Re: MTU to CDN's

[Mikael Abrahamsson]

On Thu, 18 Jan 2018, Michael Crapse wrote:


I don't mind letting the client premises routers break down 9000 byte
packets. My ISP controls end to end connectivity. 80% of people even let
our techs change settings on their computer, this would allow me to give
~5% increase in speeds, and less network congestion for end users for a one
time $60 service many people would want. It's also where the internet
should be heading... Not to beat a dead horse(re:ipv6 ) but why hasn't the
entire internet just moved to 9000(or 9600 L2) byte MTU? It was created for
the jump to gigabit... That's 4 orders of magnitude ago. The internet
backbone shouldn't be shuffling around 1500byte packets at 1tbps. That
means if you want to layer 3 that data, you need a router capable of more
than half a billion packets/s forwarding capacity. On the other hand, with
even just a 9000 byte MTU, TCP/IP overhead is reduced 6 fold, and
forwarding capacity needs just 100 or so mpps capacity. Routers that
forward at that rate are found for less than $2k.


As usual, there are 5-10 (or more) factors playing into this. Some, in 
random order:


1. IEEE hasn't standardised > 1500 byte ethernet packets
2. DSL/WIFI chips typically don't support > ~2300 because reasons.
3. Because 2, most SoC ethernet chips don't either
4. There is no standardised way to understand/probe the L2 MTU to your 
next hop (ARP/ND and probing if the value actually works)

5. PMTUD doesn't always work.
6. PLPMTUD hasn't been implemented neither in protocols nor hosts 
generally.
7. Some implementations have been optimized to work on packets < 2000 
bytes and actually has less performance than if they have to support 
larger packets (they will allocate 2k buffer memory per packet), 9k is 
ill-fitting across 2^X values
8. Because of all above reasons, mixed-MTU LAN doesn't work, and it's 
going to be mixed-MTU unless you control all devices (which is typically 
not the case outside of the datacenter).
9. The PPS problem in hosts and routers was solved by hardware offloading 
to NICs and forwarding NPUs/ASICs with very high lookup speeds where PPS 
no longer was a big problem.


On the value to choose for "large MTU", 9000 for edge and 9180 for core is 
what I advocate, after non-trivial amount of looking into this. All major 
core routing platforms work with 9180 (with JunOS only supporting this 
after 2015 or something). So if we'd want to standardise on MTU that all 
devices should support, then it's 9180, but we'd typically use 9000 in RA 
to send to devices.


If we want a higher MTU to be deployable across the Internet, we need to 
make it incrementally deployable. Some key things to achieve that:


1. Get something like 
https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 implemented.
2. Go to the IETF and get a document published that advises all protocols 
to support PLMTUD (RFC4821)


1 to enable mixed-MTU lans.
2 to enable large MTU hosts to actually be able to communicate when PMTUD 
doesn't work.


With this in place (wait ~10 years), larger MTU is now incrementally 
deployable which means it'll be deployable on the Internet, and IEEE might 
actually accept to standardise > 1500 byte packets for ethernet.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: MTU to CDN's

[Michael Crapse]

I don't mind letting the client premises routers break down 9000 byte
packets. My ISP controls end to end connectivity. 80% of people even let
our techs change settings on their computer, this would allow me to give
~5% increase in speeds, and less network congestion for end users for a one
time $60 service many people would want. It's also where the internet
should be heading... Not to beat a dead horse(re:ipv6 ) but why hasn't the
entire internet just moved to 9000(or 9600 L2) byte MTU? It was created for
the jump to gigabit... That's 4 orders of magnitude ago. The internet
backbone shouldn't be shuffling around 1500byte packets at 1tbps. That
means if you want to layer 3 that data, you need a router capable of more
than half a billion packets/s forwarding capacity. On the other hand, with
even just a 9000 byte MTU, TCP/IP overhead is reduced 6 fold, and
forwarding capacity needs just 100 or so mpps capacity. Routers that
forward at that rate are found for less than $2k.

On 18 January 2018 at 23:31, Vincent Bernat  wrote:

>  ❦ 18 janvier 2018 22:06 -0700, Michael Crapse  :
>
> > Why though? If i could get the major CDNs all inside my network willing
> to
> > run 9000 byte packets, My routers just got that much cheaper and less
> > loaded. The Routing capacity of x86 is hindered only by forwarding
> > capacity(PPS), not data line rate.
>
> Unless your clients use a 9000-byte MTU, you won't see a difference but
> you'll have to deal with broken PMTUD (or have your routers fragment).
> --
> Many a writer seems to think he is never profound except when he can't
> understand his own meaning.
> -- George D. Prentice
>

Re: MTU to CDN's

[Vincent Bernat]

 ❦ 19 janvier 2018 08:53 +1000, George Michaelson  :

> if I was an ISP (Im not) and a CDN came and said "we want to be inside
> you" (ewww) why wouldn't I say "sure: lets jumbo"

Most traffic would be with clients limited to at most 1500 bytes.
-- 
Its name is Public Opinion.  It is held in reverence.  It settles everything.
Some think it is the voice of God.
-- Mark Twain

Re: Open Souce Network Operating Systems

[Eron Lloyd]

I would start with following the Free Range Routing project, and related but 
independent (and more tangible) projects like pfSense (esp. the upcoming 3.0 
release) and Cumulus Linux. Going deeper, perhaps Carrier Grade Linux, DPDK, 
and ONOS (all Linux Foundation projects). I think scaling vertically from CPEs 
to core stack is a stretch, especially if you mean a DIY approach, however.

- Original Message -
From: "Colton Conor" 
To: "nanog" 
Sent: Wednesday, January 17, 2018 9:28:13 AM
Subject: Open Souce Network Operating Systems

If one were to deploy whitebox switches, X86 servers, low cost ARM and
MIBPS CPE devices, and basically anything that can run linux today, what
network operating system would you recommend? The goal would be to have a
universal network operating system that runs across a variety of devices.
>From low cost residential CPE's with wifi to switches to BGP speaking
routers. Is there anything that can do it all today?


I will use something like OpenWRT as an example. I don't consider this
anywhere near carrier grade, but it runs on X86 and low cost routers. I
don't think it will run on whitebox switches though.

Mikrotik RouterOS would be another example as it can run on low cost
Routerboards, and X86 servers. But it is not opensouce.

Is there any up and coming projects to look into?
-- 
Eron Lloyd
Information Technology Director
717-344-5958
e...@mawcom.com
MAW Communications, Inc.

Re: MTU to CDN's

[William Herrin]

On Thu, Jan 18, 2018 at 7:41 PM, Jared Mauch  wrote:
>> On Jan 18, 2018, at 7:32 PM, William Herrin  wrote:
>>
>> On Thu, Jan 18, 2018 at 7:14 PM, Jared Mauch  wrote:
>>> lets say i can
>>> send you a 9K packet.  If you receive that frame, and realize you need
>>> to fragment, then it’s your routers job to slice 9000 into 5 x 1500.
>>
>> In practice, no, because the packet you sent had the "don't fragment"
>> bit set.
>
> Which packet?  Is there a specific CDN that does this?  I’d be curious to see
> data vs speculation.

Howdy,

Path MTU discovery (which sets the DF bit on TCP packets) is enabled
by default on -every- operating system that's shipped for decades now.
If you don't want it, you have to explicitly disable it. Disabling it
for any significant quantity of traffic is considered antisocial since
routers generally can't fragment in the hardware fast path.

Regards,
Bill


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: MTU to CDN's

[Jared Mauch]

> On Jan 18, 2018, at 7:32 PM, William Herrin  wrote:
> 
> On Thu, Jan 18, 2018 at 7:14 PM, Jared Mauch  wrote:
>> lets say i can
>> send you a 9K packet.  If you receive that frame, and realize you need
>> to fragment, then it’s your routers job to slice 9000 into 5 x 1500.
> 
> In practice, no, because the packet you sent had the "don't fragment"
> bit set.

Which packet?  Is there a specific CDN that does this?  I’d be curious to see
data vs speculation.


> That means my router is not allowed to fragment the packet.
> Instead, I must send the originating host an ICMP destination
> unreachable packet stating that the largest packet I can send further
> is 1500 bytes.
> 
> You might receive my ICMP message. You might not. After all, I am not
> the host you were looking for.

:-)

Nor is it likely the reply.

- Jared

Re: MTU to CDN's

[Owen DeLong]

> On Jan 18, 2018, at 4:32 PM, William Herrin  wrote:
> 
> On Thu, Jan 18, 2018 at 7:14 PM, Jared Mauch  wrote:
>> lets say i can
>> send you a 9K packet.  If you receive that frame, and realize you need
>> to fragment, then it’s your routers job to slice 9000 into 5 x 1500.
> 
> In practice, no, because the packet you sent had the "don't fragment"
> bit set. That means my router is not allowed to fragment the packet.
> Instead, I must send the originating host an ICMP destination
> unreachable packet stating that the largest packet I can send further
> is 1500 bytes.
> 
> You might receive my ICMP message. You might not. After all, I am not
> the host you were looking for.

This gets especially bad in cases such as anycast where the return path may be 
asymmetrical and could result in delivery of the ICMP PTB message to a 
different anycast instance or to a stateless load balancer that is incapable of 
determining which machine originated the packet being referenced.

One of the many reasons I continue to question the wisdom of using anycast for 
multi-packet transactions.

Owen

> 
> Good luck.
> 
> Regards,
> Bill Herrin
> 
> 
> P.S. This makes Linux servers happy:
> 
> iptables -t mangle --insert POSTROUTING --proto tcp \
>--tcp-flags SYN,RST,FIN SYN --match tcpmss --mss 1241:65535 \
>--jump TCPMSS --set-mss 1240
> 
> 
> 
> -- 
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 

Re: MTU to CDN's

[William Herrin]

On Thu, Jan 18, 2018 at 7:14 PM, Jared Mauch  wrote:
> lets say i can
> send you a 9K packet.  If you receive that frame, and realize you need
> to fragment, then it’s your routers job to slice 9000 into 5 x 1500.

In practice, no, because the packet you sent had the "don't fragment"
bit set. That means my router is not allowed to fragment the packet.
Instead, I must send the originating host an ICMP destination
unreachable packet stating that the largest packet I can send further
is 1500 bytes.

You might receive my ICMP message. You might not. After all, I am not
the host you were looking for.

Good luck.

Regards,
Bill Herrin


P.S. This makes Linux servers happy:

iptables -t mangle --insert POSTROUTING --proto tcp \
--tcp-flags SYN,RST,FIN SYN --match tcpmss --mss 1241:65535 \
--jump TCPMSS --set-mss 1240



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: MTU to CDN's

[Jared Mauch]

> On Jan 18, 2018, at 5:53 PM, George Michaelson  wrote:
> 
> if I was an ISP (Im not) and a CDN came and said "we want to be inside
> you" (ewww) why wouldn't I say "sure: lets jumbo"
> 
> not even "asking for a friend" I genuinely don't understand why a CDN
> who colocates and is not using public exchange, but is inside your
> transit boundary (which I am told is actually a bit thing now) would
> not drive to the packet size which works in your switching gear.
> 
> I understand that CDN/DC praxis now drives to cheap dumb switches, but
> even dumb switches like bigger packets dont they? less forwarding
> decision cost, for more throughput?

The reason is most customers are at a lower MTU size.  lets say i can
send you a 9K packet.  If you receive that frame, and realize you need
to fragment, then it’s your routers job to slice 9000 into 5 x 1500.
I may have caused you to hit your exception path (which could be expensive)
as well as made your PPS load 5x larger downstream.

This doesn’t even account for the fact that you may need to have a speed
mismatch, whereby I am sending 100Gb+ and your outputs may be only 10G.

If you’re then doing DSL + PPPoE and your customers really see a MTU
of 1492 or less, then another device has to fragment 5x again.

For server to server, 9K makes a lot of sense, it reduces the packet processing
and increases the throughput.  If your consumer electronic wifi gear or switch
can’t handle >1500, and doesn’t even have a setting for layer-2 > 1500, the
cost is just too high.  Much easier for me to send 5x packets in the first place
and be more compatible.

Like many things, I’d love for this to be as simple and purist as you
purport.  I might even be willing to figure out if at $DayJob we could see
a benefit from doing this, but from the servers to switches to routers then
a partner interface.. it’s a lot of things to make sure are just right.

Plus.. can your phone do > 1500 MTU on the Wifi?  Where’s that setting?

(mumbling person about CSLIP and MRUs from back in the day)

- Jared

Re: MTU to CDN's

[George Michaelson]

thanks. good answer. low risk answer. "it will work" answer.

If its a variant of "the last mile is your problem" problem, I'm ok
with that. If its a consequence of the middleware deployment I feel
like its more tangibly bad decision logic, but its real.

-G

On Fri, Jan 19, 2018 at 9:50 AM, Mark Andrews  wrote:
> Because the CDN delivers to your customers not you.  It’s your customers link
> requirements that are the ones you need to worry about.  If you support
> jumbo frames to all of your customers and their gear also supports jumbo
> frame then sure go ahead and use jumbo frames otherwise use the lowest
> common denominator MTU when transmitting.  This is less than 1500 on
> today Internet and encapsulated traffic is reasonable common.
>
> embedded CND <--> NAT64 <--> CLAT <--> client
>  1500   14XX 1500
> embedded CDN <--> B4 <— > 6RD <— > client
>  1500.   14XX 1500
>
> Now you can increase the first 1500 easily.  The rest of the path not so
> easily.
>
>> On 19 Jan 2018, at 9:53 am, George Michaelson  wrote:
>>
>> if I was an ISP (Im not) and a CDN came and said "we want to be inside
>> you" (ewww) why wouldn't I say "sure: lets jumbo"
>>
>> not even "asking for a friend" I genuinely don't understand why a CDN
>> who colocates and is not using public exchange, but is inside your
>> transit boundary (which I am told is actually a bit thing now) would
>> not drive to the packet size which works in your switching gear.
>>
>> I understand that CDN/DC praxis now drives to cheap dumb switches, but
>> even dumb switches like bigger packets dont they? less forwarding
>> decision cost, for more throughput?
>>
>> On Fri, Jan 19, 2018 at 6:21 AM, Dovid Bender  wrote:
>>> Vincent,
>>>
>>> Thanks. That URL explained a lot.
>>>
>>> On Tue, Jan 9, 2018 at 3:11 AM, Vincent Bernat  wrote:
>>>
 ❦  8 janvier 2018 15:08 -0800, joel jaeggli  :

>> N00b here trying to understand why certain CDN's such as Cloudfare have
>> issues where my MTU is low. For instance if I am using pptp and the MTU
 is
>> at 1300 it wont work. If I increase to 1478 it may or may not work.
> PMTUD has a lot of trouble working reliability when the destination of
> the PTB  is a stateless load-balancer.

 More explanations are available here:
 https://blog.cloudflare.com/path-mtu-discovery-in-practice/
 --
 Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)

>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>

Re: MTU to CDN's

[Mark Andrews]

Because the CDN delivers to your customers not you.  It’s your customers link
requirements that are the ones you need to worry about.  If you support
jumbo frames to all of your customers and their gear also supports jumbo
frame then sure go ahead and use jumbo frames otherwise use the lowest
common denominator MTU when transmitting.  This is less than 1500 on
today Internet and encapsulated traffic is reasonable common.

embedded CND <--> NAT64 <--> CLAT <--> client
 1500   14XX 1500
embedded CDN <--> B4 <— > 6RD <— > client
 1500.   14XX 1500

Now you can increase the first 1500 easily.  The rest of the path not so
easily.

> On 19 Jan 2018, at 9:53 am, George Michaelson  wrote:
> 
> if I was an ISP (Im not) and a CDN came and said "we want to be inside
> you" (ewww) why wouldn't I say "sure: lets jumbo"
> 
> not even "asking for a friend" I genuinely don't understand why a CDN
> who colocates and is not using public exchange, but is inside your
> transit boundary (which I am told is actually a bit thing now) would
> not drive to the packet size which works in your switching gear.
> 
> I understand that CDN/DC praxis now drives to cheap dumb switches, but
> even dumb switches like bigger packets dont they? less forwarding
> decision cost, for more throughput?
> 
> On Fri, Jan 19, 2018 at 6:21 AM, Dovid Bender  wrote:
>> Vincent,
>> 
>> Thanks. That URL explained a lot.
>> 
>> On Tue, Jan 9, 2018 at 3:11 AM, Vincent Bernat  wrote:
>> 
>>> ❦  8 janvier 2018 15:08 -0800, joel jaeggli  :
>>> 
> N00b here trying to understand why certain CDN's such as Cloudfare have
> issues where my MTU is low. For instance if I am using pptp and the MTU
>>> is
> at 1300 it wont work. If I increase to 1478 it may or may not work.
 PMTUD has a lot of trouble working reliability when the destination of
 the PTB  is a stateless load-balancer.
>>> 
>>> More explanations are available here:
>>> https://blog.cloudflare.com/path-mtu-discovery-in-practice/
>>> --
>>> Don't comment bad code - rewrite it.
>>>- The Elements of Programming Style (Kernighan & Plauger)
>>> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: MTU to CDN's

[George Michaelson]

if I was an ISP (Im not) and a CDN came and said "we want to be inside
you" (ewww) why wouldn't I say "sure: lets jumbo"

not even "asking for a friend" I genuinely don't understand why a CDN
who colocates and is not using public exchange, but is inside your
transit boundary (which I am told is actually a bit thing now) would
not drive to the packet size which works in your switching gear.

I understand that CDN/DC praxis now drives to cheap dumb switches, but
even dumb switches like bigger packets dont they? less forwarding
decision cost, for more throughput?

On Fri, Jan 19, 2018 at 6:21 AM, Dovid Bender  wrote:
> Vincent,
>
> Thanks. That URL explained a lot.
>
> On Tue, Jan 9, 2018 at 3:11 AM, Vincent Bernat  wrote:
>
>>  ❦  8 janvier 2018 15:08 -0800, joel jaeggli  :
>>
>> >> N00b here trying to understand why certain CDN's such as Cloudfare have
>> >> issues where my MTU is low. For instance if I am using pptp and the MTU
>> is
>> >> at 1300 it wont work. If I increase to 1478 it may or may not work.
>> > PMTUD has a lot of trouble working reliability when the destination of
>> > the PTB  is a stateless load-balancer.
>>
>> More explanations are available here:
>>  https://blog.cloudflare.com/path-mtu-discovery-in-practice/
>> --
>> Don't comment bad code - rewrite it.
>> - The Elements of Programming Style (Kernighan & Plauger)
>>

Re: Greenland DSL or Internet service provider?

[John Levine]

In article <01b101d3909a$61e7a250$25b6e6f0$@pccwglobal.com> you write:
>We are searching for a provider who can deliver MPLS, dedicated circuit,
>DSL or Internet by cable access to the following GPS information address:
>
>Quanaaq

Assuming you mean Qaanaaq, the place formerly known as Thule, your
only option is the national carrier Telepost.  They claim to provide
broadband service to every community with a population of 70 or more,
and there are 650 in Qaanaaq, so you should be in good shape.

There are only about 50,000 people in all of Greenland, which is
consierably larger than Alaska, so it's not like it's a highly
competitive market.

R's,
John

Re: Greenland DSL or Internet service provider?

[Eric Dugas]

Pretty sure there's not a lot of provider and there's probably one national
infrastructure (a bit like Iceland). Try contacting Telepost as they seem
to be the only provider in the country:
https://telepost.gl/en/english/liberalized-wholesale

On Thu, Jan 18, 2018 at 3:24 PM, Rivera, Alberto 
wrote:

> We are searching for a provider who can deliver MPLS, dedicated circuit,
> DSL or Internet by cable access to the following GPS information address:
>
>
>
> Greenland
>
> Quanaaq
>
> GPS:   76°30'58.4"N 68°36'03.7"W
>
>
>
> Any ideas?
>
>
>
> Thank you!
>
>
>
> Alberto Rivera
>
> PreSales Engineer – Enterprise Sales
>
> PCCW Global
>
> 450 Spring Park Place
>
> Suite 100
>
> Herndon, VA 20170
>
> Tel: +1(703)774-9459 Office | + 1(571)315-5309 Cell
>
> Email: ariv...@pccwglobal.com
>
> Website: www.pccwglobal.com
>
> To view PCCW Global’s communication videos
>  click here
>
>
>   cid:9f4812ce-f4a5-4441-a4e4-1d77c1ee1ad7
>
>  
> cid:21f87991-196a-41be-a978-deb2e5059c9b
>
>  
> cid:1d9fa650-71e3-4e53-a84f-f92859afadfa
>
>  
> cid:e396fb8d-688f-4d85-befe-85c9f88f81c9
>
>  
> cid:0e7d23dc-f767-4fec-b036-a8410443413f
>
>
>
>

Greenland DSL or Internet service provider?

[Rivera, Alberto]

We are searching for a provider who can deliver MPLS, dedicated circuit,
DSL or Internet by cable access to the following GPS information address:



Greenland

Quanaaq

GPS:   76°30'58.4"N 68°36'03.7"W



Any ideas?



Thank you!



Alberto Rivera

PreSales Engineer – Enterprise Sales

PCCW Global

450 Spring Park Place

Suite 100

Herndon, VA 20170

Tel: +1(703)774-9459 Office | + 1(571)315-5309 Cell

Email: ariv...@pccwglobal.com

Website: www.pccwglobal.com

To view PCCW Global’s communication videos
 click here


  cid:9f4812ce-f4a5-4441-a4e4-1d77c1ee1ad7

 
cid:21f87991-196a-41be-a978-deb2e5059c9b

 
cid:1d9fa650-71e3-4e53-a84f-f92859afadfa

 
cid:e396fb8d-688f-4d85-befe-85c9f88f81c9

 
cid:0e7d23dc-f767-4fec-b036-a8410443413f

RE: Cogent ops contact

[Aaron Gould]

Going off of old notes...

1-877-726-4368 Prompts 2,2
 supp...@cogentco.com

-Aaron

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Youssef 
Bengelloun-Zahr
Sent: Thursday, January 18, 2018 4:53 AM
To: NANOG ‎[nanog@nanog.org]‎
Subject: Cogent ops contact

Dear Nanog community,

I have an issue with a client trying to reach an IP that has been blackholed on 
Cogent backbone for shady "security reasons".

Can someone reach out in MP please ?

Thank you.

Re: MTU to CDN's

[Dovid Bender]

Vincent,

Thanks. That URL explained a lot.

On Tue, Jan 9, 2018 at 3:11 AM, Vincent Bernat  wrote:

>  ❦  8 janvier 2018 15:08 -0800, joel jaeggli  :
>
> >> N00b here trying to understand why certain CDN's such as Cloudfare have
> >> issues where my MTU is low. For instance if I am using pptp and the MTU
> is
> >> at 1300 it wont work. If I increase to 1478 it may or may not work.
> > PMTUD has a lot of trouble working reliability when the destination of
> > the PTB  is a stateless load-balancer.
>
> More explanations are available here:
>  https://blog.cloudflare.com/path-mtu-discovery-in-practice/
> --
> Don't comment bad code - rewrite it.
> - The Elements of Programming Style (Kernighan & Plauger)
>

Re: Cogent ops contact

[Youssef Bengelloun-Zahr]

Hi,

Issue is I’m not a cogent customer.

Best regards.



> Le 18 janv. 2018 à 21:04, Alistair Mackenzie  a écrit :
> 
> I've had no problem dealing with their noc on these sort of issues in the 
> past. 
> 
>> On 18 Jan 2018 10:54, "Youssef Bengelloun-Zahr"  wrote:
>> Dear Nanog community,
>> 
>> I have an issue with a client trying to reach an IP that has been
>> blackholed on Cogent backbone for shady "security reasons".
>> 
>> Can someone reach out in MP please ?
>> 
>> Thank you.

Re: Cogent ops contact

[Alistair Mackenzie]

I've had no problem dealing with their noc on these sort of issues in the
past.

On 18 Jan 2018 10:54, "Youssef Bengelloun-Zahr"  wrote:

> Dear Nanog community,
>
> I have an issue with a client trying to reach an IP that has been
> blackholed on Cogent backbone for shady "security reasons".
>
> Can someone reach out in MP please ?
>
> Thank you.
>

Re: connection to ix

[Mike Hammett]

I doubt you're going to find IX-specific services among Caribbean islands. I 
also doubt that there is 10G wave-level of capacity needs to each IX, given 
that AMS-IX Caribbean has a peak of 19 Gb/s. 

Finding someone that does Carrier Ethernet or VPLS services to do aggregation 
would be the best hope, but even that is limited given the limited carrier 
selection in the Caribbean. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Olivier Benghozi"  
To: "NANOG list"  
Sent: Thursday, January 18, 2018 7:12:10 AM 
Subject: Re: connection to ix 

Sure, plenty of people use such service. 

If you have much traffic, you'll rely on one dedicated port for each IX, and 
maybe one full 10G wave or more toward each one (so the remote service is only 
transport, you have your own port at each IX). 

If not, you'll use ethernet over MPLS service for remote peering, provided by 
guys like IX-Reach, who will provide you shared bandwidth over their own 
connection at each IX, delivered on one single port (or more) toward you. 
It's shared bandwidth, so you must trust the provider network, in case of DDoS 
on its ports your traffic will be at risk, you don't see if the remote port is 
down. 
But the price can be quite more interesting, you don't have to deal with the 
remote physical interco, and so on. 

Now, you have to find someone providing remote peering to the IXs you want, to 
check the price... 

> Le 18 janv. 2018 à 13:24, Rudolph Daniel  a écrit : 
> 
> How do i remotely connect to an ix? 
> In the en. speaking caribbean we have probably six to eight small national 
> ixps. I want to be present at all of them, & its been suggested i can make 
> some cost savings by remote connection using mpls. Is this a viable 
> option? Is there a disadvantage in doing this? Thx. 
> 
> Rudi 

Re: connection to ix

[Olivier Benghozi]

Sure, plenty of people use such service.

If you have much traffic, you'll rely on one dedicated port for each IX, and 
maybe one full 10G wave or more toward each one (so the remote service is only 
transport, you have your own port at each IX).

If not, you'll use ethernet over MPLS service for remote peering, provided by 
guys like IX-Reach, who will provide you shared bandwidth over their own 
connection at each IX, delivered on one single port (or more) toward you.
It's shared bandwidth, so you must trust the provider network, in case of DDoS 
on its ports your traffic will be at risk, you don't see if the remote port is 
down.
But the price can be quite more interesting, you don't have to deal with the 
remote physical interco, and so on.

Now, you have to find someone providing remote peering to the IXs you want, to 
check the price...

> Le 18 janv. 2018 à 13:24, Rudolph Daniel  a écrit :
> 
> How do i remotely connect to an ix?
> In the en. speaking caribbean we have probably six to eight small national
> ixps. I want to be present at all of them, & its been suggested i can make
> some cost savings by remote connection using mpls.  Is this a viable
> option? Is there a disadvantage in doing this? Thx.
> 
> Rudi

connection to ix

[Rudolph Daniel]

How do i remotely connect to an ix?
In the en. speaking caribbean we have probably six to eight small national
ixps. I want to be present at all of them, & its been suggested i can make
some cost savings by remote connection using mpls.  Is this a viable
option? Is there a disadvantage in doing this? Thx.

Rudi

Cogent ops contact

[Youssef Bengelloun-Zahr]

Dear Nanog community,

I have an issue with a client trying to reach an IP that has been
blackholed on Cogent backbone for shady "security reasons".

Can someone reach out in MP please ?

Thank you.