Re: Must have ISP Open Source & tools

[Mehmet Akcin]

Awesome list

On Sun, Jul 7, 2019 at 19:42 Ryan Hamel  wrote:

> My List:
>
> Oxidized as a replacement for RANCID
> Telegraf + InfluxDB = Tons of Grafana Dashboards
> (Open Source Slack Alternative)
> Ansible or Python Knowledge with Paramiko or netmiko for network
> automation.
>
> BGP:
>
> FRRouting - Mimics Cisco CLI
> BIRD - Programming style config format.
> Exabgp - Mostly used for API driven applications, monitoring with
> heartbeat scripts.
> (many others)
>
> DDoS detection and/or filtering:
>
> Fastnetmon - Supports many methods for packet processing.
> Ddosdetector (IPv4 Only) - Uses netmap for packet processing.
>
> Top Talkers + Other Creativeness (like fib compressing, or route
> optimization):
>
> pmacct - sflow/netflow combined with BGP, and a database backend
>
> Servers:
>
> Sensu or LibreNMS for Nagios type monitoring.
>
> Diagnostics:
>
> MTR - ...and knowing how to interpret it's output.
>
> -Ryan
>
> --
Mehmet
+1-424-298-1903

Re: Must have ISP Open Source & tools

[cyrus ramirez via NANOG]

I don't know if the areas have been evaluated or not. I would hyperconverge and 
virtualize as much as possible. I would attempt MPLS with a VRF gateway. Money 
will probably be an issue so hosting VoIP and Content services may be good. Are 
you using wireless, cable, satellite as the backhaul? If this is completely 
Greenfield, then evaluating a location, finding relay sites and etc should be 
done 1st.
Cyrus 

Sent from Yahoo Mail on Android 
 
  On Sun, Jul 7, 2019 at 8:08 PM, Mehmet Akcin wrote:   Hey 
there
We are a growing ISP in Colombia and Latin America. I am interested in hearing 
from others regarding tools and software they recommend we must have such as 
LibreNMS, Rancid etc.
It’s greenfieldish now ;-) so feel free to recommend A-Z anything! ;-)
Hope this thread is useful others too!
Mehmet-- 
Mehmet
+1-424-298-1903  

RE: Must have ISP Open Source & tools

[Ryan Hamel]

My List:

Oxidized as a replacement for RANCID
Telegraf + InfluxDB = Tons of Grafana Dashboards
(Open Source Slack Alternative)
Ansible or Python Knowledge with Paramiko or netmiko for network automation.

BGP:

FRRouting - Mimics Cisco CLI
BIRD - Programming style config format.
Exabgp - Mostly used for API driven applications, monitoring with heartbeat 
scripts.
(many others)

DDoS detection and/or filtering:

Fastnetmon - Supports many methods for packet processing.
Ddosdetector (IPv4 Only) - Uses netmap for packet processing.

Top Talkers + Other Creativeness (like fib compressing, or route optimization):

pmacct - sflow/netflow combined with BGP, and a database backend

Servers:

Sensu or LibreNMS for Nagios type monitoring.

Diagnostics:

MTR - ...and knowing how to interpret it's output.

-Ryan

Re: Must have ISP Open Source & tools

[Niels Bakker]

* meh...@akcin.net (Mehmet Akcin) [Mon 08 Jul 2019, 02:07 CEST]:
We are a growing ISP in Colombia and Latin America. I am interested 
in hearing from others regarding tools and software they recommend 
we must have such as LibreNMS, Rancid etc.


You should reach out to Euro-IX if you haven't already, every member 
IXP has documented what software they use in their switch database



-- Niels.

Must have ISP Open Source & tools

[Mehmet Akcin]

Hey there

We are a growing ISP in Colombia and Latin America. I am interested in
hearing from others regarding tools and software they recommend we must
have such as LibreNMS, Rancid etc.

It’s greenfieldish now ;-) so feel free to recommend A-Z anything! ;-)

Hope this thread is useful others too!

Mehmet
-- 
Mehmet
+1-424-298-1903

Re: CenturyLink/Level3 feedback

[Mark Tinka]

Prior to the acquisition, we had a reasonable experience with Level(3)
orders in Europe.

Since the days of CL, it hasn't been great at all!

The team is the same as before for our account, so one can only assume
it's acquisition pains.

Mark.

On 7/Jul/19 03:10, Jeffrey Hathaway via NANOG wrote:
> Greetings,
>
> My personal experience, take it for what it is worth.
>
> Level 3 was extremely slow to turn up a circuit well before the merger and 
> seems slower post the merger. I have just never seen level 3 turn up anything 
> fast, even in a data center they already were serving other customers in.
>
>
> Sincerely,
> Jeffrey Hathaway
> Information Technology • Howard Center Inc.
>
>
>
> -Original Message-
> From: NANOG  On Behalf Of Jared Mauch
> Sent: Friday, July 5, 2019 3:38 PM
> To: Stephen Frost 
> Cc: nanog 
> Subject: Re: CenturyLink/Level3 feedback
>
> 
> CAUTION: This email originated from outside Howard Center. Please use caution 
> opening attachments or clicking on web links with this email.
> 
>
>
>
>> On Jul 5, 2019, at 3:10 PM, Stephen Frost  wrote:
>>
>> Greetings,
>>
>> I have to admit that I was hoping to be able to report to this list
>> that CL was able to spin up a new 1G in fairly short order (after all,
>> this is what they assured me of when discussing it with them...) but
>> it's now been over a month, with them telling me it'll be another
>> couple weeks because they need to send a tech out (the wiring and all
>> of the equipment has been ready to go, though that also took longer
>> than it should have imv...).
>>
>> And this in an already lit building in northern Virginia, not some
>> back of the woods location, small town, or something going across an ocean.
> Sometimes you’d be surprised, it may not be straightforward on their end.
>
> Remember, most people here are likely experts at some part or many parts, 
> what we do is likely wizardry to others.
>
> I have a saying you’re welcome to steal if you don’t steal it too much:
>
> “We are moving at the speed the organization is capable”.  I suspect that’s 
> the case for them in a post-acquisition world trying to sort through all the 
> integration work.
>
> - Jared
> 
>
>
> HowardCenter.org 
> [http://howardcenter.org/assets/design/Facebook.jpg] 
>   
> [http://howardcenter.org/assets/design/Twitter.jpg] 
>   
> [http://howardcenter.org/assets/design/LinkedIn.jpg] 
> 
>
> CONFIDENTIALITY NOTICE: This e-mail is intended only for the use of the 
> individual or entity to which it is addressed and may contain information 
> that is patient protected health information, privileged, confidential and 
> exempt from disclosure under applicable law. If you have received this 
> communication in error, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly prohibited. Please 
> notify the sender by reply e-mail and delete the original message 
> immediately, or notify Howard Center, Inc. immediately by forwarded e-mail to 
> our Privacy Officer, da...@howardcenter.org. Thank you.

Re: CloudFlare issues?

[Mark Tinka]

On 6/Jul/19 23:44, Matt Corallo wrote:
> On my test net I take ROA_INVALIDs and convert them to unreachables with
> a low preference (ie so that any upstreams taking only the shorter path
> will be selected, but so that such packets will never be routed).
>
> Obviously this isn't a well-supported operation, but I'm curious what
> people think of such an approach? If you really want to treat
> ROA_INVALID as "this is probably a hijack", you don't really want to be
> sending the hijacker traffic.

If a prefixe's RPKI state is Invalid, drop it! Simple.

In most cases, it's a mistake due to a mis-configuration and/or a lack
of deep understanding of RPKI. In fewer cases, it's an actual hijack.

Either way, dropping the Invalid routes keeps the BGP clean and quickly
encourages the originating network to get things fixed.

As you point out, RPKI state validation is locally-significant, with
protection extending to downstream customers only. So for this to really
work, it needs critical mass. One, two, three, four or five networks
implementing ROV and dropping Invalids does not a secure BGP make.

Mark.

Re: CloudFlare issues?

[Mark Tinka]

On 6/Jul/19 22:05, Brett Frankenberger wrote:

> These were more-specifics, though.  So if you drop all the
> more-specifics as failing ROV, then you end up following the valid
> shorter prefix to the destination.

I can't quite recall which Cloudflare prefixes were impacted. If you
have a sniff at https://bgp.he.net/AS13335#_prefixes and
https://bgp.he.net/AS13335#_prefixes6 you will see that Cloudflare have
a larger portion of their IPv6 prefixes ROA'd than the IPv4 ones. If you
remember which Cloudflare prefixes were affected by the Verizon debacle,
we can have a closer look.


>   Quite possibly that points at the
> upstream which sent you the more-specific which you rejected, at which
> point your packets end up same going to the same place they would have
> gone if you had accepted the invalid more-specific.

But that's my point... we did not have the chance to drop any of the
affected Cloudflare prefixes because we do not use the ARIN TAL.

That means that we are currently ignoring the RPKI value of Cloudflare's
prefixes that are under ARIN.

Also, AFAICT, none of our current upstreams are doing ROV. You can see
that list here:

    https://bgp.he.net/AS37100#_graph4

Mark.