starlink ixp peering progress

[Dave Taht]

One of the things I learned today was that starlink has published an
extensive guide as to how existing BGP AS holders can peer with them
to get better service.

https://starlink-enterprise-guide.readme.io/docs/peering-with-starlink

I am curious if there is a way to see how many have peered already,
how many they could actually peer with?, and progress over time since
inception what would be the right tools for that? This is pretty
impressive for peering so far:

https://www.peeringdb.com/net/18747

Is there a better email list to discuss ixp stuff?


-- 
https://blog.cerowrt.org/post/2024_predictions/
Dave Täht CSO, LibreQos

Re: Why are paper LOAs still used?

[Christopher Hawker]

Hi Seth,

LOAs can't be considered more trustworthy than IRR objects. The RIRs operate 
IRRdb services as part of the services they offer which network operators 
should be using instead of the free and paid non-authoritative IRRdb operators.

If you don’t mind, could you please reach out to me off-list with who the VPS 
hosting provider is that is only accepting LOAs? I’d like to reach out to them 
to discuss their decision.

I’m doing a talk at APRICOT 2024 on using ROAs to replace LOAs. In my view 
there's no reason why network operators cannot use ROAs instead to validate the 
routes received from their peers, be they upstream or downstream.

Regards,
Christopher Hawker


Sent from my iPhone

On 27 Feb 2024, at 1:57 am, Seth Mattinen via NANOG  wrote:

Why do companies still insist on, or deploy new systems that rely on paper LOA 
for IP and ASN resources? How can this be considered more trustworthy than RIR 
based IRR records?

And I'm not even talking about old companies, I have a situation right now 
where a VPS provider I'm using will no longer use IRR and only accepts new 
paper LOAs. In the year 2024. I don't understand how anyone can go backwards 
like that.

~Seth

Re: BGP Monitoring

[Alexander Lyamin via NANOG]

Ray mentioned precisely that he wants to  monitor BGP announcements and
route changes.

Leak detection is kind of on a different level. You need a bit more  data
to effectively detect them. ( I kind of know that).

It makes discussion more colorful to my taste.  You can do a lot with
colorful bgp data ;)


On Mon, Feb 26, 2024 at 8:02 PM Elmar K. Bins  wrote:

>
> nanog@nanog.org (Alexander Lyamin via NANOG) wrote:
>
> > RIPE RIS
> >
> https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
> > is also good, but as Job Snijders pointed me out  doesn't send emails out
> > of the box.
>
> It does provide a filterable live feed that we use for leak detection.
>
> Apart from that we're using bgp.tools when we want to dig into stuff.
> Oh, and most of the T1s have either routeservers or at least mostly usable
> looking glasses.
>
> HTH,
> Elmar.
>

Re: Why are paper LOAs still used?

[Jason Canady]

We just switched over to IRR routing with Cogent, it is available.  It's 
just not on by default.


Best Regards,

Jason

On 2/26/24 3:14 PM, Aaron Wendel wrote:
I don't have any examples of anyone still using paper LOAs except for 
Cogent.


Aaron


On 2/26/2024 12:57 PM, Seth Mattinen via NANOG wrote:
Why do companies still insist on, or deploy new systems that rely on 
paper LOA for IP and ASN resources? How can this be considered more 
trustworthy than RIR based IRR records?


And I'm not even talking about old companies, I have a situation 
right now where a VPS provider I'm using will no longer use IRR and 
only accepts new paper LOAs. In the year 2024. I don't understand how 
anyone can go backwards like that.


~Seth

Re: Why are paper LOAs still used?

[Jay Hennigan]

On 2/26/24 10:57, Seth Mattinen via NANOG wrote:
Why do companies still insist on, or deploy new systems that rely on 
paper LOA for IP and ASN resources? How can this be considered more 
trustworthy than RIR based IRR records?


* They're an authoritative signed document with legal penalties for 
forgery.


* The same LOA is often required by datacenter operators and other third 
parties for cross-connect authority, etc.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: Why are paper LOAs still used?

[Sean Donelan]

Also known as an cross-connect order form.

Why FAX a piece of paper?

Nobody cross-checks it, until after it goes wrong.

On Mon, 26 Feb 2024, Ren Provo wrote:

Most important parts on the LOA are the explicit ASN, the name to be found
in the cross-connect order portal and local contact data.  Contractors need
that.

Global networks rarely have a contact appropriate for provisioning in a
public facing database.

On Mon, Feb 26, 2024 at 14:50 Sean Donelan  wrote:
  Authentication by letterhead?

  Paper LOAs are unauthenticated documents, not worth the paper
  they are
  written on. Usually FAXed, which is even less authenticatable
  (is that a
  word?).

  Prosecutors are capable of using digital documents. Do it all
  the time
  with echecks, credit cards, ecommerce orders and ACH payments. 
  But LOAs
  are typically civil disputes, not criminal, when someone
  mistypes an IP
  address.

  They should verifiy the information in the paper LOA with a
  registry
  anyway.  Since LOAs have no intrinsic value, wouldn't be worth
  the
  prosecutors time.

  Usually a salesperson or order entry clerk thinks its required
  because
  they've always required it.  But no one in the legal department
  actually
  knows what to do with a LOA or how to authenticate them.

  Because carriers never authenticate LOAs.


  On Mon, 26 Feb 2024, Matt Erculiani wrote:
  > A paper LOA is a legally binding document, an IRR record is an
  IRR record.
  > Falsifying an LOA that is transmitted digitally is wire fraud
  and can
  > basically be handed right over to a DA for injunction and
  prosecution.
  >
  > Falsifying IRR records on the other hand leaves more work for
  the ISP's
  > lawyers to walk a judge (and jury) through the entire purpose
  and use of
  > that system, as opposed to "here's a super important sheet of
  paper that
  > they lied on case closed". 
  >
  > -Matt
  >
  > On Mon, Feb 26, 2024 at 11:57 AM Seth Mattinen via NANOG
  
  > wrote:
  >       Why do companies still insist on, or deploy new systems
  that
  >       rely on
  >       paper LOA for IP and ASN resources? How can this be
  considered
  >       more
  >       trustworthy than RIR based IRR records?
  >
  >       And I'm not even talking about old companies, I have a
  situation
  >       right
  >       now where a VPS provider I'm using will no longer use
  IRR and
  >       only
  >       accepts new paper LOAs. In the year 2024. I don't
  understand how
  >       anyone
  >       can go backwards like that.
  >
  >       ~Seth
  >
  >
  >
  > --
  > Matt Erculiani
  >
  >

Re: Why are paper LOAs still used?

[Aaron Wendel]

I don't have any examples of anyone still using paper LOAs except for 
Cogent.


Aaron


On 2/26/2024 12:57 PM, Seth Mattinen via NANOG wrote:
Why do companies still insist on, or deploy new systems that rely on 
paper LOA for IP and ASN resources? How can this be considered more 
trustworthy than RIR based IRR records?


And I'm not even talking about old companies, I have a situation right 
now where a VPS provider I'm using will no longer use IRR and only 
accepts new paper LOAs. In the year 2024. I don't understand how 
anyone can go backwards like that.


~Seth

Re: Why are paper LOAs still used?

[Tom Samplonius]

  There is one purpose:  to facilitate IP fraud, and maintain currently 
fraudulently routed IPs.

  Anyone can dummy up a LOA.  And there is still quite a lot of unrouted IP 
space.  VPS providers know this, and know their customers are submitting fake 
LOAs.  But it is sort of the business VPS providers are in.

  Is it some sort of serious crime in the US though?  Well, just submit the LOA 
from outside the US.  Plus, the entity being defrauded is the IP holder, not 
the VPS provider or their customer.  If you are an IP holder, good luck getting 
the VPS provider to give you a copy of the fake LOA.  It is not in their 
interest to throw their customers under the bus.  You would have to give them a 
court order.  So if you look for unrouted IP space, registered to a non-US 
organization (ex. Canada), and submit a fake LOA from another country (London, 
UK for instance), you are unlikely to get tracked down for wire fraud.

  And you might ask, well, why would a VPS provider accept an LOA from the UK 
for an IP block registered to a Canadian organization?  Well, clearly it isn’t 
in the VPS provider’s interest to look into the LOAs too much.  As long as the 
IP space is unrouted, they will approve it.  The LOA is basically just a 
liability shield for the VPS provider.  It is not a crime to be deceived, 
though the due diligence beggars belief.

  So I had this happen.  There was a /24 being hijacked by a VPS provider.  I 
told them this was fraud, and they asked me if I wanted to “rescind the LOA”.  
I told them I never gave them a LOA.  They dropped the /24 immediately.  They 
refused to provide a copy of the LOA.  So pretty hard to pursue any sort of 
wire fraud charges.

  So a VPS provider asking for a paper LOA is basically asking you to lie to 
them, to protect them from liability.  They will just drop the IP prefix if 
there is any contact from the actual IP holder.



Tom



> On Feb 26, 2024, at 10:57 AM, Seth Mattinen via NANOG  wrote:
> 
> Why do companies still insist on, or deploy new systems that rely on paper 
> LOA for IP and ASN resources? How can this be considered more trustworthy 
> than RIR based IRR records?
> 
> And I'm not even talking about old companies, I have a situation right now 
> where a VPS provider I'm using will no longer use IRR and only accepts new 
> paper LOAs. In the year 2024. I don't understand how anyone can go backwards 
> like that.
> 
> ~Seth

Re: Why are paper LOAs still used?

[Ren Provo]

Most important parts on the LOA are the explicit ASN, the name to be found
in the cross-connect order portal and local contact data.  Contractors need
that.

Global networks rarely have a contact appropriate for provisioning in a
public facing database.

On Mon, Feb 26, 2024 at 14:50 Sean Donelan  wrote:

> Authentication by letterhead?
>
> Paper LOAs are unauthenticated documents, not worth the paper they are
> written on. Usually FAXed, which is even less authenticatable (is that a
> word?).
>
> Prosecutors are capable of using digital documents. Do it all the time
> with echecks, credit cards, ecommerce orders and ACH payments.  But LOAs
> are typically civil disputes, not criminal, when someone mistypes an IP
> address.
>
> They should verifiy the information in the paper LOA with a registry
> anyway.  Since LOAs have no intrinsic value, wouldn't be worth the
> prosecutors time.
>
> Usually a salesperson or order entry clerk thinks its required because
> they've always required it.  But no one in the legal department actually
> knows what to do with a LOA or how to authenticate them.
>
> Because carriers never authenticate LOAs.
>
>
> On Mon, 26 Feb 2024, Matt Erculiani wrote:
> > A paper LOA is a legally binding document, an IRR record is an IRR
> record.
> > Falsifying an LOA that is transmitted digitally is wire fraud and can
> > basically be handed right over to a DA for injunction and prosecution.
> >
> > Falsifying IRR records on the other hand leaves more work for the ISP's
> > lawyers to walk a judge (and jury) through the entire purpose and use of
> > that system, as opposed to "here's a super important sheet of paper that
> > they lied on case closed".
> >
> > -Matt
> >
> > On Mon, Feb 26, 2024 at 11:57 AM Seth Mattinen via NANOG <
> nanog@nanog.org>
> > wrote:
> >   Why do companies still insist on, or deploy new systems that
> >   rely on
> >   paper LOA for IP and ASN resources? How can this be considered
> >   more
> >   trustworthy than RIR based IRR records?
> >
> >   And I'm not even talking about old companies, I have a situation
> >   right
> >   now where a VPS provider I'm using will no longer use IRR and
> >   only
> >   accepts new paper LOAs. In the year 2024. I don't understand how
> >   anyone
> >   can go backwards like that.
> >
> >   ~Seth
> >
> >
> >
> > --
> > Matt Erculiani
> >
> >
>

Re: Verizon Business Contact

[Richard Laager]

To close the loop on this, Verizon Wireless reported to me that they 
fixed the issue (whatever it was).


They further said that 63.56.37.4 was a typo; all IPs should have been 
in 63.59.x.x.


I am able to reach the 63.59.0.0/16 IPs in question: 63.59.39.232 & 
63.59.67.68.


Justin: Thanks for the detail that this was reproducible from Cogent's 
looking glass. I think there's a good chance that contributed to them 
being able to find it (i.e. having an easy way for them to test).


--
Richard

Re: Why are paper LOAs still used?

[Sean Donelan]

Authentication by letterhead?

Paper LOAs are unauthenticated documents, not worth the paper they are 
written on. Usually FAXed, which is even less authenticatable (is that a 
word?).


Prosecutors are capable of using digital documents. Do it all the time 
with echecks, credit cards, ecommerce orders and ACH payments.  But LOAs 
are typically civil disputes, not criminal, when someone mistypes an IP 
address.


They should verifiy the information in the paper LOA with a registry 
anyway.  Since LOAs have no intrinsic value, wouldn't be worth the 
prosecutors time.


Usually a salesperson or order entry clerk thinks its required because 
they've always required it.  But no one in the legal department actually 
knows what to do with a LOA or how to authenticate them.


Because carriers never authenticate LOAs.


On Mon, 26 Feb 2024, Matt Erculiani wrote:

A paper LOA is a legally binding document, an IRR record is an IRR record.
Falsifying an LOA that is transmitted digitally is wire fraud and can
basically be handed right over to a DA for injunction and prosecution.

Falsifying IRR records on the other hand leaves more work for the ISP's
lawyers to walk a judge (and jury) through the entire purpose and use of
that system, as opposed to "here's a super important sheet of paper that
they lied on case closed". 

-Matt

On Mon, Feb 26, 2024 at 11:57 AM Seth Mattinen via NANOG 
wrote:
  Why do companies still insist on, or deploy new systems that
  rely on
  paper LOA for IP and ASN resources? How can this be considered
  more
  trustworthy than RIR based IRR records?

  And I'm not even talking about old companies, I have a situation
  right
  now where a VPS provider I'm using will no longer use IRR and
  only
  accepts new paper LOAs. In the year 2024. I don't understand how
  anyone
  can go backwards like that.

  ~Seth



--
Matt Erculiani

Re: Why are paper LOAs still used?

[Peter Potvin via NANOG]

I can’t speak for all providers but when it comes to some downstream
networks we will usually request an LOA as additional proof that the
customer is authorized to announce the prefixes, in addition to the IRR
objects and (where possible) RPKI ROAs. Mainly only a thing where RPKI is
not possible and the only route object available is in a non-auth database
such as RADB. Overall it helps keep a paper trail (as Tom said) in case
someone comes knocking.

Kind regards,
Peter


On Mon, Feb 26, 2024 at 14:13 Tom Beecher  wrote:

> Perhaps the provider only had a single person maintaining the tooling they
> used to interact with the IRR records, that person left/was laid off, and
> it broke. Perhaps they don't have anyone else that can make it work again,
> and they don't want to hire someone else, so they fell back to paper.
>
> Perhaps they have a legal reason to require a paper trail and not rely on
> IRR records.
>
> Plenty of possibilities, all plausible.
>
> On Mon, Feb 26, 2024 at 1:58 PM Seth Mattinen via NANOG 
> wrote:
>
>> Why do companies still insist on, or deploy new systems that rely on
>> paper LOA for IP and ASN resources? How can this be considered more
>> trustworthy than RIR based IRR records?
>>
>> And I'm not even talking about old companies, I have a situation right
>> now where a VPS provider I'm using will no longer use IRR and only
>> accepts new paper LOAs. In the year 2024. I don't understand how anyone
>> can go backwards like that.
>>
>> ~Seth
>>
>

Re: Why are paper LOAs still used?

[Daniel Marks via NANOG]

Highly anecdotal, but we’ve always refused to provide them, and they’ve always 
set it up without an LOA.

YMMV since we negotiate larger contracts, but we’ve only ever been asked maybe 
twice? Both times they admitted they had no idea why they asked for it, so it 
just seems like some process they forgot to get rid of.

-Dan 

> On Feb 26, 2024, at 13:59, Seth Mattinen via NANOG  wrote:
> 
> Why do companies still insist on, or deploy new systems that rely on paper 
> LOA for IP and ASN resources? How can this be considered more trustworthy 
> than RIR based IRR records?
> 
> And I'm not even talking about old companies, I have a situation right now 
> where a VPS provider I'm using will no longer use IRR and only accepts new 
> paper LOAs. In the year 2024. I don't understand how anyone can go backwards 
> like that.
> 
> ~Seth

Re: Why are paper LOAs still used?

[Joe via NANOG]

One thing that I recently read on this mailing list, is that at least in the 
US, a transmitting a fraudulent LOA is a federal crime - wire fraud. [0]

Being able to hopefully charge and convict someone performing fraud is a useful 
deterrent.

-joe

[0] - 
https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf,
 page 13.


On 2/26/2024 at 12:58 PM, "Seth Mattinen via NANOG"  wrote:
>
>Why do companies still insist on, or deploy new systems that rely 
>on 
>paper LOA for IP and ASN resources? How can this be considered 
>more 
>trustworthy than RIR based IRR records?
>
>And I'm not even talking about old companies, I have a situation 
>right 
>now where a VPS provider I'm using will no longer use IRR and only 
>accepts new paper LOAs. In the year 2024. I don't understand how 
>anyone 
>can go backwards like that.
>
>~Seth

Re: Why are paper LOAs still used?

[Matt Erculiani]

A paper LOA is a legally binding document, an IRR record is an IRR record.

Falsifying an LOA that is transmitted digitally is wire fraud and can
basically be handed right over to a DA for injunction and prosecution.

Falsifying IRR records on the other hand leaves more work for the ISP's
lawyers to walk a judge (and jury) through the entire purpose and use of
that system, as opposed to "here's a super important sheet of paper that
they lied on case closed".

-Matt

On Mon, Feb 26, 2024 at 11:57 AM Seth Mattinen via NANOG 
wrote:

> Why do companies still insist on, or deploy new systems that rely on
> paper LOA for IP and ASN resources? How can this be considered more
> trustworthy than RIR based IRR records?
>
> And I'm not even talking about old companies, I have a situation right
> now where a VPS provider I'm using will no longer use IRR and only
> accepts new paper LOAs. In the year 2024. I don't understand how anyone
> can go backwards like that.
>
> ~Seth
>


-- 
Matt Erculiani

Re: Why are paper LOAs still used?

[John Kristoff]

On Mon, 26 Feb 2024 10:57:05 -0800
Seth Mattinen via NANOG  wrote:

> Why do companies still insist on, or deploy new systems that rely on 
> paper LOA for IP and ASN resources? How can this be considered more 
> trustworthy than RIR based IRR records?

For routing, some have been proposing that the RPKI.  There was some
discussion here a few months ago:

  

Shortly thereafter this blog post appeared:

  

> And I'm not even talking about old companies, I have a situation
> right now where a VPS provider I'm using will no longer use IRR and
> only accepts new paper LOAs. In the year 2024. I don't understand how
> anyone can go backwards like that.

Did you ask them why or can you name the provider?

John

Re: Why are paper LOAs still used?

[Tom Beecher]

Perhaps the provider only had a single person maintaining the tooling they
used to interact with the IRR records, that person left/was laid off, and
it broke. Perhaps they don't have anyone else that can make it work again,
and they don't want to hire someone else, so they fell back to paper.

Perhaps they have a legal reason to require a paper trail and not rely on
IRR records.

Plenty of possibilities, all plausible.

On Mon, Feb 26, 2024 at 1:58 PM Seth Mattinen via NANOG 
wrote:

> Why do companies still insist on, or deploy new systems that rely on
> paper LOA for IP and ASN resources? How can this be considered more
> trustworthy than RIR based IRR records?
>
> And I'm not even talking about old companies, I have a situation right
> now where a VPS provider I'm using will no longer use IRR and only
> accepts new paper LOAs. In the year 2024. I don't understand how anyone
> can go backwards like that.
>
> ~Seth
>

Re: BGP Monitoring

[Elmar K. Bins]

nanog@nanog.org (Alexander Lyamin via NANOG) wrote:

> RIPE RIS
> https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
> is also good, but as Job Snijders pointed me out  doesn't send emails out
> of the box.

It does provide a filterable live feed that we use for leak detection.

Apart from that we're using bgp.tools when we want to dig into stuff.
Oh, and most of the T1s have either routeservers or at least mostly usable
looking glasses.

HTH,
Elmar.

Why are paper LOAs still used?

[Seth Mattinen via NANOG]

Why do companies still insist on, or deploy new systems that rely on 
paper LOA for IP and ASN resources? How can this be considered more 
trustworthy than RIR based IRR records?


And I'm not even talking about old companies, I have a situation right 
now where a VPS provider I'm using will no longer use IRR and only 
accepts new paper LOAs. In the year 2024. I don't understand how anyone 
can go backwards like that.


~Seth

Re: BGP Monitoring

[Alexander Lyamin via NANOG]

Whoa, its nice to see that Allesandro is still around.
It was sad to see when Isolario.it quietly went offline.

Also I would point out in CAIDA's general direction
https://bgpstream.caida.org/ (should fit OP bill).
CAIDA was first to show how much geeky fun might be had by monitoring (and
sometimes storing)  BGP updates.

RIPE RIS
https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
is also good, but as Job Snijders pointed me out  doesn't send emails out
of the box.

On Mon, Feb 26, 2024 at 7:15 PM Job Snijders via NANOG 
wrote:

> 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.
>
> Catchpoint might be another option, https://www.catchpoint.com/bgp,
> AFAIK by the same people that worked on "Isolario" a few years ago.
>
> Kind regards,
>
> Job
>

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

[Denis Fondras via NANOG]

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

[Job Snijders via NANOG]

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.

Catchpoint might be another option, https://www.catchpoint.com/bgp,
AFAIK by the same people that worked on "Isolario" a few years ago.

Kind regards,

Job

Re: BGP Monitoring

[Ian Chilton]

Hi,

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

https://bgp.tools is excellent - and amazingly fast at BGP and IRR 
notifications: https://bgp.tools/pricing

Ian

Re: BGP Monitoring

[TJ Trout]

bgp.tools

On Mon, Feb 26, 2024 at 9:54 AM Mehmet  wrote:

> I love bgp.tools ;) good product
>
> On Mon, Feb 26, 2024 at 12:49 Ben Cox via NANOG  wrote:
>
>> [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: BGP Monitoring

[Mehmet]

I love bgp.tools ;) good product

On Mon, Feb 26, 2024 at 12:49 Ben Cox via NANOG  wrote:

> [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: 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?
>

BGP Monitoring

[Ray Orsini via NANOG]

What tools are you using to monitor BGP announcements and route changes?

[OIT Website]
Ray Orsini
Chief Executive Officer
OIT, LLC
[cid:915068ae-ac24-488b-95e0-65fd40ea5afb]   305.967.6756 
x1009|  
[cid:6f566813-2e6f-4b77-86fb-6dcf7b370a8a]   305.571.6272
[cid:3bcb9fcf-e0d4-43db-afd5-f0d92d993db5]   
r...@oit.co   |  [https://www.oit.co] 
   www.oit.co
[cid:de964c1d-0360-48dc-99f4-11b48385b44b]
 oit.co/ray
[Facebook]
[LinkedIn]
[Twitter]
[YouTube]
Join the OITVOIP Family at the Right of Boom Event in Las Vegas, NV on March 
6th - 8th
Register Today! https://www.rightofboom.com/

Re: Network chatter generator

[Jason Healy via NANOG]

On 2024-02-23 17:33, Brandon Martin wrote:
> Before I go to the trouble of making one myself, does anybody happen to
> know of a pre-canned program to generate realistic and scalable amounts
> of broadcast/broad-multicast network background "chatter" seen on
> typical consumer and business networks?

You may want to check out TRex:  https://trex-tgn.cisco.com

It's free and uses the DPDK framework, so even a 5-year-old Xeon box should be 
able to saturate 10g (14Mpps) which is usually enough to make most small things 
fall over.

IIRC, it uses PCAP files as a template for traffic generation, and replaces the 
header info (src/dst) with values you configure.  So, if you have some captures 
with the background chatter you want, you can probably turn around and use 
those for testing.  The tool includes some console programs that show 
throughput, drops, etc.  You can scale the generation to any level you want (it 
just loops over the captures).  You can also turn on multiple generators (each 
with its own capture) to simulate a mix of traffic at different sizes and 
rates.  The distribution comes with several canned captures (imix, dns, large 
packets, small packets, etc).

The one thing I haven't tried with it is multicast, so that might need some 
extra work.  Maybe you can specify a multicast MAC at L2 for the generated 
packets (normally you set this to the MAC of the DUT)?

Jason

Re: TFTP over anycast

[Dan Sneddon]

On Feb 22, 2024, at 10:47, Javier Gutierrez  wrote:Hi, I'm working on some DR design and we want to not only have this site as a DR but also performing some active/active for some of the services we hosts and I was wondering if someone had some experience with using anycast for TFTP or DHCP services?What are some of the pains/challenges you experienced and things we should lookout for?Any input is greatly appreciated.Kind regards, Javier GutierrezI have extensive experience using IP Anycast for TFTP and DHCP, in the area of cloud computing. My primary job role is the development of system and network provisioning in cloud infrastructure, and I’ve spent much of the last twelve years working in this area. This is one area where protocols like BGP and techniques like Anycast have a different set of assumtions and reputations for reliability when considered within a provider's network or on the Internet at large. Usually IP Anycast for DHCP and TFTP is done in a controlled environment (within a network operated by a single entity) and not done at global scale over the public Internet.I have designed or contributed to the design of several IP Anycast DHCP/TFTP implementations for cloud computing infrastructure (OpenStack, OpenShift/Kubernetes), using Quagga, Bird, or FRR for OSPF/BGP and Pound/HAProxy/NGinx/MetalLB for load balancing, along with custom ruby/python for DHCP or dnsmasq and typically standard Linux TFTP servers (either on bare metal or inside VMs or containers).It becomes complicated when you want to perform DHCP and/or TFTP across sites or WAN links, and downright tricky when you want to do it across the Internet. The DHCP servers may be configured with pre-allocated host IP reservations if the clients are known ahead of time, or all servers may use a shared database (often distributed using MariaDB, InfoBlox, or similar) to ensure that each DHCP server agrees about which IPs are assigned and can sync IP reservations and releases. It is usually necessary to ensure that all TFTP servers are offering identical images via TFTP.Some platforms that I have used IP Anycast DHCP and TFTP servers with:OpenStack Nova (KVM/QEMU virtual machines): https://docs.openstack.org/nova/latest/OpenStack Ironic (bare metal): https://docs.openstack.org/ironic/latest/Metal3 (an offspring of Ironic that works in Kubernetes clusters: https://metal3.io/As the initial DHCP request is usually done via broadcast request, the network hardware close to the client is often configured as a DHCP relay with either multiple unicast IPs as relay targets or one or more Anycast IPs (this may depend on what a particular vendor supports on a given make/model of network switch or router). In other cases a DHCP unicast IP is hard-coded into a custom image in firmware or microimage, or cached in the case of a running client making a renewal or release.Most projects use a micro-image booted over TFTP to prepare a second-stage loader that uses a more reliable protocol such as HTTPS. When using DHCPv6 there are a lot of unique challenges, especially when multiple IPv6 addresses are assigned or the client is a piece of embedded hardware (such as a bare metal IPMI controller or a NIC running PXE/iPXE firmware).Usually this is all done in either ”private” IP address space (local-scope or RFC1918). Now as far as running these same protocols over the Internet at large, I can’t speak about any personal experience. It is theoretically possible but I don’t know of any large scale examples or experiments.The underpinnings for IP Anycast that I have used were initially based on Quagga: https://github.com/QuaggaMore recently I’ve been working on projects that use a fork of Quagga called FRR (Free Range Router): https://docs.frrouting.Generally the TFTP and DHCP servers are not directly using IP Anycast, rather there is a load balancer in front of the servers at each site. Initially I used Pound for this, but then NGinX and then HAProxy became preferable. More recently MetalLB on Kubernetes has been the go-to load-balancer, and MetalLB integrates with BGP in a number of ways.I helped design and bootstrap a project to use BGP for IP Anycast in order to provide load-balanced DHCP and TFTP in OpenStack and OpenShift using OVN, which is related to OpenFlow. Here is the BGP plugin for OVN: https://docs.openstack.org/ovn-bgp-agent/latestI would be very curious to see any projects which are attempting to do this on the public Internet. Would you mind sharing a bit about your intended use case?Warm regards,-Dan Sneddon