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
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
be nice if some technical details were included
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
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
> NTT's customer Sofia Connect leaked our routes to NTT. NTT accepted
> these routes instead of properly filtering their customer
> announcements. As a network of non-trivial size, announcing over
> 75,000 customer routes which is nearly 15% of the IPv4 routing table,
> we'd expect the common cou
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
> 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
On Tue, Jun 30, 2015 at 03:24:02AM +, Faisal Imtiaz wrote:
> Hi Jared,
>
> This is neat !, for someone who recently started working the IRR's, I can
> tell you that it has been very difficult finding all info in one location.
>
> What you shared is pretty neat !, and I would like to clean 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
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
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 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 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 Tue, 30 Jun 2015, Ricky Beam wrote:
The death of Novell NetWare (and their transitioned to IP) killed it the
enterprise. Games adopting IP for network play killed it in the home.
Ultimately, it sucks as a WAN protocol, so the internet was built using this
new fangled IP thing.
There are
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, 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 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, 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 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 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 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 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 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
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 06/30/2015 07:28 AM, Justin M. Streiner wrote:
There are still isolated pockets of devices out there speaking IPX,
DECnet, Appletalk, etc, but either they're not connected to the
'Internet', or their traffic passes through other devices that
encapsulate and de-encapsulate it in IP to allow it
> On Jun 30, 2015, at 10:03 , Stephen Satchell wrote:
>
> On 06/30/2015 07:28 AM, Justin M. Streiner wrote:
>> There are still isolated pockets of devices out there speaking IPX,
>> DECnet, Appletalk, etc, but either they're not connected to the
>> 'Internet', or their traffic passes through oth
Depends on what performance considerations you are trying to address,
technically.
The question is how can we guarantee the GRE/BGP performance (control
traffic) during the time between detection and mitigation?
GRE decapsulation?
IE: Hardware vs Software?
Routing of the Protocol over the interne
On 1 Jul 2015, at 1:37, Dennis B wrote:
Would you like to learn more? lol
I'm quite conversant with all these considerations, thanks.
OP asserted that BGP sessions for diversion into any cloud DDoS
mitigation service ran from the endpoint network through GRE tunnels to
the cloud-based miti
On 15-06-26 14:04, Hank Disuko wrote:
> Bell Canada is apparently gearing up to provide the good people of Toronto
> with the World's Fastest Internet™.
> http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html
BTW, initally, Bell limits it to 94
Roland,
Agreed, Ramy's scenario was not truly spot on, but his question still
remains. Perf implications when cloud security providers time to
detect/mitigate is X minutes. How stable can GRE transports and BGP
sessions be when under load?
In my technical opinion, this is a valid argument, which
Dear colleagues,
Please find the CFP for RIPE 71 below or at
https://ripe71.ripe.net/submit-topic/cfp/.
The deadline for submissions is 13 September 2015.
Please also note that speakers do not receive any extra reduction or
funding towards the meeting fee at the RIPE Meetings.
Kind regards,
Be
On Tue, 30 Jun 2015 10:28:13 -0400, Justin M. Streiner
wrote:
There are still isolated pockets of devices out there speaking IPX,
DECnet, Appletalk, etc
Indeed. I'm one of them. (rarely) ... IPX managed print server. It speaks
IP, but cannot be managed by IP. I'd throw it away, but it func
On 30 June 2015 at 22:32, Jean-Francois Mezei
wrote:
> BTW, initally, Bell limits it to 940mbps.
940 Mbps is what speedtest.net will give you on a linespeed 1 Gbps
connection. That sounds more like marketing people trying to understand
"overhead".
Regards,
Baldur
On Tue, Jun 30, 2015 at 1:43 PM, Ricky Beam wrote:
> On Tue, 30 Jun 2015 10:28:13 -0400, Justin M. Streiner
> wrote:
>>
>> There are still isolated pockets of devices out there speaking IPX,
>> DECnet, Appletalk, etc
>
>
> Indeed. I'm one of them. (rarely) ... IPX managed print server. It speaks
I was thinking that when I posted yesterday.
These were announcements from a peer, not customer routes.
We are lowering our max prefix limits on many peers as a result of this.
We are also going towards more prefix filtering on peers beyond bogons
and martians.
Mike.
On 6/30/15 2:19 AM, Ran
* Mike Leber
> I was thinking that when I posted yesterday.
>
> These were announcements from a peer, not customer routes.
>
> We are lowering our max prefix limits on many peers as a result of this.
>
> We are also going towards more prefix filtering on peers beyond bogons
> and martians.
Hi
Call for Presentations
European Peering Forum 10
AMS-IX, DE-CIX, LINX, Netnod and guest IXP Equinix, are happy to host
the 10th European Peering Forum (EPF) in Madrid, Spain from the 21st
till the 23th of September 2015. The event will welcome up to 250
peering managers and coordinators from netwo
On 6/30/15 3:02 PM, Tore Anderson wrote:
* Mike Leber
I was thinking that when I posted yesterday.
These were announcements from a peer, not customer routes.
We are lowering our max prefix limits on many peers as a result of this.
We are also going towards more prefix filtering on peers be
On Tuesday, June 30, 2015, Mike Leber wrote:
>
>
> On 6/30/15 3:02 PM, Tore Anderson wrote:
>
>> * Mike Leber
>>
>> I was thinking that when I posted yesterday.
>>>
>>> These were announcements from a peer, not customer routes.
>>>
>>> We are lowering our max prefix limits on many peers as a res
On Wed, Jul 01, 2015 at 12:02:40AM +0200, Tore Anderson wrote:
> > I was thinking that when I posted yesterday.
> >
> > These were announcements from a peer, not customer routes.
> >
> > We are lowering our max prefix limits on many peers as a result of this.
> >
> > We are also going towards mo
>Is the WSJ a wholly owned subsidiary of GOOG? It looks to me like a WSJ
>journalist said that.
If you read the paper, which is linked from the article and takes
about five minutes, you'll find that article is cheap clickbait and
has approximately nothing to do with the topic of the paper. As f
On Tue, Jun 30, 2015 at 03:32:42PM -0700, Ca By wrote:
> It is NTT that would have mitigated this issue if they deployed and
> enforcer rpki, right?
No, NTT deploying RPKI would not have helped in yesterday's issue.
But, RPKI could've made a difference in today's Bangladesh leak, even if
RPKI val
We have been pushing large configurations to devices. You can check my slides
from the London IEPG meeting.
When 96% of your config is prefix filters we are sure trying.
I ask others to encourage your vendors to make this a priority as we have faced
a number of issues in this area and have bee
On Tue, Jun 30, 2015 at 05:40:03PM -0500, Jared Mauch wrote:
> We have been pushing large configurations to devices. You can check my
> slides from the London IEPG meeting.
These are the slides: http://iepg.org/2014-03-02-ietf89/ietf89_iepg_jmauch.pdf
> When 96% of your config is prefix filters
> As Job Snijders said, "I would forsee issues if i'd try to add an eleven
> megabyte prefix-list on all devices in the network.".
and that is why i stopped peering with HE. i run origin validation;
issue roas please.
randy
Yes, we have seen one of our prefixes hikacked. We contacted to Fiberathome and
they told us the issue has been solved.
Greetings.
Ferran.
-Mensaje original-
De: NANOG [mailto:nanog-boun...@nanog.org] En nombre de Grzegorz Janoszka
Enviado el: martes, 30 de junio de 2015 10:27
Para: nano
There are some downsides with the Colt-250+ units (as I have one almost
daily to do installs for a CLEC).
1. The Colts require 4 high amperage AA batteries. I used to purchase
Duracell Ultra batteries which worked, but life span was a couple of weeks
to maybe a month and now I cannot seem to find
> - equipment might not support the RTR protocol to validate
> announcements against the cache validator
alcalu, cisco, juniper do
> - Legal obstacles in obtaining the anchors from all RIRs
arin has been pwned by the tea party and is best ignored. that they do
not protect their me
Is it odd that there is no mention of this even here?
http://www.wavebroadband.com/resources/outage/service.txt
--
sed quis custodiet ipsos custodes? (Juvenal)
There has been mention to this in outages.org list
Mehmet
> On Jun 30, 2015, at 17:37, Larry Sheldon wrote:
>
>
> Is it odd that there is no mention of this even here?
>
> http://www.wavebroadband.com/resources/outage/service.txt
> --
> sed quis custodiet ipsos custodes? (Juvenal)
On Wed, Jul 01, 2015 at 09:36:34AM +0900, Randy Bush wrote:
> > - when not using the RTR protocol but generating prefix-list
> > filters based on RPKI data, the devices might not support
> > sufficient entries.
>
> because the rpki generated acls are bigger and heavier than those i
>>> - when not using the RTR protocol but generating prefix-list
>>> filters based on RPKI data, the devices might not support
>>> sufficient entries.
>>
>> because the rpki generated acls are bigger and heavier than those in
>> the irr. and they have trans-fats.
>
> I don't cons
We experienced our first leap second outage -- our SHE (super head end) is
using (old) Motorola encoders and we lost those video channels. They
restarted all those encoders to restore service.
Frank
This was supposed to have happened @midnight UTC, right? Meaning that we
are past that event. Under which scenarios should people be concerned about
midnight local time? Lots of confusing messages flying all over...
On Jun 30, 2015 10:13 PM, wrote:
> We experienced our first leap second outage --
I read that and that at midnight local time since that's when you have the
extra second. I know a large carrier in Israel is down. Waiting for conf. If
it's leep second related.
--Original Message--
From: Stefan
Sender: NANOG
To: frnk...@iname.com
Cc: nanog@nanog.org
Subject: Re: leap se
That is my understanding as well. The event was about 3.5 hours ago.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Tue, Jun 30, 2015 at 11:30 PM, Stefan wrote:
> This was supposed to have happened @midnight UTC, right? Meaning that we
> are
No. Some one leaked some routes:
https://mobile.twitter.com/Axcelx/status/616058414746202113
Regards,
Dovid
-Original Message-
From: Justin Paine
Date: Tue, 30 Jun 2015 20:37:06
To:
Cc: Stefan; NANOG;
;
Subject: Re: leap second outage
Any confirmation if the AWS outage was leap s
Correct, the leap second gets inserted at midnight UTC.
"Leap seconds can be introduced in UTC at the end of the months of December
or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every
six months, either to announce a time step in UTC or to confirm that there
will be no t
A leap sec causing issues. For about 40 years now, there have been
these leap seconds to no real issue. All of these are "go-forwards"
and even MS AD (I believe) treat them as a little bump (nothing to see
here move along). So unless you have really a tight VPN (non-standard
conforming) I'd hope th
Joe writes:
> A leap sec causing issues. For about 40 years now, there have been
> these leap seconds to no real issue. All of these are "go-forwards"
No, they're all "go-backwards" events. That's no big deal to things
that don't care about monotonic time, or to folks who aren't in
violation of s
On 15-07-01 00:47, Harlan Stenn wrote:
> What I'm about to say may not be as stupid as it sounds: The problems
> here aren't problems for cases where it's not a problem. It is a
> problem where it *is* a problem.
In fairness, systems should be used to NTP making adjustments to the
system clock
On Wed, 1 Jul 2015, Jean-Francois Mezei wrote:
However, in systems that expect tightly synchronized clocks, they would
want all the nodes to make the NTP adjustement at the same time.
This is both an operating system and application problem.
http://infiniteundo.com/post/25326999628/falsehoods
Mikael Abrahamsson writes:
> This is similar to the jiffycounter wrapping, since this doesn't happen
> that often, it's not commonly tested for. Good way is to start the jiffy
> counter so it wraps after 10 minutes of uptime. That way you'll run into
> any bugs quickly. Either we should abolish
-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
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 i
On 1/Jul/15 00:02, Tore Anderson wrote:
>
> You're not mentioning RPKI here. Any particular reason why not?
>
> If I understand correctly, in today's leak the origin AS was
> changed/reset, so RPKI ought to have saved the day. (At least Grzegorz'
> day, considering that 33 of AS43996's prefixes a
oracle linux did this
Jul 1 02:01:29 oraclelinux ntpd[600]: 0.0.0.0 061c 0c clock_step -1.006445 s
Jul 1 02:01:29 oraclelinux ntpd[600]: 0.0.0.0 0615 05 clock_sync
Jul 1 02:01:29 oraclelinux systemd: Time has been changed
Jul 1 02:01:30 oraclelinux ntpd[600]: 0.0.0.0 c618 08 no_sys_peer
all see
69 matches
Mail list logo
