Re: Colo in Africa

[Mehmet Akcin]

Visit https://live.infrapedia.com and you can connect colo owners ,
capacity owners directly

On Tue, Jul 16, 2019 at 15:34 Ken Gilmour  wrote:

> Hi Folks,
>
> I work for a Security Analytics org and we're looking to build a small POP
> in Africa. I am pretty clueless about the region so I was wondering if you
> could help guide me in the right direction for research?
>
> The challenges:
>
>1. Network needs to be able to receive millions of small PPS (as
>opposed to serving smaller numbers of larger files).
>2. Can't be cloud (need bare metal servers / colo). We use the full
>capacity of each server, all the time.
>3. Must have good connectivity to most of the rest of Africa
>4. We can initially only have one POP
>
> This is not like a normal website that we can just host on "any old
> provider", the requirements are very different.
>
> Is there a good location where we could either rent bare metal servers
> (something like Internap - preferred) or colocate servers within Africa
> that can serve most of the region?
>
> "Good" is defined as an area with stable connectivity and power, no legal
> restrictions on things like encryption, and good latency (sub 100ms) to the
> rest of Africa.
>
> Our two closest POPs are in Singapore and The Netherlands, so I'd like
> something closer to the middle that can serve the rest of Africa. Middle
> East will be deployed after Africa.
>
> I hope this is the right place to ask.
>
> Thanks!
>
> Ken
>
-- 
Mehmet
+1-424-298-1903

Way O/T - but I know you folks are resource-rich..

[Allen Kitchen]

Folks, I work with several people on legal probation for various offenses
such that they are completely prohibited from internet access. In a few
cases, some of these would benefit educationally from having a copy of old
printed Mouser, Digi-Key, Jameco or similar catalog - just for educational
purposes. I know it's been almost a decade since most stopped printing the
catalogs, but is there a chance that any of you have a stack of oldies
around anywhere that you're finally ready to clear out? All I need is one
or two to share, and I realize that the selection and prices would be
completely obsolete. Still, there is lots to learn from those.

I am certainly willing to pay for shipping if anyone wants. Off-line
responses preferred for the good of the list - and thanks.

Blessings..

Allen Kitchen
Several hats worn, but THIS particular hat:
Prison-After-Care Ministries (PAC-Min)
404 Franklin St, Butler, PA 16001
412-295-7736 / allenmckinleykitc...@gmail.com

Re: Colo in Africa

[Gregoire Ehoumi via NANOG]

Ken,You can have useful information in AFNOG mailing list 
(af...@afnog.org).--Gregoire Ehoumi-- Original message--From: Ken 
GilmourDate: Tue, Jul 16, 2019 6:48 PMTo: C. A. Fillekes;Cc: North 
Group;Subject:Re: Colo in AfricaWhat matters is whether or not we can get a 
facility in Africa to provide service to our customers from Bare Metal Servers 
:)On Tue, 16 Jul 2019 at 16:07, C. A. Fillekes  wrote:Are 
they refreshing data they've already got, though? This is the classic use case 
for client-side caching. On Tue, Jul 16, 2019 at 5:56 PM Ken Gilmour 
 wrote:We have a different use case to traditional 
analytics - We're aimed at consumers and small businesses, so instead of a SOC 
with one big screen refreshing 1 rows of only alert data every 30 seconds, 
we have thousands of individuals refreshing all of their data every 30 seconds 
because there are comparatively less alerts for individuals than 
enterprises.What you "should" do often do
 esn't translate to what you "do" do.On Tue, 16 Jul 2019 at 11:23, Valdis 
Kl??tnieks  wrote:On Tue, 16 Jul 2019 10:39:59 -0600, 
Ken Gilmour said:

> These are actual real problems we face. thousands of customers load and
> reload TBs of data every few seconds on their dashboards.

If they're reloading TBs of data every few seconds, you really should have been
doing summaries during data ingestion and only reloading the summaries.
(Overlooking the fact that for dashboards, refreshing every few seconds is
usually pointless because you end up looking at short-term statistical spikes
rather than anything that you can react to at human speeds.?? If you *care* in
real time that the number of probes on a port spiked to 457% of average for 2
seconds you need to be doing automated responses

Custom queries are more painful - but those don't happen "every few seconds".

Re: Colo in Africa

[Rod Beck]

The cross continent connectivity is not going to be particularly reliable. 
Prone to cuts due to wars and regional turmoil. And imagine how it takes to 
repair problems at the physical layer.


From: NANOG  on behalf of Eric Kuhnke 

Sent: Wednesday, July 17, 2019 3:05 AM
To: Ken Gilmour ; nanog@nanog.org list 
Subject: Re: Colo in Africa

Without being more specific on what geographic region you want to serve, in 
terms of ISPs, it's hard to say.

For example:

If you look at submarine cable topology at layer 1, and BGP sessions, AS 
adjacencies between ISPs: Freetown, Sierra Leone and Monrovia, Liberia are 
suburbs of London, UK.

If you want to reach major things in the west african region the two best 
connected places are Accra, Ghana and Lagos, Nigeria.

On the other hand, if you put equipment topologically close to the cable 
landing station in Accra it will have rather poor connectivity to the east side 
of Africa. It's a big place and there is very little cross-continent 
connectivity that doesn't take the long way around via submarine fiber to Cape 
Town, and then up the east coast.


On Tue, Jul 16, 2019 at 7:34 AM Ken Gilmour 
mailto:ken.gilm...@gmail.com>> wrote:
Hi Folks,

I work for a Security Analytics org and we're looking to build a small POP in 
Africa. I am pretty clueless about the region so I was wondering if you could 
help guide me in the right direction for research?

The challenges:

  1.  Network needs to be able to receive millions of small PPS (as opposed to 
serving smaller numbers of larger files).
  2.  Can't be cloud (need bare metal servers / colo). We use the full capacity 
of each server, all the time.
  3.  Must have good connectivity to most of the rest of Africa
  4.  We can initially only have one POP

This is not like a normal website that we can just host on "any old provider", 
the requirements are very different.

Is there a good location where we could either rent bare metal servers 
(something like Internap - preferred) or colocate servers within Africa that 
can serve most of the region?

"Good" is defined as an area with stable connectivity and power, no legal 
restrictions on things like encryption, and good latency (sub 100ms) to the 
rest of Africa.

Our two closest POPs are in Singapore and The Netherlands, so I'd like 
something closer to the middle that can serve the rest of Africa. Middle East 
will be deployed after Africa.

I hope this is the right place to ask.

Thanks!

Ken

Re: Performance metrics used in commercial BGP route optimizers

[Michael Still]

On Wed, Jul 17, 2019 at 12:38 AM Hank Nussbacher  wrote:
>
> On 16/07/2019 20:41, Job Snijders wrote:
>
> On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett  wrote:
>>
>> More like do whatever you want in your own house as long as you don't 
>> infringe upon others.
>
>
> That's where the rub is; when using "BGP optimisers" to influence public 
> Internet routing, you cannot guarantee you won't infringe upon others.
>
>>
>> The argument against route optimizers (assuming appropriate ingress\egress 
>> filters) is a religious one and should be treated as such.
>
> There is a difference between BGP optimizers and route optimizers.  When was 
> the last time you heard a complain about Akamai screwing up the global 
> routing table over the past 12 years:
>
> https://www.akamai.com/us/en/about/news/press/2007-press/akamai-introduces-advanced-communications-protocol-for-accelerating-dynamic-applications.jsp
>
> https://developer.akamai.com/legacy/learn/Optimization/SureRoute.html
>
> -Hank
>
>

Along these same lines I'd like to point out that nearly all or
possibly even all incidents in recent memory are attributable to a
single product whereas there has been at least one other product on
the market for something like 15+ years that AFAIK has not had a
single incident associated with it (and also does not create more
specific prefixes as part of its operation). So is it really that one
product is spoiling the market for the rest here or are they all bad?

-- 
[stillwa...@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwa...@gmail.com ~]$

Re: Colo in Africa

[Mark Tinka]

On 17/Jul/19 17:04, Rod Beck wrote:
> The cross continent connectivity is not going to be particularly
> reliable. Prone to cuts due to wars and regional turmoil. And imagine
> how it takes to repair problems at the physical layer.

I think that view is too myopic... you make it sound like Namibia,
Botswana, Zimbabwe and Zambia are at war. Just like all other
continents, unrest exists in some states, not all of them.

For the regions the OP is interested in, there isn't any conflict there
that would prevent him from deploying network.

Terrestrial connectivity is not a viable solution because:

  * It costs too much.
  * Different countries (even direct neighbors) do not share social,
economic or political values.
  * Most of the available network is in the hands of incumbents,
typically controlled by the gubbermint.
  * It costs too much.
  * There isn't sufficient capacity to drive prices down when crossing 2
or more countries.
  * It costs too much.
  * Many markets are closed off and it's impossible to obtain licenses
to compete.
  * It costs too much.
  * Much of the network is old and has barely been upgraded.
  * It costs too much.
  * For those bold enough to build, the terrain in some parts is not a
walkover.
  * It costs too much.

Mark.

Re: Performance metrics used in commercial BGP route optimizers

[Jared Geiger]

I was attracted to BGP route optimizers for latency/jitter reduction and
partial black hole detection scenarios.  Our traffic is low enough in
volume that we aren't playing the circuit commit game, but rather
optimizing the path to VoIP customers who don't care that provider Y in
path X-Y-Z had a fiber cut causing issues with their phone service.

They are a piece of the SDN and automation fun. Hopefully the vendors will
devise ways of dealing with traffic load balancing without splitting
prefixes.Or maybe RPKI will become more ubiquitous and leaks won't be as
painful. Similar to how DNSSEC led many ISPs to remove their DNS
redirecting "search services".

On Wed, Jul 17, 2019 at 10:02 AM Michael Still  wrote:

> On Wed, Jul 17, 2019 at 12:38 AM Hank Nussbacher 
> wrote:
> >
> > On 16/07/2019 20:41, Job Snijders wrote:
> >
> > On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett  wrote:
> >>
> >> More like do whatever you want in your own house as long as you don't
> infringe upon others.
> >
> >
> > That's where the rub is; when using "BGP optimisers" to influence public
> Internet routing, you cannot guarantee you won't infringe upon others.
> >
> >>
> >> The argument against route optimizers (assuming appropriate
> ingress\egress filters) is a religious one and should be treated as such.
> >
> > There is a difference between BGP optimizers and route optimizers.  When
> was the last time you heard a complain about Akamai screwing up the global
> routing table over the past 12 years:
> >
> >
> https://www.akamai.com/us/en/about/news/press/2007-press/akamai-introduces-advanced-communications-protocol-for-accelerating-dynamic-applications.jsp
> >
> > https://developer.akamai.com/legacy/learn/Optimization/SureRoute.html
> >
> > -Hank
> >
> >
>
> Along these same lines I'd like to point out that nearly all or
> possibly even all incidents in recent memory are attributable to a
> single product whereas there has been at least one other product on
> the market for something like 15+ years that AFAIK has not had a
> single incident associated with it (and also does not create more
> specific prefixes as part of its operation). So is it really that one
> product is spoiling the market for the rest here or are they all bad?
>
> --
> [stillwa...@gmail.com ~]$ cat .signature
> cat: .signature: No such file or directory
> [stillwa...@gmail.com ~]$
>

Re: Performance metrics used in commercial BGP route optimizers

[Töma Gavrichenkov]

On Wed, Jul 17, 2019, 9:52 PM Jared Geiger  wrote:

> Similar to how DNSSEC led many ISPs to remove their DNS redirecting
> "search services".
>

Not that significant, but DNSSec, at the 4% adoption rate, didn't do that,
HTTPS and HSTS did.

--
Töma

>

Re: Colo in Africa

[Rod Beck]

Circuits linking Asia & Europe via Siberia have proven highly unreliable. 
Repairs are long and difficult. And arguably Russia is a better case scenario 
than Africa. More politically stable. Better finances. Better basic 
infrastructure.


From: NANOG  on behalf 
of Mark Tinka 
Sent: Wednesday, July 17, 2019 7:16 PM
To: nanog@nanog.org 
Subject: Re: Colo in Africa



On 17/Jul/19 17:04, Rod Beck wrote:
The cross continent connectivity is not going to be particularly reliable. 
Prone to cuts due to wars and regional turmoil. And imagine how it takes to 
repair problems at the physical layer.

I think that view is too myopic... you make it sound like Namibia, Botswana, 
Zimbabwe and Zambia are at war. Just like all other continents, unrest exists 
in some states, not all of them.

For the regions the OP is interested in, there isn't any conflict there that 
would prevent him from deploying network.

Terrestrial connectivity is not a viable solution because:

  *   It costs too much.
  *   Different countries (even direct neighbors) do not share social, economic 
or political values.
  *   Most of the available network is in the hands of incumbents, typically 
controlled by the gubbermint.
  *   It costs too much.
  *   There isn't sufficient capacity to drive prices down when crossing 2 or 
more countries.
  *   It costs too much.
  *   Many markets are closed off and it's impossible to obtain licenses to 
compete.
  *   It costs too much.
  *   Much of the network is old and has barely been upgraded.
  *   It costs too much.
  *   For those bold enough to build, the terrain in some parts is not a 
walkover.
  *   It costs too much.

Mark.

Re: Performance metrics used in commercial BGP route optimizers

[Nikolas Geyer]

You can achieve performance based routing using latency/jitter and partial 
blackhole detection as your metrics without resorting to prefix splitting - 
adjust local preferences on received routes, don’t install received routes, add 
static routes, change MPLS label if doing EPE etc. I see very few, if any, use 
cases for prefix splitting that could not be accommodated for via other 
mechanisms that do not leave a network in a “locked and loaded” dangerous state.

But it’s a free world and market economy (at least in the NA part of NANOG) so 
people will use this stuff unfortunately. But take a look at the Twitter link 
Job supplied earlier where a vendor confirmed they are insecure mode of 
operation by default. Why??? Being good corporate citizens the model should be 
secure by default and you can remove the safety if you know what you’re doing 
(ideally you couldn’t remove the safety at all, but see above comment around 
free market). Handing people software with the safety removed and assuming they 
won’t pull the trigger is reckless business conduct IMO. But at the end of the 
day, it’s all about the almighty dollar and if a customer can be gained where 
the path is resistance is less giving them an insecure product by default, 
typically because the customer doesn’t have the technical knowledge to 
understand what they’re actually doing, then so be it.

Sent from my iPhone

On Jul 17, 2019, at 2:53 PM, Jared Geiger 
mailto:ja...@compuwizz.net>> wrote:

I was attracted to BGP route optimizers for latency/jitter reduction and 
partial black hole detection scenarios.  Our traffic is low enough in volume 
that we aren't playing the circuit commit game, but rather optimizing the path 
to VoIP customers who don't care that provider Y in path X-Y-Z had a fiber cut 
causing issues with their phone service.

They are a piece of the SDN and automation fun. Hopefully the vendors will 
devise ways of dealing with traffic load balancing without splitting 
prefixes.Or maybe RPKI will become more ubiquitous and leaks won't be as 
painful. Similar to how DNSSEC led many ISPs to remove their DNS redirecting 
"search services".

On Wed, Jul 17, 2019 at 10:02 AM Michael Still 
mailto:stillwa...@gmail.com>> wrote:
On Wed, Jul 17, 2019 at 12:38 AM Hank Nussbacher 
mailto:h...@efes.iucc.ac.il>> wrote:
>
> On 16/07/2019 20:41, Job Snijders wrote:
>
> On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett 
> mailto:na...@ics-il.net>> wrote:
>>
>> More like do whatever you want in your own house as long as you don't 
>> infringe upon others.
>
>
> That's where the rub is; when using "BGP optimisers" to influence public 
> Internet routing, you cannot guarantee you won't infringe upon others.
>
>>
>> The argument against route optimizers (assuming appropriate ingress\egress 
>> filters) is a religious one and should be treated as such.
>
> There is a difference between BGP optimizers and route optimizers.  When was 
> the last time you heard a complain about Akamai screwing up the global 
> routing table over the past 12 years:
>
> https://www.akamai.com/us/en/about/news/press/2007-press/akamai-introduces-advanced-communications-protocol-for-accelerating-dynamic-applications.jsp
>
> https://developer.akamai.com/legacy/learn/Optimization/SureRoute.html
>
> -Hank
>
>

Along these same lines I'd like to point out that nearly all or
possibly even all incidents in recent memory are attributable to a
single product whereas there has been at least one other product on
the market for something like 15+ years that AFAIK has not had a
single incident associated with it (and also does not create more
specific prefixes as part of its operation). So is it really that one
product is spoiling the market for the rest here or are they all bad?

--
[stillwa...@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwa...@gmail.com ~]$

Fiber providers - Englewood / Centennial Colorado

[JASON BOTHE via NANOG]

Hi all 

Just curious if you know of any fiber providers other than CL or Zayo in the 
Englewood/Centennial area. Having a really tough time finding routes that avoid 
the Solarium at Quebec / E Orchard as well as 910 15th St. Seems there are so 
many single points of failure and collapsed routes that all lead to these two 
locations to get diverse long haul. 

Many thanks. 

J~ 

Re: Fiber providers - Englewood / Centennial Colorado

[Mike Bolitho]

Denver is a tough market for diversity's sake. Just about everyone that was
there was gobbled up by what is now CenturyLink.

-Mike Bolitho

On Wed, Jul 17, 2019, 4:12 PM JASON BOTHE via NANOG  wrote:

> Hi all
>
> Just curious if you know of any fiber providers other than CL or Zayo in
> the Englewood/Centennial area. Having a really tough time finding routes
> that avoid the Solarium at Quebec / E Orchard as well as 910 15th St. Seems
> there are so many single points of failure and collapsed routes that all
> lead to these two locations to get diverse long haul.
>
> Many thanks.
>
> J~
>

Re: Bgpmon alternatives?

[TJ Trout]

Anyone know of a hosted alternative to bgpmon? I'm testing Qrator but I
can't determine if it will notify in real-time of a prefix hijack?

On Sun, Jun 16, 2019 at 9:23 AM Matt Corallo  wrote:

> There's also https://github.com/NLNOG/bgpalerter (which I believe they're
> trying to turn into a website frontend based on RIS, but I run it with
> patches for as_path regexes and it works pretty well).
>
> On Jun 16, 2019, at 07:40, Michael Hallgren  wrote:
>
> RIS Live API is a choice for this.
>
> mh
> Le 16 juin 2019, à 13:21, Brian Kantor  a écrit:
>>
>> That would be wonderful.  Thank you!
>>  - Brian
>>
>>
>> On Sun, Jun 16, 2019 at 03:59:29AM -0700, Mike Leber wrote:
>>
>>>  I'm sure if it doesn't do exactly that already, we can add it shortly.
>>>
>>>  Some of planned functionality for hijack detection is already live.
>>>  That's one of the main reasons for creating this service.
>>>
>>>  Mike.
>>>
>>>  On 6/16/19 2:48 AM, Brian Kantor wrote:
>>>
  On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote:

>  As a beta service you can try out rt-bgp.he.net.  This is a real time
>  bgp monitoring service we are developing.
>
  It's interesting, but I don't see any way to do what I primarily
  use the existing BGPMon for: watch for hijacks.

  That is, set up one or more prefixes to be continuously monitored
  and have the monitor send me an email alert when that prefix or a
  subnet of it begins to be announced by someone new.

  For example, if I have told it to monitor 44.0.0.0/8 and someone
  somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very
  much like to know about that, along with details of who and where.

  Then if that announcement is authorized, I can tell the monitoring
  service that this new entry is NOT a hijack, and it won't bug me
  about it again.

  Can it be persuaded to do this?
   - Brian

>>>

netstat -s

[Randy Bush]

do folk use `netstat -s` to help diagnose on routers/switches?

randy

Re: Bgpmon alternatives?

[Töma Gavrichenkov]

On Thu, Jul 18, 2019 at 3:16 AM TJ Trout  wrote:
> Anyone know of a hosted alternative to bgpmon? I'm testing
> Qrator but I can't determine if it will notify in real-time of a
> prefix hijack?

Qrator guy there.
Real-time notifications are there but are only available on a
commercial basis, because basically real time is expensive to compute.
The rest is free.

--
Töma