Re: BGP Monitoring

[Ben Cox via NANOG]

Aha! That makes sense!

I was struggling to find any kind of public data on who runs it, so I
assumed whoever was presenting it probably runs / owned it

On Tue, Feb 27, 2024, 08:20 Fearghas Mckay  wrote:

>
>
> On 27 Feb 2024, at 01:28, Ben Cox via NANOG  wrote:
>
> I believe PacketVis is Massimo Candela , based on
> https://ripe85.ripe.net/archives/video/987/
>
>
> It is run by his brother rather than Massimo, but it is his BGPalerter
> software behind the family business :)
>
> f
>

Re: BGP Monitoring

[Ben Cox via NANOG]

I believe PacketVis is Massimo Candela , based on
https://ripe85.ripe.net/archives/video/987/

On Mon, 26 Feb 2024 at 18:24, Denis Fondras via NANOG  wrote:
>
> Le Mon, Feb 26, 2024 at 07:12:57PM +0100, Job Snijders via NANOG a écrit :
> > On Mon, Feb 26, 2024 at 05:41:12PM +, Ray Orsini via NANOG wrote:
> > > What tools are you using to monitor BGP announcements and route changes?
> >
> > The wonderful BGP.tools already has been mentioned a few times.
> >
> > Another excellent option is https://Packetvis.com, I find their RPKI
> > monitoring approach to be very insightful.
> >
>
> Do you know who's behind that site ?
>
> Denis

Re: BGP Monitoring

[Ben Cox via NANOG]

[Full Disclosure, the bgp.tools guy will of course tell you to use bgp.tools]

Unsure what the etiquette for self promotion is on this mailing list,
but I would happily recommend bgp.tools (the service I run). It
supports the development of the BGP toolkit at the same time.

For myself (since I cannot really monitor myself with myself) I use
https://github.com/nttgin/BGPalerter


On Mon, 26 Feb 2024 at 17:43, Ray Orsini via NANOG  wrote:
>
> What tools are you using to monitor BGP announcements and route changes?
>

Re: Any clue as to when bgp.he.net will be back?

[Ben Cox via NANOG]

I spoke with someone at Mimecast and we concluded the the customer of
mimecast has setup that rule (likely the whole of *.tools), since they
could not find anything on there end that didnt like bgp.tools



On Wed, Jan 17, 2024 at 10:54 PM Christopher Hawker
 wrote:
>
> It'd be interesting to know how Mimecast made the determination that 
> bgp.tools is compromised.
>
> Regards,
> Christopher Hawker
>
> On Thu, 18 Jan 2024 at 09:47, Rubens Kuhl  wrote:
>>
>> It might be due to usage of a new gTLD like .tools. A number of new
>> gTLDs use heavy discounting and this is a magnet for abusive
>> registrations, unfortunately.
>>
>> Rubens
>>
>> On Wed, Jan 17, 2024 at 2:15 PM Tim Burke  wrote:
>> >
>> > +1 for bgp.tools, it is a superior tool. Sadly, the corporate IT-forced 
>> > DNS filtering at work for “cybersecurity” (Mimecast) thinks it is a 
>> > compromised website for some reason, so bgp.he.net ends up being used 
>> > while I am at the office.
>> >
>> > On Jan 16, 2024, at 8:44 AM, Ian Chilton  wrote:
>> >
>> > Hi,
>> >
>> > Not a direct answer to your question, but if you're not aware of it, 
>> > https://bgp.tools/ is a great tool and shows the same info.
>> >
>> > Ian
>> >
>> >

Re: Any clue as to when bgp.he.net will be back?

[Ben Cox via NANOG]

Fixed, cheers for pointing that logical error out :)

$ git show
commit 689bca929c5d3a27e6aa4f12195bf3b81b3be719 (HEAD -> master)
Author: Ben Cartwright-Cox 
Date:   Tue Jan 16 23:17:08 2024 +

clarify pricing for a nanog person

https://mailman.nanog.org/pipermail/nanog/2024-January/224556.html

diff --git a/www/templates/layouts/utils.tmpl.html
b/www/templates/layouts/utils.tmpl.html
index 5d1a4dbd..3ca554a3 100644
--- a/www/templates/layouts/utils.tmpl.html
+++ b/www/templates/layouts/utils.tmpl.html
@@ -443,7 +443,7 @@
   
 £200 / mo
 
-Originates more than a /15 of IPv4
+Originates a /15 or more of IPv4 addresses
 -
 Is tagged as a CDN or DDoS Mitigation provider
 -

On Tue, Jan 16, 2024 at 10:04 PM scott via NANOG  wrote:
>
>
>
> On 1/16/24 2:44 PM, Ian Chilton wrote:
>
> > Not a direct answer to your question, but if you're not aware of it,
> > https://bgp.tools/  is a great tool and shows the
> > same info.
> --
>
> They need to fix their page regarding cost.
>
> Originates less than a /15 - 25 pounds/month
>
> Originates more than a /15 - 200 pounds/month.
>
> What if someone originates a /15?  That's one of the prefix sizes we
> originate.  They need a 'less than or equal to' thingie in there.
>
> scott

Re: {Disarmed} RE: IPv4 address block

[Ben Cox via NANOG]

Ah, apologies on my part Tony, it did look at lot like a signature block
and thus a amusing sock puppet SNAFU



On Mon, Jan 8, 2024, 20:54 Tony Wicks  wrote:

> No, Eddies is NOT me, I included his details to be helpful to the OP….
>
>
>
>
>
> *From:* Ben Cox 
> *Sent:* Tuesday, January 9, 2024 9:27 AM
> *To:* Tony Wicks 
> *Cc:* North American Network Operators' Group 
> *Subject:* Re: IPv4 address block
>
>
>
> Hey Tony/Eddie
>
>
>
> I think your choice of email signature may have given away the game a
> little bit here
>
>
>
> Regards
>
> Ben Cartwright-Cox
>
>
>
> On Mon, Jan 8, 2024, 20:00 Tony Wicks  wrote:
>
> I have used Eddie at iptrading several times over the yearsfor IP block
> purchases and never had this sort of issue, so would count this as a
> recommendation.
>
>
>
>
>
>
>
> Regards,
>
>
>
> Eddie Stauble
>
>
>
> ed...@iptrading.com
>
> 855-IPTRADE (855-478-7233) Ext 107  Direct: 754-227-8423
>
>
>
> 
>
>
>
>
>
> *From: NANOG  On Behalf Of John
> CurranSent: Monday, January 8, 2024 7:46 PMTo: Eric Kuhnke
> Cc: nanog@nanog.org list Subject:
> Re: IPv4 address block *
>
>   
>
> *MailScanner has detected a possible fraud attempt from "iptrading.com"
> claiming to be* On Jan 7, 2024, at 9:04 PM, Eric Kuhnke <
> *eric.kuh...@gmail.com*> wrote: 
>
>   
>
> I might note that one of the qualified facilitators on the list recently
> "sold" me a block where the original entity which obtained it in the 1990s
> was still announcing it to all of their peers and trantsi after the wire
> transfer had been done, the ARIN process was done/ticket closed, and the
> block resided with my AS. 
>
>   
>
> *MailScanner has detected a possible fraud attempt from "iptrading.com"
> claiming to be* Interesting.  If you believe that the qualified
> facilitator failed in their duty to you (more specifically, if they did not
> live up to an aspect of the code of conduct –
> *https://www.arin.net/resources/registry/transfers/facilitators/codeofconduct/*)
> then please drop ARIN a message with the specifics to
> *facilitator-supp...@arin.net*  
>
>   
>
> It took a significant amount of badgering the original block holder (an
> entity with which we had no pre-existing relationship or direct contacts
> into their engineering department) to get them to withdraw the
> announcement, which we did independently of the broker and quicker than
> they responded to us. So my message would be to do your own due diligence
> and investigation of IP space and don't trust what the "broker" tells you.
> 
>
>   
>
> Absolutely - always a good idea.  
>
>   
>
> Thanks for feedback!  
>
> /John 
>
>   
>
> John Curran 
>
> President and CEO 
>
> American Registry for Internet Numbers 
>
>   
>
>   
>
>   
>
>   
>
>

Re: IPv4 address block

[Ben Cox via NANOG]

Hey Tony/Eddie

I think your choice of email signature may have given away the game a
little bit here

Regards
Ben Cartwright-Cox

On Mon, Jan 8, 2024, 20:00 Tony Wicks  wrote:

> I have used Eddie at iptrading several times over the yearsfor IP block
> purchases and never had this sort of issue, so would count this as a
> recommendation.
>
>
>
>
>
>
>
> Regards,
>
>
>
> Eddie Stauble
>
>
>
> ed...@iptrading.com
>
> 855-IPTRADE (855-478-7233) Ext 107  Direct: 754-227-8423
>
>
>
> 
>
> *From:* NANOG  *On Behalf Of *John
> Curran
> *Sent:* Monday, January 8, 2024 7:46 PM
> *To:* Eric Kuhnke 
> *Cc:* nanog@nanog.org list 
> *Subject:* Re: IPv4 address block
>
>
>
> On Jan 7, 2024, at 9:04 PM, Eric Kuhnke  wrote:
>
>
>
> I might note that one of the qualified facilitators on the list recently
> "sold" me a block where the original entity which obtained it in the 1990s
> was still announcing it to all of their peers and trantsi after the wire
> transfer had been done, the ARIN process was done/ticket closed, and the
> block resided with my AS.
>
>
>
> Interesting.  If you believe that the qualified facilitator failed in
> their duty to you (more specifically, if they did not live up to an aspect
> of the code of conduct –
> https://www.arin.net/resources/registry/transfers/facilitators/codeofconduct/)
> then please drop ARIN a message with the specifics to
> facilitator-supp...@arin.net
>
>
>
> It took a significant amount of badgering the original block holder (an
> entity with which we had no pre-existing relationship or direct contacts
> into their engineering department) to get them to withdraw the
> announcement, which we did independently of the broker and quicker than
> they responded to us. So my message would be to do your own due diligence
> and investigation of IP space and don't trust what the "broker" tells you.
>
>
>
> Absolutely - always a good idea.
>
>
>
> Thanks for feedback!
>
> /John
>
>
>
> John Curran
>
> President and CEO
>
> American Registry for Internet Numbers
>
>
>
>
>
>
>
>
>

Re: BGP hijack?

[Ben Cox via NANOG]

Hey everybody, I run bgp.tools, (And had a extremely busy alerting
engine for a few minutes)

>From what bgp.tools can see it seems like they had a private asn in
the path like so

```
2027 422027 6696 6939 42615 212232
```

This can be valid for a number of reasons, (  they might have been
doing some homemade BGP confederation for example ),  and I assume
then that they had enabled some kind of private asn filter that had
not quite done what they expected.  I think what they are expecting
was the part to look like this:

```
2027 6696 6939 42615 212232
```

However instead the private AS stripping function instead did this,
and sent it to their customers/collector feeds:

```
2027
```

This then obviously made everything look like a BGP origin hijack to
all of the route collectors and alerting systems.

It's worth noting that bgp.tools saw this from more than MilkyWan
directly, but also from what I can assume are their customers. But I
don't see any indication this faulty routing information propagated
anywhere else than that. ( To sort of backup the response that Vincent
has already provided us)

Hope this provides some interesting insight, and maybe some future heads up :)

On Sun, Oct 22, 2023 at 10:04 PM Christopher Morrow
 wrote:
>
> Hank, all exact match for prefix length? Or longer subnets covering the whole?
> (Is this leakage of a optimizer or possibly censorship leakage?)
>
> On Sun, Oct 22, 2023, 1:03 PM Olivier Benghozi  
> wrote:
>>
>> Same stuff (with our ASN and our prefixes) detected here, coming from AS2027 
>> (Milkywan), for a short time...
>>
>> Le dim. 22 oct. 2023 à 17:18, Hank Nussbacher  a écrit 
>> :
>>>
>>> We just had every single prefix in AS378 start being announced by AS2027.
>>>
>>> Every announcement by AS2027 is failing RPKI yet being propagated a bit.
>>> Is this yet another misbehaving device or an actual attack?
>>
>>
>> Ce message et toutes les pièces jointes (ci-après le "message") sont établis 
>> à l’intention exclusive des destinataires désignés. Il contient des 
>> informations confidentielles et pouvant être protégé par le secret 
>> professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
>> immédiatement l'expéditeur et de détruire le message. Toute utilisation de 
>> ce message non conforme à sa destination, toute diffusion ou toute 
>> publication, totale ou partielle, est interdite, sauf autorisation expresse 
>> de l'émetteur

Re: Cogent Abuse - Bogus Propagation of ASN 36471

[Ben Cox via NANOG]

Can you confirm what you mean by compromised here?

The prefixes currently (as far as I can see from bgp.tools) originated are:

Prefix   Description
209.255.244.0/24 Windstream Communications LLC
209.255.245.0/24 CONSOLIDATED TECHNOLOGIES INC 325 HUDSON
209.255.246.0/24 Windstream Communications LLC
209.255.247.0/24 CONSOLIDATED TECHNOLOGIES INC 325 HUDSON
216.197.80.0/20 --

The 209.xx have valid RPKI certs, so they seem validish, but all have
RADB IRR entries made by lightower.com in 2015.

Do you mean that someone has impersonated AS36471 and set up a cogent
port, and is now announcing your space? I'm confused

On Thu, Jul 20, 2023 at 3:32 PM Pete Rohrman
 wrote:
>
> NANOG,
>
> A customer of Cogent has a compromised router that is announcing
> prefixes sourced from AS 36471.   Cogent is propagating that to the
> world.  Problem is, those prefixes and AS don't belong to that customer
> of Cogent - AS 36471 belongs to Kratos Defense & Security Solutions,
> Inc. (see whois).
>
> Requests to Cogent Support and Abuse go un-actioned.  Need a contact at
> Cogent Abuse that can shut down that compromised router.  Anyone have a
> good contact at Cogent Abuse Dept?
>
> Cogent ticket: HD302928500
>
> Pete
>
> --
> Pete
> Stage2 "Survivor Island" Bronze Medal Winner

Re: Google Speed Test

[Ben Cox via NANOG]

Search "speed test" and Google search had one built in

On Wed, 28 Dec 2022, 16:43 Mike Hammett,  wrote:

> Does AS15169 have a speed test? It would be nice to gauge the capacity to
> a particular network that's something laypeople could do. I could host
> something in GCP myself, but cloud is expensive.
>
> -
> Mike Hammett
> [ http://www.ics-il.com/ | Intelligent Computing Solutions ]
> [ https://www.facebook.com/ICSIL ] [
> https://plus.google.com/+IntelligentComputingSolutionsDeKalb ] [
> https://www.linkedin.com/company/intelligent-computing-solutions ] [
> https://twitter.com/ICSIL ]
> [ http://www.midwest-ix.com/ | Midwest Internet Exchange ]
> [ https://www.facebook.com/mdwestix ] [
> https://www.linkedin.com/company/midwest-internet-exchange ] [
> https://twitter.com/mdwestix ]
> [ http://www.thebrotherswisp.com/ | The Brothers WISP ]
> [ https://www.facebook.com/thebrotherswisp ] [
> https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg ]
>

Re: What's going on with AS147028?

[Ben Cox via NANOG]

I run bgp.tools (with it's own route collectors, that people should
totally feed :) https://bgp.tools/kb/setup-sessions ) but I feel like
I can add some insight here to what I think is happening with
AS147028.

I've had multiple issues with networks feeding me that also are on
LL-IX (https://www.peeringdb.com/ix/2343) or LL-HOST (Maybe? AS59947).

It appears (based on my discussions with a few of the offending
networks) that LL-IX or LL-HOST strips their own ASN (59947) from the
path when you take up a transit or maybe (i'm not sure) peer on their
route servers on LL-IX

When you combine this and exporting to projects like RouteViews/RIPE
RIS/bgp.tools, you get a peer graph that looks like the feeder ASN is
peering with... almost everyone who AS59947 peers with.

This has become so much of a problem (as I am slightly mad for getting
this kind of data right) that bgp.tools disallows sessions to be setup
if it looks like the AS either is upstreamed by AS59947 or has a port
with LL-IX, (with a message to email me)

The users who do email me, about 50% of them commit to adding the
AS59947 ASN back on, and I enable their ability to export to
bgp.tools.

Hope this clears things up! This exact AS has been the cause of many
frustrations for me for a while now!

On Tue, Jul 12, 2022 at 11:22 PM Mike Leber via NANOG  wrote:
>
> This kind of thing is a problem from time to time with the data we get
> from route collectors.
>
> When we see it we have to add the culprit ASN to a filter list we keep
> in bgp.he.net.
>
> It tends to be a repeat problem with some collectors and some ASNs.
>
> We haven't really figured out why people send junk routes to route
> collectors.
>
> The things we've seen aren't just route leaks.  We've seen a variety of
> AS path spoofing.
>
> We've already added this specific ASN to the filter list and pushed an
> update for bgp.he.net.
>
> Note, this email is specifically talking about routes received from
> route collectors and not routes operationally received by he.net via BGP
> sessions with actual networks.
>
> Mike.
>
> On 7/12/22 12:49 PM, Eric Dugas via NANOG wrote:
> > A friend of mine mentioned that both our Canadian ASNs were listed in
> > AS147028's peer list on https://bgp.he.net/AS147028 but we have no
> > adjacency to this network.
> >
> > Their peer count jumped from 1 in May 2022 to 1,800 and just a few
> > days ago jumped to 8,800. Beside NL-IX, all the IX they are listed on
> > are virtual IX with a few dozen "hobby networks".
> >
> > The only lead I have is they use HE as transit and they're pumping
> > back BGP feed to route collectors like RIPE RIS or Route Views with
> > routes stripped of HE's ASN.
> >
> > Eric
> >

Re: Zayo Contact

[Ben Cox via NANOG]

Just in case - how are you checking they are announced?

Is there a chance they are stuck routes as documented (self blog post) here
( https://blog.benjojo.co.uk/post/bgp-stuck-routes-tcp-zero-window ) ?

On Fri, 16 Jul 2021, 01:20 Dave Browning,  wrote:

> Anyone on the list from Zayo NOC who can assist with removing a couple of
> /24's from their table that isn't actually being advertised to them?
>
> Dave Browning | dlbNetworks
> 0413 579 391 | 07 3088 2274
>