Re: Indonesian ISP Moratel announces Google's prefixes

[Jian Gu]

Dear Mr. Know-Peering,

I came here to learn and I believe I have the right to say what I was
thinking, no matter how ignorant my comment was. I don't have the right to
blame anybody, in fact I don't give a damn whose fault it is, it is not my
business.

I apologize if I offended you when you claimed that it was a hijacking.

On Tue, Nov 6, 2012 at 9:45 PM, Patrick W. Gilmore wrote:

> On Nov 07, 2012, at 00:35 , Jian Gu  wrote:
>
> > Hmm, look at this screen shot from the blog, 8.8.8.0/24 was orignated
> from
> > Google.
>
> Everyone who posted in this thread was well aware of that.  (Well, except
> me in my first post. :)  Google was still the victim, and it was still not
> their fault.
>
> You are showing wide and clear ignorance on the basics of peering.  Which
> is fine, the vast majority of the planet hasn't a clue what peering is.
>  However, the rest of the people who do not know what they are talking
> about have managed to avoid commenting on the subject to 10K+ of their
> not-so-closest friends.
>
> To be clear, if you had started with something like: "Why is Google
> originating the route?  Doesn't that make it valid?", you would have gotten
> a lot of help & support.  But instead you started by claiming it was
> Google's fault and they could stop this by setting "the correct BGP
> attributes".  I note you still haven't told us what those attributes would
> be despite repeated questions.
>
> Perhaps it's time to admit you don't know what attributes, and you need a
> little more education on peering in general?
>
> When you find yourself in a hole, stop digging.
>
> --
> TTFN,
> patrick
>
>
> > tom@edge01.sfo01> show route 8.8.8.8
> >
> > inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown,
> > 14 hidden)
> > + = Active Route, - = Last Active, * = Both
> > 8.8.8.0/24 *[BGP/170] 00:27:02, MED 18, localpref 100
> >  AS path: 4436 3491 23947 15169 I
> >> to 69.22.153.1 via ge-1/0/9.0
> >
> >
> >
> > On Tue, Nov 6, 2012 at 9:33 PM, Hank Nussbacher  >wrote:
> >
> >> At 21:21 06/11/2012 -0800, Jian Gu wrote:
> >>
> >> If Google announces 8.8.8.0/24 to you and you in turn start announcing
> to
> >> the Internet 8.8.8.0/24 as originating from you, then a certain section
> >> of the Internet will believe your announcement over Google's.This
> has
> >> happened many times before due to improper filters, but this is the
> first
> >> time I have seen the victim being blamed.  Interesting concept.
> >>
> >> -Hank
> >>
> >> I don't know what Google and Moratel's peering agreement, but "leak"?
> >>> educate me, Google is announcing /24 for all of their 4 NS prefix and
> >>> 8.8.8.0/24 for their public DNS server, how did Moratel leak those
> routes
> >>> to Internet?
> >>>
> >>> On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore   wrote:
> >>>
> >>>
>  On Nov 07, 2012, at 00:07 , Jian Gu  wrote:
> 
> > Where did you get the idea that a Moratel customer announced a
>  google-owned
> > prefix to Moratel and Moratel did not have the proper filters in
> >>> place?
> > according to the blog, all google's 4 authoritative DNS server
> >>> networks
>  and
> > 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for
> >>> a
> > Moratel customers announce all those prefixes?
> 
>  Ah, right, they just leaked Google's prefix.  I thought a customer
>  originated the prefix.
> 
>  Original question still stands.  Which attribute do you expect Google
> to
>  set to stop this?
> 
>  Hint: Don't say No-Advertise, unless you want peers to only talk to
> the
>  adjacent AS, not their customers or their customers' customers, etc.
> 
>  Looking forward to your answer.
> 
>  --
>  TTFN,
>  patrick
> 
> 
> > On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore <
> patr...@ianai.net
> > wrote:
> >
> >> On Nov 06, 2012, at 23:48 , Jian Gu  wrote:
> >>
> >>> What do you mean hijack? Google is peering with Moratel, if Google
> >>> does
> >> not
> >>> want Moratel to advertise its routes to Moratel's peers/upstreams,
> >>> then
> >>> Google should've set the correct BGP attributes in the first place.
> >>
> >> That doesn't make the slightest bit of sense.
> >>
> >> If a Moratel customer announced a Google-owned prefix to Moratel,
> and
> >> Moratel did not have the proper filters in place, there is nothing
>  Google
> >> could do to stop the hijack from happening.
> >>
> >> Exactly what attribute do you think would stop this?
> >>
> >> --
> >> TTFN,
> >> patrick
> >>
> >>
> >>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia  >
> >> wrote:
> >>>
>  Another case of route hijack -
> 
> >>
>  http://blog.cloudflare.com/**why-google-went-offline-today-**
> >>> and-a-bit-about<
> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-abo

Re: Indonesian ISP Moratel announces Google's prefixes

[Anurag Bhatia]

Apologize for calling it an prefix hijack. I misunderstood in start.
Clearly it was case of prefix leaking.

Thanks


(Sent from my mobile device)

Anurag Bhatia
http://anuragbhatia.com
On Nov 7, 2012 11:22 AM, "joel jaeggli"  wrote:

> On 11/7/12 12:13 AM, Patrick W. Gilmore wrote:
>
>> On Nov 07, 2012, at 00:07 , Jian Gu  wrote:
>>
>>  Where did you get the idea that a Moratel customer announced a
>>> google-owned
>>> prefix to Moratel and Moratel did not have the proper filters in place?
>>> according to the blog, all google's 4 authoritative DNS server networks
>>> and
>>> 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a
>>> Moratel customers announce all those prefixes?
>>>
>> Ah, right, they just leaked Google's prefix.  I thought a customer
>> originated the prefix.
>>
>> Original question still stands.  Which attribute do you expect Google to
>> set to stop this?
>>
>> Hint: Don't say No-Advertise, unless you want peers to only talk to the
>> adjacent AS, not their customers or their customers' customers, etc.
>>
>> Looking forward to your answer.
>>
>
> I would expect that moratel should have a route object which their transit
> providers can construct a prefix filter for. if moratel advertised an AS
> path including themselves and a google  orgin pccw should not have accepted
> it. if they originated the prefix, pccw should not have accepted it.
>
>
>

Re: Indonesian ISP Moratel announces Google's prefixes

[Andrew Jones]

It looks like nLayer have routes learned through Moratel which have 
local-pref set to anywhere up to 250 (learned from private peers), while 
the routes learned from direct peering relationships to Google on public 
peering have a local-pref of 200. This explains why the routes from 
Moratel would have been preferred during the period when they were being 
leaked, despite the shorter as-path (but doesn't explain why they 
weren't being filtered).



On 07.11.2012 16:33, Hank Nussbacher wrote:

At 21:21 06/11/2012 -0800, Jian Gu wrote:

If Google announces 8.8.8.0/24 to you and you in turn start
announcing to the Internet 8.8.8.0/24 as originating from you, then a
certain section of the Internet will believe your announcement over
Google's.This has happened many times before due to improper
filters, but this is the first time I have seen the victim being
blamed.  Interesting concept.

-Hank


I don't know what Google and Moratel's peering agreement, but "leak"?
educate me, Google is announcing /24 for all of their 4 NS prefix and
8.8.8.0/24 for their public DNS server, how did Moratel leak those 
routes

to Internet?

On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore 
wrote:


> On Nov 07, 2012, at 00:07 , Jian Gu  wrote:
>
> > Where did you get the idea that a Moratel customer announced a
> google-owned
> > prefix to Moratel and Moratel did not have the proper filters in 
place?
> > according to the blog, all google's 4 authoritative DNS server 
networks

> and
> > 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity 
for a

> > Moratel customers announce all those prefixes?
>
> Ah, right, they just leaked Google's prefix.  I thought a customer
> originated the prefix.
>
> Original question still stands.  Which attribute do you expect 
Google to

> set to stop this?
>
> Hint: Don't say No-Advertise, unless you want peers to only talk 
to the
> adjacent AS, not their customers or their customers' customers, 
etc.

>
> Looking forward to your answer.
>
> --
> TTFN,
> patrick
>
>
> > On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore 

> >wrote:
> >
> >> On Nov 06, 2012, at 23:48 , Jian Gu  
wrote:

> >>
> >>> What do you mean hijack? Google is peering with Moratel, if 
Google does

> >> not
> >>> want Moratel to advertise its routes to Moratel's 
peers/upstreams, then
> >>> Google should've set the correct BGP attributes in the first 
place.

> >>
> >> That doesn't make the slightest bit of sense.
> >>
> >> If a Moratel customer announced a Google-owned prefix to 
Moratel, and
> >> Moratel did not have the proper filters in place, there is 
nothing

> Google
> >> could do to stop the hijack from happening.
> >>
> >> Exactly what attribute do you think would stop this?
> >>
> >> --
> >> TTFN,
> >> patrick
> >>
> >>
> >>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia 


> >> wrote:
> >>>
>  Another case of route hijack -
> 
> >>
> 
http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about

> 
> 
> 
>  I am curious if big networks have any pre-defined filters for 
big

> >> content
>  providers like Google to avoid these? I am sure internet 
community

> >> would be
>  working in direction to somehow prevent these issues. Curious 
to know

>  developments so far.
> 
> 
> 
> 
>  Thanks.
> 
> 
>  --
> 
>  Anurag Bhatia
>  anuragbhatia.com
> 
>  Linkedin  |
>  Twitter|
>  Google+ 
> 
> >>>
> >>
> >>
> >>
>
>
>

Re: Indonesian ISP Moratel announces Google's prefixes

[joel jaeggli]

On 11/7/12 12:13 AM, Patrick W. Gilmore wrote:

On Nov 07, 2012, at 00:07 , Jian Gu  wrote:


Where did you get the idea that a Moratel customer announced a google-owned
prefix to Moratel and Moratel did not have the proper filters in place?
according to the blog, all google's 4 authoritative DNS server networks and
8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a
Moratel customers announce all those prefixes?

Ah, right, they just leaked Google's prefix.  I thought a customer originated 
the prefix.

Original question still stands.  Which attribute do you expect Google to set to 
stop this?

Hint: Don't say No-Advertise, unless you want peers to only talk to the 
adjacent AS, not their customers or their customers' customers, etc.

Looking forward to your answer.


I would expect that moratel should have a route object which their 
transit providers can construct a prefix filter for. if moratel 
advertised an AS path including themselves and a google  orgin pccw 
should not have accepted it. if they originated the prefix, pccw should 
not have accepted it.

Re: Indonesian ISP Moratel announces Google's prefixes

[Patrick W. Gilmore]

On Nov 07, 2012, at 00:35 , Jian Gu  wrote:

> Hmm, look at this screen shot from the blog, 8.8.8.0/24 was orignated from
> Google.

Everyone who posted in this thread was well aware of that.  (Well, except me in 
my first post. :)  Google was still the victim, and it was still not their 
fault.

You are showing wide and clear ignorance on the basics of peering.  Which is 
fine, the vast majority of the planet hasn't a clue what peering is.  However, 
the rest of the people who do not know what they are talking about have managed 
to avoid commenting on the subject to 10K+ of their not-so-closest friends.

To be clear, if you had started with something like: "Why is Google originating 
the route?  Doesn't that make it valid?", you would have gotten a lot of help & 
support.  But instead you started by claiming it was Google's fault and they 
could stop this by setting "the correct BGP attributes".  I note you still 
haven't told us what those attributes would be despite repeated questions.

Perhaps it's time to admit you don't know what attributes, and you need a 
little more education on peering in general?

When you find yourself in a hole, stop digging.

-- 
TTFN,
patrick


> tom@edge01.sfo01> show route 8.8.8.8
> 
> inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown,
> 14 hidden)
> + = Active Route, - = Last Active, * = Both
> 8.8.8.0/24 *[BGP/170] 00:27:02, MED 18, localpref 100
>  AS path: 4436 3491 23947 15169 I
>> to 69.22.153.1 via ge-1/0/9.0
> 
> 
> 
> On Tue, Nov 6, 2012 at 9:33 PM, Hank Nussbacher wrote:
> 
>> At 21:21 06/11/2012 -0800, Jian Gu wrote:
>> 
>> If Google announces 8.8.8.0/24 to you and you in turn start announcing to
>> the Internet 8.8.8.0/24 as originating from you, then a certain section
>> of the Internet will believe your announcement over Google's.This has
>> happened many times before due to improper filters, but this is the first
>> time I have seen the victim being blamed.  Interesting concept.
>> 
>> -Hank
>> 
>> I don't know what Google and Moratel's peering agreement, but "leak"?
>>> educate me, Google is announcing /24 for all of their 4 NS prefix and
>>> 8.8.8.0/24 for their public DNS server, how did Moratel leak those routes
>>> to Internet?
>>> 
>>> On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore >>> wrote:
>>> 
>>> 
 On Nov 07, 2012, at 00:07 , Jian Gu  wrote:
 
> Where did you get the idea that a Moratel customer announced a
 google-owned
> prefix to Moratel and Moratel did not have the proper filters in
>>> place?
> according to the blog, all google's 4 authoritative DNS server
>>> networks
 and
> 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for
>>> a
> Moratel customers announce all those prefixes?
 
 Ah, right, they just leaked Google's prefix.  I thought a customer
 originated the prefix.
 
 Original question still stands.  Which attribute do you expect Google to
 set to stop this?
 
 Hint: Don't say No-Advertise, unless you want peers to only talk to the
 adjacent AS, not their customers or their customers' customers, etc.
 
 Looking forward to your answer.
 
 --
 TTFN,
 patrick
 
 
> On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore  wrote:
> 
>> On Nov 06, 2012, at 23:48 , Jian Gu  wrote:
>> 
>>> What do you mean hijack? Google is peering with Moratel, if Google
>>> does
>> not
>>> want Moratel to advertise its routes to Moratel's peers/upstreams,
>>> then
>>> Google should've set the correct BGP attributes in the first place.
>> 
>> That doesn't make the slightest bit of sense.
>> 
>> If a Moratel customer announced a Google-owned prefix to Moratel, and
>> Moratel did not have the proper filters in place, there is nothing
 Google
>> could do to stop the hijack from happening.
>> 
>> Exactly what attribute do you think would stop this?
>> 
>> --
>> TTFN,
>> patrick
>> 
>> 
>>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia 
>> wrote:
>>> 
 Another case of route hijack -
 
>> 
 http://blog.cloudflare.com/**why-google-went-offline-today-**
>>> and-a-bit-about
 
 
 
 I am curious if big networks have any pre-defined filters for big
>> content
 providers like Google to avoid these? I am sure internet community
>> would be
 working in direction to somehow prevent these issues. Curious to
>>> know
 developments so far.
 
 
 
 
 Thanks.
 
 
 --
 
 Anurag Bhatia
 anuragbhatia.com
 
 Linkedin 
 >
>>> |
 Twitter

Re: Indonesian ISP Moratel announces Google's prefixes

[Jian Gu]

Hmm, look at this screen shot from the blog, 8.8.8.0/24 was orignated from
Google.

tom@edge01.sfo01> show route 8.8.8.8

inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown,
14 hidden)
+ = Active Route, - = Last Active, * = Both
8.8.8.0/24 *[BGP/170] 00:27:02, MED 18, localpref 100
  AS path: 4436 3491 23947 15169 I
> to 69.22.153.1 via ge-1/0/9.0



On Tue, Nov 6, 2012 at 9:33 PM, Hank Nussbacher wrote:

> At 21:21 06/11/2012 -0800, Jian Gu wrote:
>
> If Google announces 8.8.8.0/24 to you and you in turn start announcing to
> the Internet 8.8.8.0/24 as originating from you, then a certain section
> of the Internet will believe your announcement over Google's.This has
> happened many times before due to improper filters, but this is the first
> time I have seen the victim being blamed.  Interesting concept.
>
> -Hank
>
>  I don't know what Google and Moratel's peering agreement, but "leak"?
>> educate me, Google is announcing /24 for all of their 4 NS prefix and
>> 8.8.8.0/24 for their public DNS server, how did Moratel leak those routes
>> to Internet?
>>
>> On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore > >wrote:
>>
>>
>> > On Nov 07, 2012, at 00:07 , Jian Gu  wrote:
>> >
>> > > Where did you get the idea that a Moratel customer announced a
>> > google-owned
>> > > prefix to Moratel and Moratel did not have the proper filters in
>> place?
>> > > according to the blog, all google's 4 authoritative DNS server
>> networks
>> > and
>> > > 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for
>> a
>> > > Moratel customers announce all those prefixes?
>> >
>> > Ah, right, they just leaked Google's prefix.  I thought a customer
>> > originated the prefix.
>> >
>> > Original question still stands.  Which attribute do you expect Google to
>> > set to stop this?
>> >
>> > Hint: Don't say No-Advertise, unless you want peers to only talk to the
>> > adjacent AS, not their customers or their customers' customers, etc.
>> >
>> > Looking forward to your answer.
>> >
>> > --
>> > TTFN,
>> > patrick
>> >
>> >
>> > > On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore > > >wrote:
>> > >
>> > >> On Nov 06, 2012, at 23:48 , Jian Gu  wrote:
>> > >>
>> > >>> What do you mean hijack? Google is peering with Moratel, if Google
>> does
>> > >> not
>> > >>> want Moratel to advertise its routes to Moratel's peers/upstreams,
>> then
>> > >>> Google should've set the correct BGP attributes in the first place.
>> > >>
>> > >> That doesn't make the slightest bit of sense.
>> > >>
>> > >> If a Moratel customer announced a Google-owned prefix to Moratel, and
>> > >> Moratel did not have the proper filters in place, there is nothing
>> > Google
>> > >> could do to stop the hijack from happening.
>> > >>
>> > >> Exactly what attribute do you think would stop this?
>> > >>
>> > >> --
>> > >> TTFN,
>> > >> patrick
>> > >>
>> > >>
>> > >>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia 
>> > >> wrote:
>> > >>>
>> >  Another case of route hijack -
>> > 
>> > >>
>> > http://blog.cloudflare.com/**why-google-went-offline-today-**
>> and-a-bit-about
>> > 
>> > 
>> > 
>> >  I am curious if big networks have any pre-defined filters for big
>> > >> content
>> >  providers like Google to avoid these? I am sure internet community
>> > >> would be
>> >  working in direction to somehow prevent these issues. Curious to
>> know
>> >  developments so far.
>> > 
>> > 
>> > 
>> > 
>> >  Thanks.
>> > 
>> > 
>> >  --
>> > 
>> >  Anurag Bhatia
>> >  anuragbhatia.com
>> > 
>> >  Linkedin 
>> >  >
>> |
>> >  Twitter
>> >|
>> >  Google+ 
>> >  
>> >
>> > 
>> > >>>
>> > >>
>> > >>
>> > >>
>> >
>> >
>> >
>>
>
>

Re: Indonesian ISP Moratel announces Google's prefixes

[Hank Nussbacher]

At 21:21 06/11/2012 -0800, Jian Gu wrote:

If Google announces 8.8.8.0/24 to you and you in turn start announcing to 
the Internet 8.8.8.0/24 as originating from you, then a certain section of 
the Internet will believe your announcement over Google's.This has 
happened many times before due to improper filters, but this is the first 
time I have seen the victim being blamed.  Interesting concept.


-Hank


I don't know what Google and Moratel's peering agreement, but "leak"?
educate me, Google is announcing /24 for all of their 4 NS prefix and
8.8.8.0/24 for their public DNS server, how did Moratel leak those routes
to Internet?

On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore wrote:

> On Nov 07, 2012, at 00:07 , Jian Gu  wrote:
>
> > Where did you get the idea that a Moratel customer announced a
> google-owned
> > prefix to Moratel and Moratel did not have the proper filters in place?
> > according to the blog, all google's 4 authoritative DNS server networks
> and
> > 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a
> > Moratel customers announce all those prefixes?
>
> Ah, right, they just leaked Google's prefix.  I thought a customer
> originated the prefix.
>
> Original question still stands.  Which attribute do you expect Google to
> set to stop this?
>
> Hint: Don't say No-Advertise, unless you want peers to only talk to the
> adjacent AS, not their customers or their customers' customers, etc.
>
> Looking forward to your answer.
>
> --
> TTFN,
> patrick
>
>
> > On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore  >wrote:
> >
> >> On Nov 06, 2012, at 23:48 , Jian Gu  wrote:
> >>
> >>> What do you mean hijack? Google is peering with Moratel, if Google does
> >> not
> >>> want Moratel to advertise its routes to Moratel's peers/upstreams, then
> >>> Google should've set the correct BGP attributes in the first place.
> >>
> >> That doesn't make the slightest bit of sense.
> >>
> >> If a Moratel customer announced a Google-owned prefix to Moratel, and
> >> Moratel did not have the proper filters in place, there is nothing
> Google
> >> could do to stop the hijack from happening.
> >>
> >> Exactly what attribute do you think would stop this?
> >>
> >> --
> >> TTFN,
> >> patrick
> >>
> >>
> >>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia 
> >> wrote:
> >>>
>  Another case of route hijack -
> 
> >>
> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about
> 
> 
> 
>  I am curious if big networks have any pre-defined filters for big
> >> content
>  providers like Google to avoid these? I am sure internet community
> >> would be
>  working in direction to somehow prevent these issues. Curious to know
>  developments so far.
> 
> 
> 
> 
>  Thanks.
> 
> 
>  --
> 
>  Anurag Bhatia
>  anuragbhatia.com
> 
>  Linkedin  |
>  Twitter|
>  Google+ 
> 
> >>>
> >>
> >>
> >>
>
>
>

Re: Indonesian ISP Moratel announces Google's prefixes

[Hank Nussbacher]

At 20:48 06/11/2012 -0800, Jian Gu wrote:

Ahhh...blame the victim.  Google - shame on you.

-Hank


What do you mean hijack? Google is peering with Moratel, if Google does not
want Moratel to advertise its routes to Moratel's peers/upstreams, then
Google should've set the correct BGP attributes in the first place.

On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia  wrote:

> Another case of route hijack -
> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about
>
>
>
> I am curious if big networks have any pre-defined filters for big content
> providers like Google to avoid these? I am sure internet community would be
> working in direction to somehow prevent these issues. Curious to know
> developments so far.
>
>
>
>
> Thanks.
>
>
> --
>
> Anurag Bhatia
> anuragbhatia.com
>
> Linkedin  |
> Twitter|
> Google+ 
>

Re: Indonesian ISP Moratel announces Google's prefixes

[Patrick W. Gilmore]

On Nov 07, 2012, at 00:21 , Jian Gu  wrote:

> I don't know what Google and Moratel's peering agreement, but "leak"?
> educate me, Google is announcing /24 for all of their 4 NS prefix and
> 8.8.8.0/24 for their public DNS server, how did Moratel leak those routes
> to Internet?

Downthread, someone said what is typical with peering prefixes, i.e. announce 
to customers, not to peers or upstreams.  How do you think peering works?

However, I place most of the blame on PCCW for crappy filtering of their 
customers.  And I'm a little surprised to see nLayer in the path.  Shame on 
them!  (Does that have any effect any more? :)

Oh, and we are still waiting for an answer: Which attribute do you think Google 
could have used to stop this?

-- 
TTFN,
patrick


> On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore wrote:
> 
>> On Nov 07, 2012, at 00:07 , Jian Gu  wrote:
>> 
>>> Where did you get the idea that a Moratel customer announced a
>> google-owned
>>> prefix to Moratel and Moratel did not have the proper filters in place?
>>> according to the blog, all google's 4 authoritative DNS server networks
>> and
>>> 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a
>>> Moratel customers announce all those prefixes?
>> 
>> Ah, right, they just leaked Google's prefix.  I thought a customer
>> originated the prefix.
>> 
>> Original question still stands.  Which attribute do you expect Google to
>> set to stop this?
>> 
>> Hint: Don't say No-Advertise, unless you want peers to only talk to the
>> adjacent AS, not their customers or their customers' customers, etc.
>> 
>> Looking forward to your answer.
>> 
>> --
>> TTFN,
>> patrick
>> 
>> 
>>> On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore >> wrote:
>>> 
 On Nov 06, 2012, at 23:48 , Jian Gu  wrote:
 
> What do you mean hijack? Google is peering with Moratel, if Google does
 not
> want Moratel to advertise its routes to Moratel's peers/upstreams, then
> Google should've set the correct BGP attributes in the first place.
 
 That doesn't make the slightest bit of sense.
 
 If a Moratel customer announced a Google-owned prefix to Moratel, and
 Moratel did not have the proper filters in place, there is nothing
>> Google
 could do to stop the hijack from happening.
 
 Exactly what attribute do you think would stop this?
 
 --
 TTFN,
 patrick
 
 
> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia 
 wrote:
> 
>> Another case of route hijack -
>> 
 
>> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about
>> 
>> 
>> 
>> I am curious if big networks have any pre-defined filters for big
 content
>> providers like Google to avoid these? I am sure internet community
 would be
>> working in direction to somehow prevent these issues. Curious to know
>> developments so far.
>> 
>> 
>> 
>> 
>> Thanks.
>> 
>> 
>> --
>> 
>> Anurag Bhatia
>> anuragbhatia.com
>> 
>> Linkedin  |
>> Twitter|
>> Google+ 
>> 
> 
 
 
 
>> 
>> 
>> 

Re: Indonesian ISP Moratel announces Google's prefixes

[Jian Gu]

I don't know what Google and Moratel's peering agreement, but "leak"?
educate me, Google is announcing /24 for all of their 4 NS prefix and
8.8.8.0/24 for their public DNS server, how did Moratel leak those routes
to Internet?

On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore wrote:

> On Nov 07, 2012, at 00:07 , Jian Gu  wrote:
>
> > Where did you get the idea that a Moratel customer announced a
> google-owned
> > prefix to Moratel and Moratel did not have the proper filters in place?
> > according to the blog, all google's 4 authoritative DNS server networks
> and
> > 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a
> > Moratel customers announce all those prefixes?
>
> Ah, right, they just leaked Google's prefix.  I thought a customer
> originated the prefix.
>
> Original question still stands.  Which attribute do you expect Google to
> set to stop this?
>
> Hint: Don't say No-Advertise, unless you want peers to only talk to the
> adjacent AS, not their customers or their customers' customers, etc.
>
> Looking forward to your answer.
>
> --
> TTFN,
> patrick
>
>
> > On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore  >wrote:
> >
> >> On Nov 06, 2012, at 23:48 , Jian Gu  wrote:
> >>
> >>> What do you mean hijack? Google is peering with Moratel, if Google does
> >> not
> >>> want Moratel to advertise its routes to Moratel's peers/upstreams, then
> >>> Google should've set the correct BGP attributes in the first place.
> >>
> >> That doesn't make the slightest bit of sense.
> >>
> >> If a Moratel customer announced a Google-owned prefix to Moratel, and
> >> Moratel did not have the proper filters in place, there is nothing
> Google
> >> could do to stop the hijack from happening.
> >>
> >> Exactly what attribute do you think would stop this?
> >>
> >> --
> >> TTFN,
> >> patrick
> >>
> >>
> >>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia 
> >> wrote:
> >>>
>  Another case of route hijack -
> 
> >>
> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about
> 
> 
> 
>  I am curious if big networks have any pre-defined filters for big
> >> content
>  providers like Google to avoid these? I am sure internet community
> >> would be
>  working in direction to somehow prevent these issues. Curious to know
>  developments so far.
> 
> 
> 
> 
>  Thanks.
> 
> 
>  --
> 
>  Anurag Bhatia
>  anuragbhatia.com
> 
>  Linkedin  |
>  Twitter|
>  Google+ 
> 
> >>>
> >>
> >>
> >>
>
>
>

Re: Indonesian ISP Moratel announces Google's prefixes

[Patrick W. Gilmore]

On Nov 07, 2012, at 00:07 , Jian Gu  wrote:

> Where did you get the idea that a Moratel customer announced a google-owned
> prefix to Moratel and Moratel did not have the proper filters in place?
> according to the blog, all google's 4 authoritative DNS server networks and
> 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a
> Moratel customers announce all those prefixes?

Ah, right, they just leaked Google's prefix.  I thought a customer originated 
the prefix.

Original question still stands.  Which attribute do you expect Google to set to 
stop this?

Hint: Don't say No-Advertise, unless you want peers to only talk to the 
adjacent AS, not their customers or their customers' customers, etc.

Looking forward to your answer.

-- 
TTFN,
patrick


> On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore wrote:
> 
>> On Nov 06, 2012, at 23:48 , Jian Gu  wrote:
>> 
>>> What do you mean hijack? Google is peering with Moratel, if Google does
>> not
>>> want Moratel to advertise its routes to Moratel's peers/upstreams, then
>>> Google should've set the correct BGP attributes in the first place.
>> 
>> That doesn't make the slightest bit of sense.
>> 
>> If a Moratel customer announced a Google-owned prefix to Moratel, and
>> Moratel did not have the proper filters in place, there is nothing Google
>> could do to stop the hijack from happening.
>> 
>> Exactly what attribute do you think would stop this?
>> 
>> --
>> TTFN,
>> patrick
>> 
>> 
>>> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia 
>> wrote:
>>> 
 Another case of route hijack -
 
>> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about
 
 
 
 I am curious if big networks have any pre-defined filters for big
>> content
 providers like Google to avoid these? I am sure internet community
>> would be
 working in direction to somehow prevent these issues. Curious to know
 developments so far.
 
 
 
 
 Thanks.
 
 
 --
 
 Anurag Bhatia
 anuragbhatia.com
 
 Linkedin  |
 Twitter|
 Google+ 
 
>>> 
>> 
>> 
>> 

Re: Indonesian ISP Moratel announces Google's prefixes

[Stephen Wilcox]

Nobody said a Moratel customer announced a Google prefix, they said the
issue was within Moratel.

This is a really good article that explains the issue in detail, maybe read
it again?

http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about

Steve

On 7 November 2012 05:07, Jian Gu  wrote:

> Where did you get the idea that a Moratel customer announced a google-owned
> prefix to Moratel and Moratel did not have the proper filters in place?
> according to the blog, all google's 4 authoritative DNS server networks and
> 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a
> Moratel customers announce all those prefixes?
>
> On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore  >wrote:
>
> > On Nov 06, 2012, at 23:48 , Jian Gu  wrote:
> >
> > > What do you mean hijack? Google is peering with Moratel, if Google does
> > not
> > > want Moratel to advertise its routes to Moratel's peers/upstreams, then
> > > Google should've set the correct BGP attributes in the first place.
> >
> > That doesn't make the slightest bit of sense.
> >
> > If a Moratel customer announced a Google-owned prefix to Moratel, and
> > Moratel did not have the proper filters in place, there is nothing Google
> > could do to stop the hijack from happening.
> >
> > Exactly what attribute do you think would stop this?
> >
> > --
> > TTFN,
> > patrick
> >
> >
> > > On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia 
> > wrote:
> > >
> > >> Another case of route hijack -
> > >>
> > http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about
> > >>
> > >>
> > >>
> > >> I am curious if big networks have any pre-defined filters for big
> > content
> > >> providers like Google to avoid these? I am sure internet community
> > would be
> > >> working in direction to somehow prevent these issues. Curious to know
> > >> developments so far.
> > >>
> > >>
> > >>
> > >>
> > >> Thanks.
> > >>
> > >>
> > >> --
> > >>
> > >> Anurag Bhatia
> > >> anuragbhatia.com
> > >>
> > >> Linkedin  |
> > >> Twitter|
> > >> Google+ 
> > >>
> > >
> >
> >
> >
>

Re: Indonesian ISP Moratel announces Google's prefixes

[Jian Gu]

Where did you get the idea that a Moratel customer announced a google-owned
prefix to Moratel and Moratel did not have the proper filters in place?
according to the blog, all google's 4 authoritative DNS server networks and
8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a
Moratel customers announce all those prefixes?

On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore wrote:

> On Nov 06, 2012, at 23:48 , Jian Gu  wrote:
>
> > What do you mean hijack? Google is peering with Moratel, if Google does
> not
> > want Moratel to advertise its routes to Moratel's peers/upstreams, then
> > Google should've set the correct BGP attributes in the first place.
>
> That doesn't make the slightest bit of sense.
>
> If a Moratel customer announced a Google-owned prefix to Moratel, and
> Moratel did not have the proper filters in place, there is nothing Google
> could do to stop the hijack from happening.
>
> Exactly what attribute do you think would stop this?
>
> --
> TTFN,
> patrick
>
>
> > On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia 
> wrote:
> >
> >> Another case of route hijack -
> >>
> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about
> >>
> >>
> >>
> >> I am curious if big networks have any pre-defined filters for big
> content
> >> providers like Google to avoid these? I am sure internet community
> would be
> >> working in direction to somehow prevent these issues. Curious to know
> >> developments so far.
> >>
> >>
> >>
> >>
> >> Thanks.
> >>
> >>
> >> --
> >>
> >> Anurag Bhatia
> >> anuragbhatia.com
> >>
> >> Linkedin  |
> >> Twitter|
> >> Google+ 
> >>
> >
>
>
>

Re: Indonesian ISP Moratel announces Google's prefixes

[Patrick W. Gilmore]

On Nov 06, 2012, at 23:48 , Jian Gu  wrote:

> What do you mean hijack? Google is peering with Moratel, if Google does not
> want Moratel to advertise its routes to Moratel's peers/upstreams, then
> Google should've set the correct BGP attributes in the first place.

That doesn't make the slightest bit of sense.

If a Moratel customer announced a Google-owned prefix to Moratel, and Moratel 
did not have the proper filters in place, there is nothing Google could do to 
stop the hijack from happening.

Exactly what attribute do you think would stop this?

-- 
TTFN,
patrick


> On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia  wrote:
> 
>> Another case of route hijack -
>> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about
>> 
>> 
>> 
>> I am curious if big networks have any pre-defined filters for big content
>> providers like Google to avoid these? I am sure internet community would be
>> working in direction to somehow prevent these issues. Curious to know
>> developments so far.
>> 
>> 
>> 
>> 
>> Thanks.
>> 
>> 
>> --
>> 
>> Anurag Bhatia
>> anuragbhatia.com
>> 
>> Linkedin  |
>> Twitter|
>> Google+ 
>> 
> 

Re: Indonesian ISP Moratel announces Google's prefixes

[Jian Gu]

By reading cloudflare blog, cloudflare network engineer discovered that
Google's authoritative DNS server networks (including Google's public DNS
8.8.8.0/24) were being routed to Indonesia according their cloudflare's SF
office edge router, this is werid unless cloudflare is doing something
crazy on their edge router, given that those networks are heavily anycasted
across the Internet, if cloudflare sees those networks are being routed to
Indonesia from San Francisco, then a lot more people should've been
affected.

On Tue, Nov 6, 2012 at 8:51 PM, Christopher Morrow
wrote:

> On Tue, Nov 6, 2012 at 11:48 PM, Jian Gu  wrote:
> > What do you mean hijack? Google is peering with Moratel, if Google does
> not
> > want Moratel to advertise its routes to Moratel's peers/upstreams, then
> > Google should've set the correct BGP attributes in the first place.
> >
>
> curios to know which those are?
>

Re: Indonesian ISP Moratel announces Google's prefixes

[Andrew Jones]

It's widely accepted that you only advertise your peers' routes to 
customers, and you only advertise your own, and your customers' routes 
to your upstreams.


On 07.11.2012 15:48, Jian Gu wrote:
What do you mean hijack? Google is peering with Moratel, if Google 
does not
want Moratel to advertise its routes to Moratel's peers/upstreams, 
then

Google should've set the correct BGP attributes in the first place.

On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia  
wrote:



Another case of route hijack -

http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about



I am curious if big networks have any pre-defined filters for big 
content
providers like Google to avoid these? I am sure internet community 
would be
working in direction to somehow prevent these issues. Curious to 
know

developments so far.




Thanks.


--

Anurag Bhatia
anuragbhatia.com

Linkedin  |
Twitter|
Google+ 

Re: Indonesian ISP Moratel announces Google's prefixes

[Christopher Morrow]

On Tue, Nov 6, 2012 at 11:48 PM, Jian Gu  wrote:
> What do you mean hijack? Google is peering with Moratel, if Google does not
> want Moratel to advertise its routes to Moratel's peers/upstreams, then
> Google should've set the correct BGP attributes in the first place.
>

curios to know which those are?

Re: Indonesian ISP Moratel announces Google's prefixes

[Jian Gu]

What do you mean hijack? Google is peering with Moratel, if Google does not
want Moratel to advertise its routes to Moratel's peers/upstreams, then
Google should've set the correct BGP attributes in the first place.

On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia  wrote:

> Another case of route hijack -
> http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about
>
>
>
> I am curious if big networks have any pre-defined filters for big content
> providers like Google to avoid these? I am sure internet community would be
> working in direction to somehow prevent these issues. Curious to know
> developments so far.
>
>
>
>
> Thanks.
>
>
> --
>
> Anurag Bhatia
> anuragbhatia.com
>
> Linkedin  |
> Twitter|
> Google+ 
>

RE: Sandy seen costing telco, cable hundreds of millions of dollars

[Frank Bulk]

The U.S. Federal Communications Commission said on Thursday that about 19
percent of towers were still offline that morning down from 25 percent the
day after the storm.

Verizon Wireless, a venture of Verizon Communications and Vodafone Group
Plc, said on Thursday that about 96 percent of their cellsite were up and
running, up from 94 percent the day before.

Sprint, the No. 3 U.S. operator said that more than 80 percent of its
network was operating by Thursday evening.

T-Mobile USA, a unit of Deutsche Telekom, said it had completed 85 percent
of its restoration in New York by Thursday evening. However it is only 80
percent complete in Staten Island, a borough of New York.


So which wireless carrier is bringing down the average to 81%?

Frank

-Original Message-
From: Roy [mailto:r.engehau...@gmail.com] 
Sent: Monday, November 05, 2012 12:21 AM
To: nanog
Subject: Sandy seen costing telco, cable hundreds of millions of dollars

http://www.reuters.com/article/2012/11/01/storm-sandy-telecoms-idUSL1E8M1L9Z
20121101 

Re: p2p addresses for point-to-point connections with customers

[Dobbins, Roland]

On Nov 6, 2012, at 9:47 PM, Otis L. Surratt, Jr. wrote:

> Also, if you are going to adjust your iACL for them you will want that 
> customer to have a static IP address or range (not dynamic address) they are 
> using to monitor/manage/access the infrastructure IP you've assigned on their 
> router.

Yes, this is key.  Management access to this router should not be possible from 
the public Internet at large.

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

Unable to reach www.t-online.de over IPv6 since late September

[Frank Bulk]

For 42 days we have not been able to reach www.t-online.de over IPv6.  

C:\>tracert -6 www.t-online.de

Tracing route to www.t-online.de [2003:2:2:40:62:153:159:92]
over a maximum of 30 hops:

  1 4 ms 3 ms 2 ms  router-core.mtcnet.net
[2607:fe28:11:1000::2]
  2 3 ms 3 ms 2 ms  sxct.sxcy.mtcnet.net
[2607:fe28:11:1002::197]

  824 ms23 ms22 ms  sl-crs2-chi-te1-2-0-1.v6.sprintlink.net
[2600:4::6]
  931 ms30 ms30 ms  sl-crs2-akr-bu-2.v6.sprintlink.net
[2600:0:2:1239:144:232:20:186]
 1041 ms41 ms39 ms  sl-crs2-rly-bu-2.v6.sprintlink.net
[2600:0:2:1239:144:232:4:187]
 1140 ms40 ms39 ms  sl-crs2-dc-po0-9-0-0.v6.sprintlink.net
[2600:0:2:1239:144:232:25:128]
 1242 ms42 ms41 ms  sl-st31-ash-po0-2-0-0.v6.sprintlink.net
[2600:0:2:1239:144:232:25:15]
 13 *** Request timed out.
 14 *** Request timed out.
 15 *** Request timed out.

DT (Deutsche Telekom) is not learning our routes (AS53347) or the routes of
our upstream provider (AS5056).  DT's looking glass
(https://f-lga1.f.de.net.dtag.de/index.php?pageid=lg) confirms that:

sh ipv6 bgp 2607:fe28::/32
% Network not in table

sh ipv6 bgp 2001:05f8::/32
% Network not in table

Our prefix goes over our upstream provider's transit link with Sprint, so on
September 26 our upstream provider opened up a ticket with Sprint.  From
what our upstream provider tells us, Sprint is advertising our routes to DT
but DT has an IPv6 prefix that is blocking all of Sprint's customer
prefixes.  It's almost been a month since the last substantive update from
DT (via our upstream provider, via Sprint).

If anybody is able to help and shake something loose at DT, that would be
appreciated.  For the right people, I can provide both Sprint and DT's
ticket numbers.

Thanks,

Frank   

Re: p2p addresses for point-to-point connections with customers

[Alastair Johnson]

On 11/6/2012 5:44 AM, Tassos Chatzithomaoglou wrote:

Roland, how do you handle customer requests regarding the remote management of 
their devices?
i.e. if the customer wants to do any kind of management (ssh, snmp) from 
outside his router, he must use our
infrastructure address (which is configured on his router) as a destination.
Generally, the customer might want to use this wan address for many other 
things which you shouldn't actually care,
since it's his router.


Why would the customer not have a loopback interface configured on his 
router with an accessible IP address? Relying on the WAN address is 
arguably a poor choice for a number of reasons including renumbering 
events and circuit outages.

RE: p2p addresses for point-to-point connections with customers

[James Baker]

Well if you’re null routing the /30 then you or them should have a /32 or 
larger for NAT or no RFC space behind it. 

-Original Message-
From: Tassos Chatzithomaoglou [mailto:ach...@forthnetgroup.gr] 
Sent: Wednesday, 7 November 2012 2:45 a.m.
To: Dobbins, Roland
Cc: NANOG list
Subject: Re: p2p addresses for point-to-point connections with customers

Roland, how do you handle customer requests regarding the remote management of 
their devices?
i.e. if the customer wants to do any kind of management (ssh, snmp) from 
outside his router, he must use our infrastructure address (which is configured 
on his router) as a destination.
Generally, the customer might want to use this wan address for many other 
things which you shouldn't actually care, since it's his router.

--
Tassos


Dobbins, Roland wrote on 06/11/2012 14:34:
> On Nov 6, 2012, at 7:31 PM, Tassos Chatzithomaoglou wrote:
>
>> Only specific types of icmp messages?
> That, plus the routing session (if any) with your customer, plus anything 
> else that's situationally-specific (GRE tunnel termination, etc.).
>
> --
> - Roland Dobbins  // 
> 
>
> Luck is the residue of opportunity and design.
>
>  -- John Milton
>
>
>
>

Re: dhcpy6d - a MAC address aware DHCPv6 server

[Henri Wahl]

Hi,
> If you're on local subnet, why not pull the MAC address out of the
> received packet?
> 
The used SocketServer module of Python has no support for raw sockets,
as far as I see. Let me know if there is a way to get the MAC in a
cleaner way.

> Further, what happens to this when IPv4 goes away?
> 

Will that day ever come? :-) I think until this day a lot of RFCs will
be written. This server here just allows to make transistion easier.
And, it also allows the use of DUIDs, so it might work in an IPv6-only
world.

Regards
Henri

-- 
Henri Wahl

IT Department
Leibniz-Institut für Festkörper- u.
Werkstoffforschung Dresden

tel. (03 51) 46 59 - 797
email: h.w...@ifw-dresden.de
http://www.ifw-dresden.de

http://nagstamon.ifw-dresden.de
http://dhcpy6d.ifw-dresden.de

IFW Dresden e.V., Helmholtzstraße 20, D-01069 Dresden
VR Dresden Nr. 1369
Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle



smime.p7s
Description: S/MIME Kryptografische Unterschrift

Re: dhcpy6d - a MAC address aware DHCPv6 server

[bmanning]

On Tue, Nov 06, 2012 at 05:38:32AM -0800, Owen DeLong wrote:
> If you're on local subnet, why not pull the MAC address out of the
> received packet?
> 
> Further, what happens to this when IPv4 goes away?
> 
> Owen

"the cat came back" ...  IPv4 is going away like RIP is a dead routing 
protocol.
give it another 20 years.

/bill

UK Scientists Claim to Develop 2000 Times Faster Broadband via Fibre Optic

[Eugen Leitl]

http://www.ispreview.co.uk/index.php/2012/11/uk-scientists-claim-to-develop-2000-times-faster-broadband-via-fibre-optic.html

UK Scientists Claim to Develop 2000 Times Faster Broadband via Fibre Optic

Posted Tuesday, November 6th, 2012 (11:08 am) by Mark Jackson (Score 746)

A team of scientists working out of Bangor University in Wales has developed
a commercially affordable method of using Optical Orthogonal Frequency
Division Multiplexing (OOFDM) over fibre optic lines, which could deliver
broadband ISP speeds that are 2,000 times faster than current services.

But the three-year project (OCEAN) is not the first to make use of OOFDM,
which typically splits a laser down to multiple different optical
frequencies. The data can then be broken up and sent in parallel streams via
the different frequencies. Last year a team of Sydney University scientists
found an energy-efficient way of using a single laser to transfer data down a
50km long single-mode fibre optic cable at speeds of up to 26Tbps (Terabits
per second).

The key difference with OCEAN is that this work is capable of “significantly
saving the network installation and maintenance cost for both [ISPs] and
equipment vendors” by using low-cost off-the-shelf components and end-to-end
real-time OOFDM transceivers via currently installed fibre networks (FTTH
etc.). It also provides a “Green” solution due to the “significant reduction
in electrical power consumption“.

The work is also more targeted towards home and business connections, as
opposed to undersea cables, most of which tend to offer broadband speeds of
less than 100Mbps; currently only a few UK FTTH ISPs offer up to 1Gbps and
most suffer from very limited coverage.

Professor Jianming Tang explained:

“Compared to today’s commercially available broadband connections, the
technology is expected to provide end-users with both downloading and
uploading speeds up to 2,000 times faster than current speeds and with a
guaranteed quality of services at a price that subscribers are currently
paying for their current 20Mb/s services, regardless of subscribers’ home
location. Obviously, this will revolutionise communication technology.”

However there’s still the little matter of capacity supply costs and Traffic
Management measures to consider, although the university’s efforts bode well
for the future and could help a new generation of truly fibre optic ISPs to
improve their service without incurring excessive additional costs.

On the other hand most of today’s connections are still being delivered over
older and slower copper based broadband lines. This is gradually beginning to
change and the situation could look very different in another ten or twenty
years’ time.

According to Bangor University, OCEAN is a partnership project (funded by the
European Union (3m Euros+)) that includes several major global telecoms
firms; Fujitsu Semiconductors Europe, Finisar Israel, Fraunhofer Heinrich
Hertz Institute and VPIsystems GmbH.

Re: dhcpy6d - a MAC address aware DHCPv6 server

[George Herbert]

Oh, horrors, part of my infrastructure needs raw socket data?

We should ban that, for security.  Who needs those pesky switches anyways?


George William Herbert
Sent from my iPhone

On Nov 6, 2012, at 5:49 AM, Stephane Bortzmeyer  wrote:

> On Tue, Nov 06, 2012 at 05:38:32AM -0800,
> Owen DeLong  wrote 
> a message of 68 lines which said:
> 
>> If you're on local subnet, why not pull the MAC address out of the
>> received packet?
> 
> Because it requires access to raw sockets, which should not be
> necessary for DHCP?
> 
> 

Re: MTU issues s0.wp.com

[Matthew Luckie]

> Since about a week or so it's become impossible to reach wp.com content 
> over IPv6.
>
> IPv4 content does work fine, using the IPv6 literal returns a 404 which 
> is small enough to fit in a smaller 1480 byte MTU.
>
> I have another test site that has a clean 1500 byte mtu and I can fetch 
> the s0.wp.com page from there.
>
> It looks like tunneled IPv6 users might be in hurt here.

Yes, a middlebox is discarding PTB messages before they reach the webserver:

$ scamper -F ipfw -I "tbit -u 'http://s0.wp.com/' 
2606:2800:220:1c85:99b:1b56:207e:ea5"
tbit from 2001:48d0:101:501:d267:e5ff:fe14:a701 to 
2606:2800:220:1c85:99b:1b56:207e:ea5
 server-mss 1440, result: pmtud-fail
 app: http, url: http://s0.wp.com/
 [  0.048] TX SYN 64  seq = 0:0 
 [  0.061] RX SYN/ACK 64  seq = 0:1 
 [  0.099] TX 60  seq = 1:1 
 [  0.148] TX228  seq = 1:1(168)
 [  0.161] RX 60  seq = 1:169   
 [  0.162] RX   1500  seq = 1:169(1440) 
 [  0.162] RX   1500  seq = 1441:169(1440)  
 [  0.162] RX   1500  seq = 2881:169(1440)  
 [  0.162] RX   1500  seq = 4321:169(1440)  
 [  0.162] RX   1500  seq = 5761:169(1440)  
 [  0.162] RX914  seq = 7201:169(854)   
 [  0.198] TX PTB   1280  mtu = 1280
 [  0.248] TX 60  seq = 169:1   
 [  3.173] RX   1500  seq = 1:169(1440) 
 [  3.173] TX PTB   1280  mtu = 1280
 [  6.044] RX FIN 60  seq = 8055:169
 [  6.044] TX 60  seq = 169:1   
 [  9.183] RX   1500  seq = 1:169(1440) 
 [  9.183] TX PTB   1280  mtu = 1280
 [ 21.204] RX   1500  seq = 1:169(1440) 
 [ 21.204] TX PTB   1280  mtu = 1280
 [ 45.254] RX   1500  seq = 1:169(1440) 

RE: p2p addresses for point-to-point connections with customers

[Otis L. Surratt, Jr.]

We generally perform all the management needed for our customer's circuits. If 
the customer is wanting to remotely manage their own router and etc then you 
should adjust your iACL to grant the customer access only on the IP on their 
router interface not the whole /30 or etc. Or if you've routed an IP range to 
that customer they can use that and pick an IP for mgmt stuff from that range 
and let your infrastructure be at peace. ;)

Also, if you are going to adjust your iACL for them you will want that customer 
to have a static IP address or range (not dynamic address) they are using to 
monitor/manage/access the infrastructure IP you've assigned on their router.

Otis
-Original Message-
From: Tassos Chatzithomaoglou [mailto:ach...@forthnetgroup.gr] 
Sent: Tuesday, November 06, 2012 7:45 AM
To: Dobbins, Roland
Cc: NANOG list
Subject: Re: p2p addresses for point-to-point connections with customers

Roland, how do you handle customer requests regarding the remote management of 
their devices?
i.e. if the customer wants to do any kind of management (ssh, snmp) from 
outside his router, he must use our infrastructure address (which is configured 
on his router) as a destination.
Generally, the customer might want to use this wan address for many other 
things which you shouldn't actually care, since it's his router.

Re: AS 1668 BGP contact - possible prefix hijacking

[Brad Passwaters]

Ben,

We don't believe there is prefix hijacking.  Due to various legal and
contractual obligations there are certain questions you asked that
we just can not answer.  However I have asked an engineer to sanitize our
internal audit and provide it to you.
Also I'll reach out to you later today by phone and make sure that it
answers your questions.

Brad Passwaters - Director Production Networks at Aol
(My Nanog participation predates my employment at Aol thus the use of a
personal account)

On Tue, Nov 6, 2012 at 9:02 AM, Ben Bartsch  wrote:

> Hi:
>
> Is there anyone here who can help us with a possible prefix hijacking
> situation through ATDN?  Please contact me off list if you (or you know
> somebody) that can help us.  I've tried the ATDN NOC and Vikas, but they
> have been no help whatsoever.
>
> The hijacked prefix appears to be sent to AS 1668, then propagated from
> there.
>
> Thanks.
>
> Ben
> AS 32440
>



-- 

Brad Passwaters
--
brad.passwat...@gmail.com

Re: MTU issues s0.wp.com

[Jeroen Massar]

On 2012-11-06 13:33, Seth Mos wrote:
> Hi,
> 
> Since about a week or so it's become impossible to reach wp.com content
> over IPv6.
> 
> IPv4 content does work fine, using the IPv6 literal returns a 404 which
> is small enough to fit in a smaller 1480 byte MTU.
> 
> I have another test site that has a clean 1500 byte mtu and I can fetch
> the s0.wp.com page from there.
> 
> It looks like tunneled IPv6 users might be in hurt here.

tracepath and scapy are the tools of choice here to determine where pMTU
messages go missing. Also, it would be very useful to have a source
address when reporting these issues as it might affect a lot of other
paths too.

Greets,
 Jeroen

Re: MTU issues s0.wp.com

[sthaug]

> Is anyone else experiencing similar issues?

Not from here (AS 2116, Norway). No problem getting up the web page,
tcpdump shows MSS 1440.

> My traceroute shows they are employing a CDN for s0.wp.com, so not 
> everyone might be affected.
> 
>   7  asd2-rou-1022.NL.eurorings.net (2001:680:0:800f::291)  6.460 ms 
> 6.203 ms  6.188 ms
>   8  asd2-rou-1044.eurorings.net (2001:680::134:222:85:63)  6.447 ms 
> 6.494 ms  6.495 ms
>   9  adm-b5-link.telia.net (2001:2000:3080:6f::1)  6.818 ms  6.936 ms 
> 6.891 ms
> 10  ldn-b3-v6.telia.net (2001:2000:3018:5::1)  15.290 ms  27.481 ms 
> 15.380 ms
> 11  edgecast-ic-147468-ldn-b3.c.telia.net (2001:2000:3080:378::2) 
> 15.116 ms  15.174 ms  15.176 ms
> 12  2606:2800:234:1922:15a7:17bf:bb7:f09 
> (2606:2800:234:1922:15a7:17bf:bb7:f09)  15.496 ms  15.327 ms  15.460 ms

I have a clean 1500 byte path to s0.wp.com through Level3 and Telia:

 1  ge0-0-0-10.ar1.skxy.no.catchbone.net (2001:8c0:9602:1::1)  7.937 ms  7.882 
ms  10.373 ms
 2  ge0-0-2.cr2.osls.as2116.net (2001:8c0:3::71)  9.745 ms  9.540 ms  9.117 ms
 3  te3-0-0.br1.osls.as2116.net (2001:8c0:3::292)  10.352 ms  9.548 ms  9.733 ms
 4  te-4-1.car1.Oslo1.Level3.net (2001:1900:5:2:1::99)  10.374 ms  9.023 ms  
10.206 ms
 5  ae-3-6.bar1.Copenhagen1.Level3.net (2001:1900:5:1::49)  18.002 ms  18.597 
ms  14.754 ms
 6  ae-0-10.bar1.Copenhagen2.Level3.net (2001:1900:5:1::1b6)  15.193 ms  19.215 
ms  15.314 ms
 7  kbn-b3-link.telia.net (2001:2000:3080:459::1)  20.434 ms  18.480 ms  15.821 
ms
 8  ldn-b3-v6.telia.net (2001:2000:3018:5::1)  41.915 ms  62.951 ms  39.543 ms
 9  edgecast-ic-147468-ldn-b3.c.telia.net (2001:2000:3080:378::2)  40.656 ms  
37.063 ms  37.683 ms
10  2606:2800:234:1922:15a7:17bf:bb7:f09 (2606:2800:234:1922:15a7:17bf:bb7:f09) 
 39.866 ms  39.443 ms  40.827 ms

Steinar Haug, AS 2116

AS 1668 BGP contact - possible prefix hijacking

[Ben Bartsch]

Hi:

Is there anyone here who can help us with a possible prefix hijacking
situation through ATDN?  Please contact me off list if you (or you know
somebody) that can help us.  I've tried the ATDN NOC and Vikas, but they
have been no help whatsoever.

The hijacked prefix appears to be sent to AS 1668, then propagated from
there.

Thanks.

Ben
AS 32440

Re: dhcpy6d - a MAC address aware DHCPv6 server

[Stephane Bortzmeyer]

On Tue, Nov 06, 2012 at 05:38:32AM -0800,
 Owen DeLong  wrote 
 a message of 68 lines which said:

> If you're on local subnet, why not pull the MAC address out of the
> received packet?

Because it requires access to raw sockets, which should not be
necessary for DHCP?

Re: p2p addresses for point-to-point connections with customers

[Tassos Chatzithomaoglou]

Roland, how do you handle customer requests regarding the remote management of 
their devices?
i.e. if the customer wants to do any kind of management (ssh, snmp) from 
outside his router, he must use our
infrastructure address (which is configured on his router) as a destination.
Generally, the customer might want to use this wan address for many other 
things which you shouldn't actually care,
since it's his router.

--
Tassos


Dobbins, Roland wrote on 06/11/2012 14:34:
> On Nov 6, 2012, at 7:31 PM, Tassos Chatzithomaoglou wrote:
>
>> Only specific types of icmp messages?
> That, plus the routing session (if any) with your customer, plus anything 
> else that's situationally-specific (GRE tunnel termination, etc.).
>
> ---
> Roland Dobbins  // 
>
> Luck is the residue of opportunity and design.
>
>  -- John Milton
>
>
>
>

Re: dhcpy6d - a MAC address aware DHCPv6 server

[Owen DeLong]

If you're on local subnet, why not pull the MAC address out of the
received packet?

Further, what happens to this when IPv4 goes away?

Owen

On Nov 5, 2012, at 12:14 AM, Henri Wahl  wrote:

> Hello World,
> like other people we had the problem that existing DHCPv6 servers do not
> evaluate the MAC address of clients, following RFC 3315. The IPv4
> clients already are managed via their MAC addresses so we wanted to use
> these identifiers for IPv6 too for our dualstack network.
> 
> At the end we had to write our own DHCPv6 server dhcpy6d which I want to
> present here to a larger audience. It runs on Linux, tested on Debian
> and CentOS. It gets the client MAC addresses from neighbor cache by
> calling "ip -6 neigh" and caches them itself, allowing to access the
> already working MAC-based IPv4 infrastructure. This obviously only works
> on the local subnet but might be worked around with several servers
> being connected via database storage of clients and leases.
> 
> Features are:
> - identifies clients by MAC address, DUID or hostname
> - generates addresses randomly, by MAC address, by range or by given ID
> - filters clients by MAC, DUID or hostname
> - assignes more than one address per client
> - allows to organize clients in different classes
> - stores leases in MySQL or SQLite database
> - client information can be retrieved from database or textfile
> - dynamically updates DNS (Bind)
> 
> We run it with ~500 clients without problems. I am interested if it
> would run in larger environments too. If not, how to make it running.
> Bugs and ideas how to improve it are welcome too.
> 
> Packages are not yet available but the Python code should run as is.
> 
> See further details at http://dhcpy6d.ifw-dresden.de
> 
> Best regards
> Henri Wahl
> 
> -- 
> Henri Wahl
> 
> IT Department
> Leibniz-Institut für Festkörper- u.
> Werkstoffforschung Dresden
> 
> tel. (03 51) 46 59 - 797
> email: h.w...@ifw-dresden.de
> http://www.ifw-dresden.de
> 
> Nagios status monitor for your desktop:
> http://nagstamon.ifw-dresden.de
> 
> IFW Dresden e.V., Helmholtzstraße 20, D-01069 Dresden
> VR Dresden Nr. 1369
> Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle
> 

Re: MTU issues s0.wp.com

[Timothy Morizot]

On Nov 6, 2012 6:35 AM, "Seth Mos"  wrote:
>
> Hi,
>
> Since about a week or so it's become impossible to reach wp.com content
over IPv6.
[snip]
> It looks like tunneled IPv6 users might be in hurt here.
>
> Is anyone else experiencing similar issues?

I've definitely had problems from my home network (HE tunnel) recently. I
hadn't had time to look into it yet -- too swamped at work. But the above
would be consistent with what I've seen.

Scott

Re: p2p addresses for point-to-point connections with customers

[Dobbins, Roland]

On Nov 6, 2012, at 7:31 PM, Tassos Chatzithomaoglou wrote:

> Only specific types of icmp messages?

That, plus the routing session (if any) with your customer, plus anything else 
that's situationally-specific (GRE tunnel termination, etc.).

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

MTU issues s0.wp.com

[Seth Mos]

Hi,

Since about a week or so it's become impossible to reach wp.com content 
over IPv6.


IPv4 content does work fine, using the IPv6 literal returns a 404 which 
is small enough to fit in a smaller 1480 byte MTU.


I have another test site that has a clean 1500 byte mtu and I can fetch 
the s0.wp.com page from there.


It looks like tunneled IPv6 users might be in hurt here.

Is anyone else experiencing similar issues?

My traceroute shows they are employing a CDN for s0.wp.com, so not 
everyone might be affected.


 7  asd2-rou-1022.NL.eurorings.net (2001:680:0:800f::291)  6.460 ms 
6.203 ms  6.188 ms
 8  asd2-rou-1044.eurorings.net (2001:680::134:222:85:63)  6.447 ms 
6.494 ms  6.495 ms
 9  adm-b5-link.telia.net (2001:2000:3080:6f::1)  6.818 ms  6.936 ms 
6.891 ms
10  ldn-b3-v6.telia.net (2001:2000:3018:5::1)  15.290 ms  27.481 ms 
15.380 ms
11  edgecast-ic-147468-ldn-b3.c.telia.net (2001:2000:3080:378::2) 
15.116 ms  15.174 ms  15.176 ms
12  2606:2800:234:1922:15a7:17bf:bb7:f09 
(2606:2800:234:1922:15a7:17bf:bb7:f09)  15.496 ms  15.327 ms  15.460 ms


Kind regards,

Seth

Re: p2p addresses for point-to-point connections with customers

[Tassos Chatzithomaoglou]

Having an iACL format like below, that means that i would have to add at least 
one extra "permit" entry before the
spoofing entries.

deny MARTIANS/BOGONS
deny SPOOFING
deny PROTOCOLS/PORTS
permit BGP-PEERINGS
permit TUNNELS
deny INFRASTRUCTURE
permit ANY

If that's indeed the case, what non-routing protocols do you allow from/to 
these type of addresses?
Only specific types of icmp messages?

--
Tassos

Dobbins, Roland wrote on 06/11/2012 14:05:
> On Nov 6, 2012, at 6:32 PM, Tassos Chatzithomaoglou wrote:
>
>> Do you filter them on your border routers (via iACLs)
> Yes.
>
>> and if yes, how?
> The same way you filter any other interface addresses in your iACLs.
>
> ---
> Roland Dobbins  // 
>
> Luck is the residue of opportunity and design.
>
>  -- John Milton
>

Re: p2p addresses for point-to-point connections with customers

[Dobbins, Roland]

On Nov 6, 2012, at 6:32 PM, Tassos Chatzithomaoglou wrote:

> Do you consider them infrastructure addresses or customer addresses?

They're infrastructure addresses.

> Do you put them in your IGP or in BGP?

You should treat them as you do your other infrastructure addresses (i.e., if 
you're null-routing them at the peering edge, or what-have-you).

> Do you filter them on your border routers (via iACLs)

Yes.

> and if yes, how?

The same way you filter any other interface addresses in your iACLs.

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

Indonesian ISP Moratel announces Google's prefixes

[Anurag Bhatia]

Another case of route hijack -
http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about



I am curious if big networks have any pre-defined filters for big content
providers like Google to avoid these? I am sure internet community would be
working in direction to somehow prevent these issues. Curious to know
developments so far.




Thanks.


-- 

Anurag Bhatia
anuragbhatia.com

Linkedin  |
Twitter|
Google+ 

p2p addresses for point-to-point connections with customers

[Tassos Chatzithomaoglou]

I've been trying hard to come up with a solution regarding this, but i haven't 
decided yet which one is the best.

>From the perspective of an ISP, how do you characterize the p2p addresses 
>given for a point-to-point connection to a)
customers with their own ASN b) customers without an ASN?

These are ip addresses configured on your router's border interface and on the 
customer's peer router interface (old
WAN-style), so they actually are both infrastructure and customer addresses.

So...
Do you consider them infrastructure addresses or customer addresses?
Do you put them in your IGP or in BGP?
Do you filter them on your border routers (via iACLs) and if yes, how?



-- 
Tassos

Re: dhcpy6d - a MAC address aware DHCPv6 server

[Stephane Bortzmeyer]

On Mon, Nov 05, 2012 at 09:14:54AM +0100,
 Henri Wahl  wrote 
 a message of 155 lines which said:

> - identifies clients by MAC address, DUID or hostname

Excellent, identification by MAC address was often requested. Thanks
for this software.

> like other people we had the problem that existing DHCPv6 servers do
> not evaluate the MAC address of clients, following RFC 3315.

I'm not convinced that it is RFC's fault. The only thing I find in RFC
3315 is (section 9) "DHCP servers use DUIDs to identify clients for
the selection of configuration parameters and in the association of
IAs with clients." I read it as "a compliant DHCPv6 server MUST
recognize DUID and identify clients this way" which does not logically
imply that it cannot identify clients by other means as well.