OVH datacenter SBG2 in Strasbourg on fire 🔥

[Fredy Kuenzler]

Very sad day for our colleagues at OVH AS16276 as they lost their datacenter 
SBG-2 in Strasbourg/France completly („everything is destroyed“) in a fire 🔥 
and the neighboring SBG1/SBG3/SBG4 at least temporary.

https://www.dna.fr/amp/faits-divers-justice/2021/03/10/strasbourg-important-incendie-dans-une-entreprise-situee-sur-un-site-seveso-au-port-du-rhin

--
Fredy Künzler

Init7 (Switzerland) Ltd.
Technoparkstrasse 5
CH-8406 Winterthur
https://www.init7.net/

Re: Zurich Data Center

[Fredy Kuenzler]

This one at Aargauerstasse 10 in Zurich is operated by the incumbent Swisscom, 
mainly for their own purpose. It‘s called «Zurich Herdern» with LEX code 
790ZHH, despite it‘s not a LEX in the classical sense. 

There is a similar one in another area of the city called «Zurich Binz» with 
the code 790ZHB.

We (Init7) along with some other carriers are present too in both, mainly for 
interconnection purpose. Strict rules for other carriers unlike in the carrier 
neutral sites of the ususal suspects (Equinix, e-shelter NTT, Interxion, 
green.ch...). For example: expect cross connects delivery times of at least 6 
to 8 weeks to other 3rd party carriers. It is not a regulated product but the 
process feels like.

They also sell space and power to 3rd party customers in 790ZHH (not carriers), 
commonly along with expensive telco services, but I‘m not too familiar with 
details. We have one or two customers there which decided not to buy only from 
the incumbent. Saying this: 790ZHH is somewhat carrier neutral but it‘s 
complicated.

Hope this helps.

--
Fredy Künzler

Init7 (Switzerland) Ltd.
Technoparkstrasse 5
CH-8406 Winterthur
https://www.init7.net/

> Am 01.02.2021 um 08:42 schrieb Rod Beck :
> 
> 
> Off list, what can someone tell me about the data center at 
> 
> Aargauerstrasse 10
> 
> 8048 Zürich
> 
> 
> Regards, 
> 
> Roderick. 
> 
> 
> 
> 
> Roderick Beck
> VP of Business Development
> United Cable Company
> www.unitedcablecompany.com
> New York City & Budapest
> rod.b...@unitedcablecompany.com
> Budapest: 36-70-605-5144
> NJ: 908-452-8183 
> 
> 

Re: Germany Long Haul Providers

[Fredy Kuenzler]

For Nuremberg specifically I suggest to ask Core Backbone and Noris.

From what I heard Gasline sold their Layer2 operations to EnBW if I recall 
correctly. I think Gasline has only DF left.

Re Eunetworks: I recommend to avoid them, unless you don‘t mind be taken to 
court for their own mistakes. No joke.

To get better answers or more regional suggestions try asking in the DENOG 
mailinglist.

--
Fredy Künzler

Init7 (Switzerland) Ltd.
Technoparkstrasse 5
CH-8406 Winterthur
https://www.init7.net/

> Am 06.01.2021 um 20:23 schrieb Karsten Thomann via NANOG :
> 
> 
> Depending on your specific needs the first I would think about are EUnetworks 
> and Gasline.
>  
> Regards
> Karsten
>  
> Am Mittwoch, 6. Januar 2021, 19:12:14 schrieb Rod Beck:
> > Looking for a niche provider - not one of the usual suspects like Colt or
> > GTT or Deutsche Telekom. A carrier with a dense German network hitting the
> > smaller cities like Nürnberg. Wholesale mentality. Gige, 10 and 100 gig
> > waves. DF.
> >
> > The big guys don't cut it.
> >
> > Regards,
> >
> > Roderick.
> >
> >
> > Roderick Beck
> >
> > VP of Business Development
> >
> > United Cable Company
> >
> > www.unitedcablecompany.com
> >
> > New York City & Budapest
> >
> > rod.b...@unitedcablecompany.com
> >
> > Budapest: 36-70-605-5144
> >
> > NJ: 908-452-8183
> >
> >
> > [1467221477350_image005.png]
>  

Re: Cogent sales reps who actually respond

[Fredy Kuenzler]

When they do their cold calls I tend to answer «Call again in 6 months, if you 
are still with Cogent then.» Most sales reps don‘t survive that long. #SCNR 

--
Fredy Kuenzler
Init7 (Switzerland) Ltd.
Technoparkstrasse 5
CH-8406 Winterthur
Switzerland

http://www.init7.net/


> Am 16.09.2019 um 15:30 schrieb Jon Sands :
> 
> The last time I dealt with them, it took a little over 3 months to get them 
> to turn up basic BGP service. To top it off the sales rep was fired in the 
> middle of our deployment. Cogent seems to have higher rep turnover than 
> anything else I've dealt with. Buckle up and have fun!
> 
>> On 9/15/2019 4:13 PM, n...@as37662.com n...@as37662.com wrote:
>> 
>> Hi fellow network operators,
>> 
>> Do any orgs here have experience with a good Cogent rep? The rep we got via 
>> Cogent's website is unresponsive to even basic questions. It feels like we 
>> are dealing with a bot and copy-pasted replies.
>> 
>> Thanks
>> Ruldu
>> 
> 
> -- 
> Jon Sands
> MFI Labs
> https://fohdeesha.com/
> 

Re: well-known Anycast prefixes

[Fredy Kuenzler]

Am 19.03.19 um 18:39 schrieb Bill Woodcock:
>> On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler  
>> wrote: I wonder whether anyone has ever compiled a list of 
>> well-known Anycast prefixes.
> 
> I don’t know of one.
> 
> It seems like a good idea.
> 
> BGP-multi-hop might be a reasonable way to collect them.
> 
> If others agree that it’s a good idea, and it’s not stepping on 
> anyone’s toes, PCH would be happy to host/coordinate.

Thanks for the effort, much appreciated.

Am 19.03.19 um 18:40 schrieb Joe Provo:
> I think one would want that internal and no rely upon someone else
> maintaining it.  You might check if Oracle followed up on the 
> Renesys/Dyn work documented: 
> https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf
> 
> ...where there were ~600 anycast v4 prefixes at the time.

That's a lot %-]

Maybe a well-known community (similar to RFC7999) could be defined and
every Anycast operator could tag his prefixes? That's likely a better
idea than manually maintain some list somewhere.

-- 
Fredy Kuenzler

Init7 (Switzerland) Ltd.
AS13030
Technoparkstrasse 5
CH-8406 Winterthur
Skype:   flyingpotato
Phone:   +41 44 315 4400
Fax: +41 44 315 4401
Twitter: @init7 / @kuenzler
http://www.init7.net/



signature.asc
Description: OpenPGP digital signature

well-known Anycast prefixes

[Fredy Kuenzler]

I wonder whether anyone has ever compiled a list of well-known Anycast
prefixes.

Such as

1.1.1.0/24
8.8.8.0/24
9.9.9.0/24
...

Might be useful for a routing policy such as "always route hot-potato".

PS. this mail is not intended to start a flame war of hot vs. cold
potato routing.

-- 
Fredy Kuenzler

Init7 (Switzerland) Ltd.
AS13030
Technoparkstrasse 5
CH-8406 Winterthur
Twitter: @init7 / @kuenzler
http://www.init7.net/



signature.asc
Description: OpenPGP digital signature

Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Fredy Kuenzler]

Is anyone else affected by a massive price increase for x-conns by
Telehouse Chelsea?

When we moved in a few years ago they were asking 150$, it changed to
200$ and now we are asked to pay 260$. That's 73% more. I don't think
inflation is that high in the United states.

I get the impression that they feel comfortable enough to abuse their
position. When we complained they simply said 'you may consider to
cancel the contract'.

Of course they don't provide any better service, in fact, the service
quality is commonly indirectly proportional to the price at most 'big
names'. #rant

I suggest to anyone considering to buy colocation space in NYC (or
elsewhere) not to choose Telehouse, unlike a few years ago.

-- 
Fredy Kuenzler
Init7 (Switzerland) Ltd.



signature.asc
Description: OpenPGP digital signature

Re: Equinix IX Port Moves

[Fredy Kuenzler]

On 10.06.2016 16:00, Mike Hammett wrote:
> Who has moved an Equinix IX port? We're told that it's a full 
> cancellation, re-order, re IPs, re-peering, etc.
> 
> Can anyone lend any input either way on that?

Same issue here. Super complicated. I'm tempted to stop the process
after the first step.

-- 
Fredy Kuenzler

-
Fiber7. No Limits.
https://www.fiber7.ch
-

Init7 (Switzerland) Ltd.
AS13030
St.-Georgen-Strasse 70
CH-8400 Winterthur
Skype:   flyingpotato
Phone:   +41 44 315 4400
Fax: +41 44 315 4401
Twitter: @init7 / @kuenzler
http://www.init7.net/

Re: Cogent - Google - HE Fun

[Fredy Kuenzler]

This would work for those which are using IPv6 transit from Cogent.

For anyone else which is using IPv6 transit from Hurricane Electric and some 
other suppliers such as L3 or NTT: to set the community 'do not announce to 
Cogent' only on every other transit but HE would help to isolate Cogent without 
much collateral damage. It would support Google/HE's position. And maybe help 
to bring back Cogent onto a cooperative track, after all.

--
Fredy Kuenzler
Init7 (Switzerland) Ltd.
St.-Georgen-Strasse 70
CH-8400 Winterthur
Switzerland

http://www.init7.net/


> Am 10.03.2016 um 23:19 schrieb Matthew D. Hardeman :
> 
> I have contemplated whether such mechanisms matter to Cogent, etc.
> 
> I’m inclined to think that if Google is willing to pull the routes and they 
> still don’t blink, then certainly us smaller shops aren’t going to impact 
> them…
> 
> However…  If enough prefixes disappear from the _apparent_ Cogent table as 
> viewed by outsiders, this may ultimately impact their sales of new 
> interconnection….
> 
> For those of us multihomed with Cogent and other transit providers on IPv6 
> there is a less drastic way to impact the perceived value of Cogent’s IPv6 
> routing table to outsiders and especially to Cogent’s peers — and one that 
> still doesn’t negatively impact the single-home customers of Cogent:
> 
> "set community 174:3000" on your IPv6 advertisement to Cogent.  This will 
> constrain the advertisement to Cogent and Cogent’s customers only.  For good 
> measure, prepend your own AS to this advertisement at least a couple of 
> times, potentially discouraging even Cogent customers who see the route from 
> using it if they have other transit.  It will prevent the path via Cogent 
> being selected by Cogent IPv6 peers versus your other transit providers.
> 
> 
>> On Mar 10, 2016, at 3:47 PM, Fredy Kuenzler  wrote:
>> 
>> Am 10.03.2016 um 22:25 schrieb Damien Burke :
>>> Anyone who is multihomed with cogent ipv6 in their mix should shutdown 
>>> their IPv6 bgp session. Let’s see if we can make their graph freefall.
>> 
>> 
>> Alternative:
>> 
>> set community [do not announce to Cogent]
>> 
>> *SCNR*
> 

Re: AW: Cogent - Google - HE Fun

[Fredy Kuenzler]

Am 10.03.2016 um 22:25 schrieb Damien Burke :
> Anyone who is multihomed with cogent ipv6 in their mix should shutdown their 
> IPv6 bgp session. Let’s see if we can make their graph freefall.


Alternative:

set community [do not announce to Cogent]

*SCNR*

Microsoft Geo-IP Admin needed

[Fredy Kuenzler]

Can anyone point me to a Microsoft Geo-IP admin? Their Geo-IP for
live.com/outlook.com seems to be rather outdated.

We get complaints for 85.195.208.0/20 and 85.195.224.0/19, pointing to
Antarctic instead of Switzerland. Any commercial Geo-IP shows correct
information, but Office product activation fails.

Twitter thread:
https://twitter.com/fiber7_ch/status/630880605971025920

Offlist response is fine.

Thanks.

-- 
Fredy Kuenzler

-
Fiber7. No Limits.
https://www.fiber7.ch
-

Init7 (Switzerland) Ltd.
AS13030
St.-Georgen-Strasse 70
CH-8400 Winterthur
Skype:   flyingpotato
Phone:   +41 44 315 4400
Fax: +41 44 315 4401
Twitter: @init7 / @kuenzler
http://www.init7.net/



signature.asc
Description: OpenPGP digital signature

Re: How long will it take to completely get rid of IPv4 or will it happen at all?

[Fredy Kuenzler]

Am 27.06.2015 um 16:38 schrieb Bob Evans:
> We have a greater supply for packets to travel than we do for
> addresses required to move packets. Do you know how many packets a
> single IP address can generate or utilize, if it was attached too
> "The World's Fastest Internet" in someplace like Canadaland or Sweden
> on init7's Fiber7 ?

Thanks for mentioning Fiber7, which is actually available in
Switzerland, not Sweden. And every Fiber7 customer gets a /48, too.

-- 
Fredy Kuenzler

-
Fiber7. No Limits.
https://www.fiber7.ch
-

Init7 (Switzerland) Ltd.
AS13030
St.-Georgen-Strasse 70
CH-8400 Winterthur
Skype:   flyingpotato
Phone:   +41 44 315 4400
Fax: +41 44 315 4401
Twitter: @init7 / @kuenzler
http://www.init7.net/



signature.asc
Description: OpenPGP digital signature

Re: Connectivity issue between Verizon and Amazon EC2 (NTT issue?)

[Fredy Kuenzler]

Am 23.07.2014 09:23, schrieb Matthew Petach:
> So, Verizon is saying that Level3 into them is congested, NTT into
> them is congested...sounds like there might be a bit of a trend
> happening here.

They (Verizon) should issue a list of those which are _not_ congested. I
guess the list would be rather short...

*SCNR*

-- 
Fredy Kuenzler

-
Fiber7. No Limits.
https://www.fiber7.ch
-

Init7 (Switzerland) Ltd.
AS13030
St.-Georgen-Strasse 70
CH-8400 Winterthur
Skype:   flyingpotato
Phone:   +41 44 315 4400
Fax: +41 44 315 4401
Twitter: @init7 / @kuenzler
http://www.init7.net/



signature.asc
Description: OpenPGP digital signature

Re: Survey on Internet Disputes.

[Fredy Kuenzler]

Am 23.03.2014 05:40, schrieb Kshitiz Verma:
> As claimed in http://www.cs.columbia.edu/~misra/news/CD070113.pdf , 
> 500 to 1000 de-peering happens on a daily basis today.

I suppose this is just by technical incapabilities. People leak
prefixes, hit max-pref limters, forget to clear sessions or don't bother
increasing limits, they migrate gear from Cisco to Brocade or Juniper
and cannot recover encrypted MD5 passwords... or management decisions
decide to pull from an exchange.

I don't consider this "de-peering" a peering dispute or an offensive
act. The majority of vanished BGP adjacencies are due to laziness or
technical limitations.

-- 
Fredy Kuenzler

Init7 (Switzerland) Ltd.
AS13030
St. Georgen-Strasse 70
CH-8400 Winterthur
Skype:   flyingpotato
Phone:   +41 44 315 4400
Fax: +41 44 315 4401
Twitter: @init7 / @kuenzler
http://www.init7.net/



signature.asc
Description: OpenPGP digital signature

Re: Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond

[Fredy Kuenzler]

Constantine,

Please mail me offlist if Init7 can be of any help to resolve the case.

--
Fredy Kuenzler
Init7 (Switzerland) Ltd.
St.-Georgen-Strasse 70
CH-8400 Winterthur
Switzerland

http://www.init7.net/


> Am 30.11.2013 um 08:30 schrieb "Constantine A. Murenin" :
> 
> Dear NANOG@,
> 
> I'm not exactly sure how else I can get he.net's attention, because I've been 
> experiencing congestion issues between my dedi and Indiana for a couple of 
> months now, all due to he.net's poor transit, as it turns out.  The issue was 
> complicated by the fact that the routes are asymmetric, and it appears as if 
> the traffic loss is going on somewhere where there is none at all.
> 
> I will just provide the data, and people can make their own conclusions, any 
> insights are welcome.
> 
> During all of this, since some late September 2013, all 4 networks involved 
> have been contacted -- hetzner, init7, he.net, indiana; all except for he.net 
> have responded and did troubleshooting.
> 
> After pressing the lack of any kind of response from he.net, all they did was 
> ask for a customer number, and that was back in September.  I have not heard 
> from their NOC@ ever since, with requests left unanswered, sans the "we have 
> received your request" autoreply.
> 
> Interestingly enough, only some of their Europe-to-US routes are blatantly 
> congested and have very obvious packet loss (often making ssh unusable), 
> whereas others appear to be doing just fine (at least, not losing packets and 
> not experiencing jitter, and the increased latency).  E.g. IPv6 routes don't 
> appear affected, for example.  IPv4 addresses in North America that are 
> announced directly from AS6939 (e.g. Linode in Fremont) don't appear 
> affected, either.  But the multi-homed indiana.edu and wiscnet.net are 
> affected.  The single-homed ntp1.yycix.ca is affected, too.  Probably other 
> customers are affected as well.
> 
> Where's the end to this?
> 
> Or is the ongoing 0.5+% traffic loss, and the 140+ms avg latency on a 114ms 
> route, with random spikes and jitter in certain hours of the day (generally 
> around midnight ET), every day for several weeks or even months, an 
> acceptable practice?
> 
> 
> 
> From hetzner.de through he.net:
> 
> 
> Cns# date ; mtr --report{,-wide,-cycles=600} --interval 0.1 --order "SRL 
> BGAWV" -4 c.indiana.edu ; date
> Fri Nov 29 21:06:17 PST 2013
> HOST: Cns???   Snt   Rcv Loss% Best Gmean 
>   Avg  Wrst StDev
>  1.|-- static.??.???.4.46.clients.your-server.de600   600  0.0%  0.5   
> 1.0   1.3   4.9   1.1
>  2.|-- hos-tr1.juniper1.rz13.hetzner.de 600   600  0.0%  0.1   
> 0.2   1.9  66.0   7.6
>  3.|-- core21.hetzner.de600   600  0.0%  0.2   
> 0.2   0.2   5.8   0.4
>  4.|-- core22.hetzner.de600   600  0.0%  0.2   
> 0.2   0.2  19.4   1.2
>  5.|-- core1.hetzner.de 600   600  0.0%  4.8   
> 4.8   4.8  13.2   0.7
>  6.|-- juniper1.ffm.hetzner.de  600   600  0.0%  4.8   
> 4.8   4.8  27.4   1.4
>  7.|-- 30gigabitethernet1-3.core1.ams1.he.net   600   600  0.0% 11.2  
> 14.0  14.6  48.7   4.5
>  8.|-- 10gigabitethernet1-4.core1.lon1.he.net   600   600  0.0% 18.2  
> 19.6  19.9  53.9   4.1
>  9.|-- 10gigabitethernet10-4.core1.nyc4.he.net  600   599  0.2% 87.0 
> 116.1 116.7 145.7  12.4
> 10.|-- 100gigabitethernet7-2.core1.chi1.he.net  600   597  0.5% 106.6 
> 135.4 136.1 192.0  13.3
> 11.|-- ???  600 0 100.0  0.0   
> 0.0   0.0   0.0   0.0
> 12.|-- et-11-0-0.945.rtr.ictc.indiana.gigapop.net   600   594  1.0% 113.3 
> 139.3 139.7 166.1  11.4
> 13.|-- xe-0-3-0.11.br2.ictc.net.uits.iu.edu 600   596  0.7% 113.2 
> 139.8 140.3 177.3  12.0
> 14.|-- ae-0.0.br2.bldc.net.uits.iu.edu  600   595  0.8% 114.2 
> 140.1 140.6 183.2  11.8
> 15.|-- ae-10.0.cr3.bldc.net.uits.iu.edu 600   597  0.5% 114.3 
> 140.3 140.8 165.0  11.5
> 16.|-- c.indiana.edu600   597  0.5% 114.7 
> 140.7 141.1 161.6  11.4
> Fri Nov 29 21:08:52 PST 2013
> 
> 
> Cns# unbuffer hping --icmp-ts c.indiana.edu | \
> perl -ne 'if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {($s, $p) = ($1, $2);} \
> if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {($o, $r, $t) = ($1, $2, $3);} \
> if (/tsrtt=(\d+)/) { \
> print $s, "\t", $p, "\t", $1, " = ", $r - $o, " + ", $o + $1 - $t, "\n"; }'
> 0   143.5   144 = 87 + 57
> 1   125.5   126 = 69 + 57
> 2   143.6   14

Re: What routers do folks use these days?

[Fredy Kuenzler]

Am 29.11.2013 06:37, schrieb Jawaid Desktop:
> We're a service provider, and we have a network full of Cat6509's.
> We are finding that we are outgrowing them from the standpoint of
> their ability to handle lots of large routing tables. Obviously
> their switching capability is still superb but one of them with 20
> peers is starting to groan a bit and RAM is going to be an issue
> soon.
> 
> What do people use these days? Our backbone needs in the next 2-3
> years are going to be sub-100Gbps.

Check the Brocade MLXe series. We (Init7 / AS13030) are using them and
the previous XMR series for years and are happy with it. CLI is
Cisco-look-and-feel, the software tree has a clear structure (unlike
Cisco with hundreds of versions) and the TAC is willing to ssh into your
gear to assist.

-- 
Fredy Kuenzler

Init7 (Switzerland) Ltd.
AS13030
St. Georgen-Strasse 70
CH-8400 Winterthur
Twitter: @init7 / @kuenzler
http://www.init7.net/



signature.asc
Description: OpenPGP digital signature

Re: AS12715 (Jazz Telecom S.A.) Peering contact

[Fredy Kuenzler]

Am 26.11.2012 11:01, schrieb Network Department:

Could somebody provide me peering contact for AS12715 (Jazz Telecom
S.A.)? I see they have OPEN peering policy at AMS-IX and peering contact
b...@jazztel.com but there are no replies from this email.


The address you mentioned is actually very responsive to me...

--
Fredy Künzler

Init7 (Switzerland) AG
AS13030
Elias-Canetti-Strasse 7
CH-8050 Zürich
Skype:   flyingpotato
Phone:   +41 44 315 4400
Fax: +41 44 315 4401
Twitter: @init7
http://www.init7.net/

Re: In Need of 10GbE Optics @AMS4

[Fredy Kuenzler]

I guess the Flexoptix experts are able to adress this problem... 
http://www.flexoptix.net/

HTH, Fredy / Init7

Von meinem iPhone gesendet

Am 18.11.2012 um 05:00 schrieb Pete Ashdown :

> I don't have the quantity you need, but this reminded me that I'm in
> need of a reliable supplier of CWDM 40KM XFP 10GbE optics.  Specifically
> 1310nm, but I'll need other wavelengths soon.  These things seem to be
> manufactured by elves.  I can't find a reliable supplier anywhere.  Can
> anyone help?
> 

Level3 (3356/3549) changes routing policy

[Fredy Kuenzler]

From my observation Level3 has recently changed their routing policy. It 
seems that 3356 always prefers customer prefixes of 3549, regardless of the 
AS path length. Example (seen from 3356):


3549_13030_[Customer1]_[Customer2]

is preferred over

2914_[Customer1]_[Customer2]

Considering that both 2914 and 3549 are peers of 3356, and 13030 is a 
customer of 3549, 3356 seems to give higher local-pref on the longer 
AS-path, likely to increase traffic and revenue of their sister network 3549.


Certainly it's common practice to overrule the BGP4 default behaviour, and 
widely used by smaller networks.


Still I'm surprised that it happened obviously rather undetected, at least, 
to my knowledge, Level3 did implement it silently and hasn't published an 
official statement or customer announcement, which I think, would have been 
fair, at least.


Considering that Level3 3356 and 3549 are by far the largest networks 
globally this decision must have a large impact on traffic flows and, of 
course money flows.


Maybe the BGP monitoring experts (aka Renesys et al) can shed some light?

--
Fredy Künzler
Init7 / AS13030

Re: French Regulator to ask all your information about your Peering

[Fredy Kuenzler]

Am 30.03.2012 23:20, schrieb Raphael MAUNIER:

Sorry Fredy, but you are living in a care bear world ?

Do you think some people build an intense national backbone

You were @GPF last week, when Martin asked : Who want this to be
regulated ? And Who want to have his peering controled ? why you didn't
raise your hand ?

In my memory, no one did.

I didn't get my peering with France Telecom, so I get in touch with them
and I have a fair contrat and I have a good backbone quality. In my
market, I need for now direct access to them, and that's life.

My business is not made on the "wishes" to have free peering with my
incumbent.


I'm not saying I want this regulated, in fact I prefer to have it as it is
and keep authorities out of the game. That's why I didn't raise my hand.

But: Fact is that competition commissions and regulators are investigating
against incumbents and such. They could have avoided this easily if they
would have been more cooperative and keep their policy less restrictive. I
don't blame anyone who is filing against someone who is abusing market power.

Now, obviously, the French regulator sees the trouble and trys to understand
and 'regulate' it the way they do it usually. From our perspective certainly
not a good way, but why blaming the regulator? Blame those which made it all
happen! Read: the restrictive incumbents which put obstacles in the way of
everyone else.

You've choosen to pay to get obstacles away. Others prefer to call the
court. And probably the majority suffers in silence, especially the
countless broadband users which actually pay our salaries and make our
industry happening. Regulators should primarily care about those, and
therefore it's good that the French regulator actually made a move, however
arguably in the wrong direction.

F.

Re: French Regulator to ask all your information about your Peering

[Fredy Kuenzler]

Am 30.03.2012 20:21, schrieb Raphael MAUNIER:

This is now the end. The French regulator ( Arcep ) is now asking all the
people with an ASN in France ( with a L33 license ) to get all their
information on their peering.

The Arcep claim it's for the "net neutrality" and still don't understand
it works because it's self regulated.


I suggest to stop whining. Why do we see regulators stepping in? Simply
because some networks (mainly, but not only incumbents) abused their market
power. It doesn't surprise me that it starts in France, as it's a common
knowledge that the French incumbent has only one default answer, which is 'no'.


[...]

You have to give them information twice a year

We ( @Neo Telecoms ) and other folks in France will probably setup
something with other carriers ( I already had some discussion with some
of you ) to talk to them on a single voice.


Much appreciated. They certainly will come to some automated solution where
they can generate reports on BGP feeds we send to their route collector.
Everyone with proper route tagging should be ok and live happily.

If, after all, the French incumbent has trouble to find an appropriate
explanation for the regulator to justify their policy, so be it...

Re: Please help our simple bgp

[Fredy Kuenzler]

Am 31.01.2012 04:06, schrieb Joel Maslak:

There are several ways to handle this is, if you have at least two
/24s of space.

Let's say you just have two /24s, both part of the same /23.

[...]


Sad to see that deaggregation is still propagated to handle this issue. As a 
matter of fact deaggregation pollutes the global BGP table with more than 
40% of rubbish, mainly caused by this silly type of traffic engineering. See 
the weekly routing table report or the CIDR report:



Analysis Summary


BGP routing table entries examined:  394446
Prefixes after maximum aggregation:  169250
Deaggregation factor:  2.33
Unique aggregates announced to Internet: 191523


There are many smarter ways to manage unbalanced links. See my slides 
presented on various occations (page 31 to 48) which describes the 
disadvantages and collateral damage of deaggregation:


http://www.swinog.ch/meetings/swinog23/p/03_BGP-traffic-engineering-considerations-v0.2.pdf

HTH,

--
Fredy Künzler
Init7 / AS13030

Minimum Allocation Size by RIRs (IPv4)

[Fredy Kuenzler]

I'm trying to compile a comprehensive and up-to-date list of Minimum 
Allocation Sizes by the various RIRs. Any hint would be appreciated. I have 
so far:


ARIN:  https://www.arin.net/knowledge/ip_blocks.html

APNIC: 
http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations 
(seems that they have recently changed from /22 to /24, which is not too 
helpful...)


RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5

Nothing found for AFRINIC and LACNIC yet, and legacy space, too.

--
Fredy Künzler

Init Seven AG
AS13030
Elias-Canetti-Strasse 7
CH-8050 Zürich
Skype:   flyingpotato
Phone:   +41 44 315 4400
Fax: +41 44 315 4401
Twitter: @init7
http://www.init7.net/

Re: IPV6 over a PPTP Link

[Fredy Kuenzler]

Am 15.09.2011 18:24, schrieb Meftah Tayeb:

can i ofer ipv6 addresses through a PPTP connection using cisco ?
if yes, how please ?


These slides were presented on various conferences showing native v6 via 
L2TP. While you asked for PPTP, I thought to point to the link anyway, maybe 
the slides are useful.


http://www.blogg.ch/uploads/Native-IPv6-via-xdsl-how-to-tweak-your-LNS_v0.41.pdf

Fredy Künzler
Init7 / AS13030

Re: experience with equinix exchange

[Fredy Kuenzler]

Am 29.11.2010 20:44, schrieb Richard A Steenbergen:

Uhh... Reality check, with the S&D acquisition Equinix controls the VAST
majority of the IX traffic in the US. [...]


I was actually quite surprised that, when the merger of Equinix and S&D was
announced, no competition commission woke up and regulated it. An order
could have been for example the independence of the former PAIX exchanges.

I don't think in Europe a merger of AMSIX, LINX and DECIX would be accepted
by the EU competition commission. Though these three exchanges are not for
profit, which is, of course, another background.

Fredy Künzler
Init7 / AS13030

Re: Prefix 120.29.240.0/21

[Fredy Kuenzler]

Am 17.11.2010 10:19, schrieb Fredy Kuenzler:

We see a number of session towards downstreams flaps obviously caused by
prefix 120.29.240.0/21, originated by AS45158, transited by AS4739 (see
below).

#sh ip bgp 120.29.240.0
Number of BGP Routes matching display condition : 4
Status codes: s suppressed, d damped, h history, * valid, > best, i
internal Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop   MED LocPrf Weight Path
*>i 120.29.240.0/21 206.223.143.99 21  1500
4739 45158 {64512 64514 64516 64519 64521 64522 64525 64526 64528 64529
64530 64535 64537 64538 64541 64542 64543 64544 64545 64546 64547 64548
64549 64552 64553 64556 64557 64560 64561 64562 64564 64565 64566 64568
64569 64570 64574 64575 64576 64577 64578 64580 64582 64583 64584 64588
64593 64598 64599 64601 64602 64605 64610 64611 64620 64621 65397 65398
65470 65471 65472 65473 65474 65479 65480 65484 65485 65490 65502 65505
65511 65514 65523 65524 65528 65534 65609} ?


After some investigation I can post a summary of the incident.

At appx. 9:33 CET we saw the first flaps, affecting most of our downstreams, 
with Cisco and Juniper routers. Our backbone, based on Brocade XMR, was not 
affected, apart from the number of BGP updates which caused some CPU load.


Ironically the incident prefix got picked up by a Cisco edge router, and the 
session to the peer (AS4739) where the prefix got injected didn't crash either.


We filtered the evil prefix, and then the systems became stable again.

Meanwhile AS4739 shut down the BGP session with the originator AS45158 
(thanks MMC).


The propagation itself of the originator is rather uncommon, I'd say, as we 
can see, it's a BGP confederation of not less than 77 private AS numbers. 
Don't know for what it should be useful...


We asked some customers what gear they are running, and here is a short 
compilation - all these systems were affected by the BGP flaps:


- Cisco 2821 - c2800nm-advipservicesk9-mz.124-20.T4
- Cisco 2821 - c2800nm-advipservicesk9-mz.124-24.T1.bin
- Cisco ASR1002F - asr1000rp1-adventerprisek9.03.01.01.S.150-1.S1.bin
- Juniper MX480 - junos 10.0R3.10

We couldn't observe flaps of Quagga. Also not one single iBGP session was 
affected within our Brocade / Cisco network.


Best regards,

Fredy Kuenzler
Init7 / AS13030

Prefix 120.29.240.0/21

[Fredy Kuenzler]

We see a number of session towards downstreams flaps obviously caused by 
prefix 120.29.240.0/21, originated by AS45158, transited by AS4739 (see below).


Best regards,

Fredy Kuenzler
Init7 / AS13030



#sh ip bgp 120.29.240.0
Number of BGP Routes matching display condition : 4
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
NetworkNext HopMEDLocPrf Weight Path
*>i 120.29.240.0/21206.223.143.99  21 1500  4739 45158 
{64512 64514 64516 64519 64521 64522 64525 64526 64528 64529 64530 64535 
64537 64538 64541 64542 64543 64544 64545 64546 64547 64548 64549 64552 
64553 64556 64557 64560 64561 64562 64564 64565 64566 64568 64569 64570 
64574 64575 64576 64577 64578 64580 64582 64583 64584 64588 64593 64598 
64599 64601 64602 64605 64610 64611 64620 64621 65397 65398 65470 65471 
65472 65473 65474 65479 65480 65484 65485 65490 65502 65505 65511 65514 
65523 65524 65528 65534 65609} ?
*i  120.29.240.0/21206.223.143.99  21 1500  4739 45158 
{64512 64514 64516 64519 64521 64522 64525 64526 64528 64529 64530 64535 
64537 64538 64541 64542 64543 64544 64545 64546 64547 64548 64549 64552 
64553 64556 64557 64560 64561 64562 64564 64565 64566 64568 64569 64570 
64574 64575 64576 64577 64578 64580 64582 64583 64584 64588 64593 64598 
64599 64601 64602 64605 64610 64611 64620 64621 65397 65398 65470 65471 
65472 65473 65474 65479 65480 65484 65485 65490 65502 65505 65511 65514 
65523 65524 65528 65534 65609} ?
*i  120.29.240.0/21206.223.143.99  21 1500  4739 45158 
{64512 64514 64516 64519 64521 64522 64525 64526 64528 64529 64530 64535 
64537 64538 64541 64542 64543 64544 64545 64546 64547 64548 64549 64552 
64553 64556 64557 64560 64561 64562 64564 64565 64566 64568 64569 64570 
64574 64575 64576 64577 64578 64580 64582 64583 64584 64588 64593 64598 
64599 64601 64602 64605 64610 64611 64620 64621 65397 65398 65470 65471 
65472 65473 65474 65479 65480 65484 65485 65490 65502 65505 65511 65514 
65523 65524 65528 65534 65609} ?
*   120.29.240.0/2177.67.76.2371546   1500  3257 7473 7474 
9300 45158 i

   Last update to IP routing table: 0h25m47s, 1 path(s) installed:
   Route is advertised to 1 peers:
213.144.128.180(13030)

NYCX (New York City Exchange) contact wanted

[Fredy Kuenzler]

Anyone in charge of the exchange plattform in New York formerly known as 
NYCX (New York City Exchange), managed by NAC.net? Please contact me offlist.


(Yes we are still plugged and there is some traffic flowing ...)

Many thanks,
Fredy

Re: IPv6 Addressing Help

[Fredy Kuenzler]

Hi,

Chris Gotstein schrieb:
We are a small ISP that is in the process of setting up IPv6 on our 
network.  We already have the ARIN allocation and i have a couple routers

and servers running dual stack.  Wondering if someone out there would be
willing to give me a few pointers on setting up my addressing scheme? 
I've been mulling over how to do it, and i think i'm making it more 
complicated than it needs to be.  You can hit me offlist if you wish to 
help.  Thanks.


I did some presentations in the past ~12 to 18 months about v6 for
v4-cluefuls ... the slides have been evolved over time, still way from being
perfect, but it contains some examples which have been proven useful for
some, at least.

http://www.blogg.ch/uploads/IPv6-best-practice.pdf

HTH,

Fredy Künzler, Init7

Re: Recommendation of Tools

[Fredy Kuenzler]

Lee, Steven (NSG Malaysia) schrieb:

Hi all, do you have any recommended tools that can measure
latency/delay hop by hop basis? Preferable the tools can measure the
running (live) traffic.


Try Smokeping for long-term latency stats: http://oss.oetiker.ch/smokeping/

Fredy

Re: McColo: Are the 'Lights On" at Telia?

[Fredy Kuenzler]

Paul Ferguson schrieb:

Thanks to some good folks in Telia, McColo has been de-peered
(again):

  26780 MCCOLO - McColo Corporation

Adjacency: 1  Upstream: 1  Downstream: 0
Upstream Adjacent AS list
  AS1299  TELIANET TeliaNet Global Network

NOT Announced

This AS is not currently used to announce prefixes in the global 
routing table, nor is it used as a visible transit AS.


Prefixes added and withdrawn by this origin AS in the past 7 days.

  - 208.66.192.0/22 Withdrawn
  - 208.72.168.0/21 Withdrawn
  - 208.72.173.0/24 Withdrawn


I was wondering why I still saw routes from McColo AS26780, and I 
noticed that we picked up the routes via the Any2 LAX routeserver. They 
still seem to be connected to Any2 LAX, even though they are no longer 
listed. I applied now filters and set the community 19996:26780 to avoid 
the annoucement of our routes towards them.


Maybe someone at CRG West could pull their plug, too.

--
Fredy Künzler
Init Seven AG, AS13030

Re: EFF tool to check bandwidth throttling

[Fredy Kuenzler]

Gadi Evron schrieb:

Story is here:
http://www.webmonkey.com/blog/Switzerland%3A_EFF_Software_Helps_Track_ISP_Bandwidth_Throttling 


The tool is called... Switzerland.


For the Swiss it's kinda strange ... and, the initial version was 
released on Aug 1st, which is in fact the Swiss national day. Coincidence?


F.

Re: AS 54271

[Fredy Kuenzler]

Patrick W. Gilmore schrieb:

On Jul 13, 2008, at 1:01 PM, Marshall Eubanks wrote:


As of this morning, I am seeing BGP from AS 54271


Maybe someone mistyped "65271"? Which is still bad, but not at bad
(IMHO).


Interestingly, AS54271 is the last # of an unassigned block:


46080-47103Assigned by ARIN whois.arin.net2008-03-27
47104-48127Assigned by RIPE NCC whois.ripe.net2008-04-07
48128-54271Unassigned
54272-64511Reserved by the IANA
64512-65534Designated for private use (Allocated to the IANA)
65535  Reserved


http://www.iana.org/assignments/as-numbers

F.