Re: Comcast Contact

[Matt Freitag]

Contact made, thank you NANOG.

Re: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?

[nusenu]

Montgomery, Douglas (Fed):
> Our effort to get our new monitor transitioned to a public facing
> system ran into a wall for ~35 days.  Unfortunately during that time,
> the visa of a visiting researcher leading that effort expired.
> 
> We have almost recovered from all of that.  Unfortunately, we have a
> bit of a bureaucracy to deploying public facing systems.  So I would
> guess it will take ~end of March to get it on-line.

I'm curious, are there any updates on this topic?

thanks!
nusenu
 

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature

RE: Cisco Crosswork Network Insights - or how to destroy a useful service

[Marcin Gondek]

Hi,

Maybe you should contact https://www.isolario.it/ for intergration?

Thanks,


-- 
Marcin Gondek / Drixter
http://fido.e-utp.net/
AS56662

-Original Message-
From: NANOG  On Behalf Of Vasileios Kotronis
Sent: Wednesday, May 15, 2019 10:27 PM
To: Dale W. Carder 
Cc: nanog@nanog.org
Subject: Re: Cisco Crosswork Network Insights - or how to destroy a useful 
service

Hello,

we would be happy to collaborate to deploy and extend the ARTEMIS open-source 
software tool

for monitoring, detection and potential automated mitigation of prefix hijacks,

available on GitHub at https://github.com/FORTH-ICS-INSPIRE/artemis .

Current monitoring sources include RIS live, BGPStream (classic RV + RIS and 
beta BMP support) and ExaBGP APIs to local monitors.

You are most welcome to check out the code and test, provide feedback and/or 
integrate with existing custom tools you might use.

Best regards,

Vasileios

On 15/5/19 8:58 μ.μ., Dale W. Carder wrote:
> Thus spake Job Snijders (j...@ntt.net) on Wed, May 15, 2019 at 12:16:06PM 
> +0200:
>> I recognise the issue you describe, and I'd like to share with you 
>> that we're going down another road. Nowadays, RIPE NCC offers a 
>> streaming API ("RIS Live") which has the data needed to analyse and 
>> correlate BGP UPDATES seen in the wild to business rules you as operator 
>> define.
>>
>> NTT folks are working on https://github.com/nlnog/bgpalerter/ - which 
>> relies on "RIPE RIS Live", this software should become a competitive 
>> replacement to current BGP monitoring tools. Stay tuned, the software 
>> will be more useful in the course of the next few weeks.
> Similarly, one can integrate CAIDA's BGPStream Broker Service[1] into 
> their own tools.  Like bgpalerter above, working with open source or 
> rolling your own tools is increasingly straightforward[2] due to these 
> community projects.
>
> Another viable project to keep an eye on is ARTEMIS[3] for monitoring.
>
> Dale
>
> [1] https://bgpstream.caida.org/data
> [2] https://github.com/dwcarder/bgpwatch
> [3] https://www.inspire.edu.gr/artemis/

--
===
Vasileios Kotronis
Postdoctoral Researcher, member of the INSPIRE Group INSPIRE = INternet 
Security, Privacy, and Intelligence REsearch Telecommunications and Networks 
Lab (TNL) Foundation for Research and Technology - Hellas (FORTH) Leoforos 
Plastira 100, Heraklion 70013, Greece
Tel: +302810391241 Office: G-060
e-mail : vkotro...@ics.forth.gr
url: http://inspire.edu.gr
===

Comcast Contact

[matt]

Hi all,

I'm looking for a contact at Comcast, been having an issue in the  
Baltimore area for about three weeks and am getting stonewalled by  
front line support.


Thank you for your time.

Matt Freitag

Re: BGP prefix filter list

[Blake Hudson]

Ca, taking a self-originated default route (with or without an 
additional partial view of the global routing table) from your transit 
provider's edge router seems to make the assumption that your transit 
provider's edge router either has a full table or a working default 
route itself. In the case of transit provider outages (planned or 
unplanned), the transit provider's edge router that you peer with may be 
up and reachable (and generating a default route to your routers), but 
may not have connectivity to the greater internet. Put another way, if 
your own routers don't have a full routing table then they don't have 
enough information to make intelligent routing decisions and are 
offloading that responsibility onto the transit provider. IMHO, what's 
the point of being multi-homed if you can't make intelligent routing 
decisions and provide routing redundancy in the case of a transit 
provider outage?




Mike Hammett wrote on 5/15/2019 2:19 PM:
As an eyeball network myself, you'll probably want to look at those 
things. You don't need to run a CDN to know where your bits are going.




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

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


*From: *"Ca By" 
*To: *"Mike Hammett" 
*Cc: *"Dan White" , nanog@nanog.org
*Sent: *Wednesday, May 15, 2019 2:14:21 PM
*Subject: *Re: BGP prefix filter list



On Wed, May 15, 2019 at 11:52 AM Mike Hammett > wrote:


You can't do uRPF if you're not taking full routes.


I would never do uRPF , i am not a transit shop, so no problem there. 
BCP38 is as sexy as i get.



You also have a more limited set of information for analytics if
you don't have full routes.


Yep, i don’t run a sophisticate internet  CDN either. Just pumping 
packets from eyeballs to clouds and back, mostly.




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

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


*From: *"Ca By" mailto:cb.li...@gmail.com>>
*To: *"Dan White" mailto:dwh...@olp.net>>
*Cc: *nanog@nanog.org 
*Sent: *Wednesday, May 15, 2019 1:50:41 PM

*Subject: *Re: BGP prefix filter list



On Wed, May 15, 2019 at 7:27 AM Dan White mailto:dwh...@olp.net>> wrote:

On 05/15/19 13:58 +, Phil Lavin wrote:
>> We're an eyeball network. We accept default routes from our
transit
>> providers so in theory there should be no impact on
reachability.
>>
>> I'm pretty concerned about things that I don't know due to
inefficient
>> routing, e.g. customers hitting a public anycast DNS server
in the wrong
>> location resulting in Geolocation issues.
>
>Ah! Understood. The default route(s) was the bit I missed.
Makes a lot of
>sense if you can't justify buying new routers.
>
>Have you seen issues with Anycast routing thus far? One would
assume that
>routing would still be fairly efficient unless you're picking
up transit
>from non-local providers over extended L2 links.

We've had no issues so far but this was a recent change. There
was no
noticeable change to outbound traffic levels.


+1, there is no issue with this approach.

i have been taking “provider routes” + default for a long time,
works great.

This makes sure you use each provider’s “customer cone” and SLA to
the max while reducing your route load / churn.

IMHO, you should only take full routes if your core business is
providing full bgp feeds to downstrean transit customers.


-- 
Dan White

BTC Broadband
Network Admin Lead
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610            email: dwh...@mybtc.com

http://www.btcbroadband.com

Re: BGP prefix filter list

[Ahad Aboss]

Hi Baldur,

Have you tried disabling storage of received updates from your upstream on
your edge/PE or Border? Just remove *soft-reconfiguration inbound* for eBGP
peering with your upstream/s. This will resolve your issue.

If you have multiple links to different upstream providers and you want to
simplify your network operation, you might want to introduce a pair of
route reflectors to handle all your IP and MPLS VPN routes...

Cheers,
Ahad


On Thu, May 16, 2019 at 4:24 AM Baldur Norddahl 
wrote:

> Hello
>
> On Wed, May 15, 2019 at 3:56 PM Mike Hammett  wrote:
>
>> What is the most common platform people are using with such limitations?
>> How long ago was it deprecated?
>>
>>
>>
> We are a small network with approx 10k customers and two core routers. The
> routers are advertised as 2 million FIB and 10 million RIB.
>
> This morning at about 2 AM CET our iBGP session between the two core
> routers started flapping every 5 minutes. This is how long it takes to
> exchange the full table between the routers. The eBGP sessions to our
> transits were stable and never went down.
>
> The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4,
> IPv6 and VRF in a single session.
>
> We are working closely together with another ISP that have the same
> routers. His network went down as well.
>
> Nothing would help until I culled the majority of the IPv6 routes by
> installing a default IPv6 route together with a filter, that drops every
> IPv6 route received on our transits. After that I could not make any more
> experimentation. Need to have a maintenance window during the night.
>
> These routers have shared IPv4 and IPv6 memory space. My theory is that
> the combined prefix numbers is causing the problem. But it could also be
> some IPv6 prefix first seen this night, that triggers a bug. Or something
> else.
>
> Regards,
>
> Baldur
>
>
>

Re: BGP prefix filter list

[Mark Tinka]

On 15/May/19 19:20, Mike wrote:

>
> This is very true. I picked up a nicely equipped juniper mx240 -
> waa overkill for my current operation - for far, far cheaper than
> anything I could have otherwise afforded new. Absolutely killer could
> not be happier, and J has won a convert. But, I find this seems to be
> the thing - needing capacity/feature sets/etc just to be able to stand
> still, but not having the revenue stream to actually pay new for what
> these vendors want to charge for their gear/licenses/etc.
>

It is a quagmire, isn't it?

The revenue from capacity (Ethernet, IP, DWDM, SDH) is falling every
year, to a point where it stops becoming a primary revenue source for
any telecoms provider. However, the cost of equipment is not following
suit, be it on the IP, Transport or Mobile side, terrestrial, marine or
wireless.

Work that is going on in the open space around all of this for hardware
and software needs to pick its pace up, otherwise this disconnect
between the loss of revenue and the cost of capex will remain.

Mark.