Dear Hank,
On Sat, Feb 20, 2021 at 07:37:08PM +0200, Hank Nussbacher wrote:
> Is there a place where one can examine RPKI invalid logs for a specific date
> & time
I have set up a publicly accessible archiver instance in Dallas, and one
in Amsterdam which capture and archive data every 20
On Tue, Feb 16, 2021 at 01:37:35PM -0600, John Kristoff wrote:
> I'd like to start a thread about the most famous and widespread Internet
> operational issues, outages or implementation incompatibilities you
> have seen.
>
> Which examples would make up your top three?
This was a fantastic
On Mon, Feb 08, 2021 at 04:02:14PM -0500, Justin Wilson (Lists) wrote:
> I enabled 134.195.47.1 on one of our routers.
Cool! I noticed the following: from many NLNOG RING nodes I can reach
that IP address, but not from 195.66.134.42:
deepmedia01.ring.nlnog.net:~$ mtr -z -w -r 134.195.47.1
Dear Justin,
On Mon, Feb 08, 2021 at 03:14:47PM -0500, Justin Wilson (Lists) wrote:
> It acts like the IP block was blacklisted at some point and got on
> some bad lists but I don’t want ti limit myself to that theory.
> I have opened up a ticket with ARIN asking for any guidance. Has
> anyone
Hi Sean, Will, group,
On Sun, Jan 17, 2021 at 03:01:22PM -0800, William Herrin wrote:
> On Sun, Jan 17, 2021 at 1:37 PM Sean Donelan wrote:
> > Some people think its funny to ghost subscribe email addresses, and
> > the NANOG mailing list auomation doesn't catch them in the verification
> >
Dear all,
On Mon, Jan 18, 2021 at 11:17:06AM -0700, Anne P. Mitchell, Esq. wrote:
> Either Alexandria Ocasio-Cortez' office is on the NANOG list or
> someone is forwarding NANOG email to AOC's press office (in which case
> either spoofed as the original sender or AOC's office sends an ack to
>
RENTSERIAL
NRTM Host: irr.lacnic.net
NRTM Port:43
When LACNIC enables NRTM in the coming days, other IRRs such as RADB and NTT
will begin mirroring the LACNIC source.
We would also like to thank the DashCare team (https://dashcare.nl/), Job
Snijders (NTT) and the RADB team for their support.
On Fri, Nov 20, 2020 at 12:02:04PM -0500, Tom Beecher wrote:
> In before snark of "OMG "http" links to RPKI info HURF BLURF!"
But Tom, that is exactly the whole point of the RPKI :-)
It's funny, but true! You really can safely use the RPKI data from the
console website in your own production
Dear all,
I'd like to introduce another tool to inspect RPKI data... the
rpki-client console! Comes with an authentic 90s look & feel :-)
The Frontpage - http://console.rpki-client.org/
---
On the front page you can see stdout + stderr of the most
Dear Pirawat,
On Mon, Oct 26, 2020 at 08:13:19PM +0700, Pirawat WATANAPONGSE wrote:
> I am seeking advice concerning someone else announcing IRR records on
> resources belonging to me.
Change is underway in the IRR ecosystem! The situation we are all used
to is that it is rather cumbersome to
On Mon, Nov 02, 2020 at 09:13:16AM +0100, Tim Bruijnzeels wrote:
> On the other hand, the fallback exposes a Malicious-in-the-Middle
> replay attack surface for 100% of the prefixes published using RRDP,
> 100% of the time. This allows attackers to prevent changes in ROAs to
> be seen.
This is a
On Fri, Oct 30, 2020 at 12:47:44PM +0100, Alex Band wrote:
> > On 30 Oct 2020, at 01:10, Randy Bush wrote:
> > i'll see your blog post and raise you a peer reviewed academic paper
> > and two rfcs :)
>
> For the readers wondering what is going on here: there is a reason
> there is only a vague
On Thu, Oct 29, 2020 at 09:14:16PM +0100, Alex Band wrote:
> In fact, we argue that it's actually a bad idea to do so:
>
> https://blog.nlnetlabs.nl/why-routinator-doesnt-fall-back-to-rsync/
>
> We're interested to hear views on this from both an operational and
> security perspective.
I don't
Hi all,
About eight months ago I discovered a number of issues in the validation
procedure of most RPKI validator softwares (including the RIPE NCC
Validator, Routinator, and OctoRPKI). The impact of improper
verification of Manifests (and associated aspects of the X.509 system)
in the RPKI can
Dear Kevin,
I am the maintainer of NLNOG's IRRexplorer and can help.
On Wed, Oct 07, 2020 at 08:37:00PM +, Kevin McCormick wrote:
> There seems to an issue with IRR Explorer.
>
> I check the following prefix and I get the message, “The server
> encountered an internal error and was unable to
On Fri, Oct 02, 2020 at 03:39:00AM -0700, Randy Bush wrote:
> > Marco Marzetti (PCCW) wrote an even faster compression tool!
> > https://github.com/lamehost/aggregate-prefixes
> >
> > Both these python implementations are meant as replacements for ISC's
> > vintage 'aggregate' Unix utility, with
On Thu, Oct 01, 2020 at 02:15:01PM -0300, Marcos Manoni wrote:
> Check https://github.com/job/aggregate6 (thank you, Job)
Marco Marzetti (PCCW) wrote an even faster compression tool!
https://github.com/lamehost/aggregate-prefixes
Both these python implementations are meant as replacements
Dear Łukasz, others,
Can you please send any suspecious emails (including headers) to
the mailing list admin team at ge...@nanog.org?
We'll try to figure out if it happens through an existing subscription.
Kind regards,
Job
(hat: NANOG geeks)
On Mon, Sep 21, 2020 at 12:51:44PM +0200, Octolus
On Tue, Sep 15, 2020 at 01:52:05PM -0700, Randy Bush wrote:
> perchance is RDAP implemented by all RIRs?
Yes, but in 5 slightly different ways :-)
Kind regards,
Job
I believe from this moment forward things are converging back to normal.
Kind regards,
Job
On Tue, Aug 25, 2020 at 08:27:24AM -0400, K. Scott Helms wrote:
> Comcast is blocking it. From the table on that page.
>
> "Port 0 is a reserved port, which means it should not be used by
> applications. Network abuse has prompted the need to block this port."
The 'Transport' column seems to
On Tue, Aug 25, 2020 at 07:27:33AM -0400, K. Scott Helms wrote:
> I think a fairly easy thing to do is see what other large retail ISPs
> have done. Comcast, as an example, lists all of the ports they block
> and 0 is blocked. I do recommend that port 0 be blocked by all of the
> ISPs I work
On Mon, Aug 03, 2020 at 08:17:55AM -0500, John Kristoff wrote:
> On Sun, 2 Aug 2020 18:52:11 +
> Randy Bush wrote:
>
> > not to mention the ARIN stupidity
>
> Notwithstanding the RPA, downloading ARIN's TAL is straightforward:
>
> As documented here:
>
>
Dear Ryan,
I have come to believe this is a Noction IRP specific issue.
On Sat, Aug 01, 2020 at 01:29:59PM -0700, Ryan Hamel wrote:
> I disagree on the fact that it is not fair to the BGP implementation
> ecosystem, to enforce a single piece of software to activate the
> no-export community by
On Mon, Aug 03, 2020 at 02:36:25PM +0200, Alex Band wrote:
> According to the information I received from the community[1], you
> should read PR1461602 and PR1309944 before deploying.
>
> [1] https://rpki.readthedocs.io/en/latest/rpki/router-support.html
My take on PR1461602 is that it can be
On Sat, Aug 01, 2020 at 06:50:55AM -0700, Ca By wrote:
> I am not normally supporting a heavy hand in regulation, but i think it is
> fair to say Noction and similar BGP optimizers are unsafe at any speed and
> the FTC or similar should ban them in the USA. They harm consumers and are
> a risk to
On Fri, Jul 31, 2020 at 03:34:47PM +0200, Mark Tinka wrote:
> On 31/Jul/20 03:57, Aftab Siddiqui wrote:
> > Not a single prefix was signed, what I saw. May be good reason for
> > Rogers, Charter, TWC etc to do that now. It would have stopped the
> > propagation at Telia.
>
> If none of the
On Thu, Jul 30, 2020 at 07:09:07PM +0200, Patrick Schultz wrote:
> so, bgp optimizers... again?
We should stop calling them 'optimizers'... perhaps "BGP Polluters"?
Kind regards,
Job
Dear Jon, group,
On Wed, Jun 17, 2020 at 10:25:14AM -0400, Jon Lewis wrote:
> On Mon, 15 Jun 2020, Mike Leber via NANOG wrote:
>
> > I'm pleased to announce Hurricane Electric has completed our RPKI
> > INVALID filtering project and we now have 0 RPKI INVALIDs in our routing
> > table.
> >
> >
Dear all,
> I noticed that Mikrotik has added RPKI into their very much beta v7
> branch. I would like to ask those of you that know RPKI well to check
> it out and offer Mikrotik feedback on what they've done
> right\wrong\broken.
Our hero Massimiliano Stucchi in Switzerland started doing the
Dear Baldur,
On Wed, Jun 17, 2020 at 01:42:36PM +0200, Baldur Norddahl wrote:
> Lets say someone makes an announcement that creates a RPKI invalid and
> it is determined to be a mistake. They then go back and add ROA
> objects to fix the problem. With this reactive RPKI approach then
> continue
Dear Mike, Ytti, others,
First of all and most importantly: congratulations Mike! I thank you and
your team for having constructed a great mechanism that helps honor the
routing intentions everyone publishes in the RPKI.
On Tue, Jun 16, 2020 at 09:08:41AM +0300, Saku Ytti wrote:
> On Tue, 16 Jun
Dear colleagues,
On Tue, Jun 9, 2020, at 08:04, Mark Tinka wrote:
> On 5/Jun/20 18:49, Saku Ytti wrote:
> > The comparison isn't between full or default, the comparison is
> > between static default or dynamic default. Of course with any default
> > scenario there are more failure modes you cannot route around.
Dear John, group,
On Wed, Jun 10, 2020 at 06:51:53PM +, John Curran wrote:
> ARIN has released its updated IRR system - if you are relying on
> ARIN’s IRR data, please refer to details below and update access
> methods accordingly.
Ack - NTT has done so.
The 'rr.ntt.net' instance now
On Mon, Apr 20, 2020, at 21:54, Amir Herzberg wrote:
> Randy said, > From a practical standpoint, this doesn't actually tell
> the whole truth
> >
> > indeed. route origin validation, while a good thing, does not make
> > bgp safe from attack. this marketing fantasy is being propagated;
> > but
Dear Mark, group,
On Tue, Mar 31, 2020 at 03:50:23PM +0200, Mark Tinka wrote:
> On 31/Mar/20 15:21, Dorian Kim wrote:
> > Unfortunately we don’t have any testing done or experience with RPKI
> > on XE or Classic boxes as we don’t have any deployed outside of OOB
> > infrastructure.
>
> Cherish
Dear group,
Exciting news! Today NTT's Global IP Network (AS 2914) enabled RPKI
based BGP Origin Validation on virtually all EBGP sessions, both
customer and peering edge. This change positively impacts the Internet
routing system.
The use of RPKI technology is a critical component in our
On Fri, Mar 20, 2020 at 05:57:19PM -0400, Jared Mauch wrote:
> You also need to watch out to ensure you’re not on some L2VPN type
> product that bumps up against a barrier. I know it’s a stressful time
> for many networks and systems people as traffic shifts.
A few years ago we did a
On Fri, Mar 20, 2020 at 05:33:31PM -0400, Nimrod Levy wrote:
> With the increase in remote workers and VPN traffic that won't hash across
> multiple paths, I thought this anecdote might help someone else track down
> a problem that might not be so obvious.
Do we know which specific VPN
I can help! Will follow-up off list.
For future reference: db-ad...@rr.ntt.net is also a good place to direct any
questions about NTT's IRR service "NTTCOM"
Kind regards,
Job
On Tue, Mar 17, 2020, at 20:54, Sadiq Saif wrote:
> Hi all,
>
> I am looking for help with removal of a
On Tue, Mar 17, 2020, at 19:38, Dan White wrote:
> By "ahead of us", I'm hoping to glean some operational experience from
> European, or networks in larger cities with a more impactful lock
> down.
It is all fairly new here too. Some of the things that have come to mind so far:
- the supply
On Tue, Mar 03, 2020 at 11:22:35AM -0700, Clinton Work wrote:
> It looks like the former Allstream RADB account (MAINT-AS15290) and
> all associated route objects were removed from RADB today. The
> deletion mainly impacts Canadian route objects registered by the
> former Allstream (now Zayo).
> Any word on what the update was for? It caused quite a jump in traffic on our
> network.
On twitter "68 GB" was trending
https://twitter.com/search?q=%2268%20GB%22=trend_click
Kind regards,
Job
Oops, I see a fat typo slipped in - the correct URL is
https://github.com/job/rpki-ov-checker :-)
Kind regards,
Job
On Thu, Feb 6, 2020 at 20:35 Job Snijders wrote:
> Dear ops,
>
> I wrote a simple tool to figure out what kind of invalid a rpki invalid
> is, this ca
Dear ops,
I wrote a simple tool to figure out what kind of invalid a rpki invalid
is, this can aid people in understanding the impact of "invalid ==
reject" routing policies. Only "invalid_unreachable" routes present
an operational issue in my opinion, IP addresses covered by "notfound"
or
Dear Paul,
I recommend subscribing and reaching out to the “mailop” mailing list. You
may not see replies from the big mail operators in the archives, but I
suspect a lot of relevant people pay attention to this specific list.
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Kind
Hi!
This came up on our radar somewhere in the last 24 hours too. It indeed
does look very curious. Thank you for your analysis and report.
NTT is taking steps to figure out what is behind this. Our current
working theories are that perhaps the IRR maintainer account was
compromised, or some
Dear Brian,
On Fri, 24 Jan 2020 at 17:40, Brian wrote:
> Hello all. I am having a hard time trying to articulate why a Dual Home
> ISP should have full tables. My understanding has always been that full
> tables when dual homed allow much more control. Especially in helping to
> prevent Async
On Tue, Dec 31, 2019 at 17:26 Seth Mattinen wrote:
> On 12/31/19 8:10 AM, joel jaeggli wrote:
> > Argumentation on the basis of a tu quoque fallacy doesn't really add
> > much to the dicussion. Depreciating potentialy dangerous and definitely
> > obsolete protocols does not make you a hypocrite.
Dear all,
On Fri, Dec 27, 2019 at 04:06:24PM -0500, Christopher Morrow wrote:
> If there are AS46844 folk listening around their eggnog ... it'd be
> nice if you would stop leaking prefixes: https://imgur.com/a/Js0YvP2
>
> this from the current view at: https://bgp.he.net/AS15169#_graph6
>
> I
Dear Arturo, group,
On Tue, Dec 10, 2019 at 20:51 Arturo Servin wrote:
>
> Invalid according to RPKI or IRR? Or both?
>
In this context the use of the word “invalid” refers to the result of
validation procedure described in RFC 6811 - which is to match received BGP
updates to the RPKI and
Hi all,
We are following up off-list!
This may be a good moment to mention that the excellent people at the NTT
NOC are always available at n...@ntt.net, or the phone numbers listed in
PeeringDB. :-)
Kind regards,
Job
On Tue, Dec 3, 2019 at 23:19 Ben Cannon wrote:
> We’re trying to figure
Dear fellow network operators,
It appears Santa brought presents early this year! I'd like to draw
attention to the below forwarded message and provide my take on it.
Some of you represent organisations that interact with multiple RIRs,
and have concluded it can be challenging to figure out the
Dear Douglas,
Thanks for sharing the link. This is an impressive effort!
Can you share with the group what the best way is to share feedback to
effect changes in the document?
Is there a difference between just emailing you or are there official
channels to be considered?
Kind regards,
Job
Dear Stephen,
I’ll work with you off-list to investigate! :-)
Kind regards,
Job
NTT / AS 2914
On Wed, Oct 23, 2019 at 14:23 Ross Tajvar wrote:
> What was the source/destination?
>
> On Wed, Oct 23, 2019, 2:10 PM Stephen Satchell wrote:
>
>> Routing loop
>>
>> > 11.|-- 129.250.24.196
It appears in your thought experiment, a stick is dressed up like a carrot.
I’m not a fan of deploying purely punitive strategies to promote adoption;
technologies should stand on their own and be able to convince the
potential users based on their merit, not based on penalties.
It would be good to see some receipts, offered by the selling party.
Hi Ryan, Alarig,
> On 14/08/2019 19:06, Ryan Hamel wrote:
> > I appreciate the effort and the intent behind this project, but why
> > should the community contribute to an open source project on GitHub
> > that is mainly powered by a closed source binary?
>
On Wed, Aug 14, 2019 at 07:13:47PM
Dear NANOG,
Recently NTT investigated how to best monitor the visibility of our own and
our subsidiaries’ IP resources in the BGP Default-Free Zone. We were
specifically looking how to get near real-time alerts funneled into an
actionable pipeline for our NOC & Operations department when BGP
Dear all,
On Wed, Aug 14, 2019 at 10:36:44AM +, John Curran wrote:
> On 14 Aug 2019, at 2:26 AM, Matthew Petach wrote:
> > ...
> > Now, at the risk of bringing down the ire of the community on my
> > head...ARIN could consider tying the elements together, at least for
> > ARIN members. Add
On Fri, Jul 19, 2019 at 3:16 AM Adam Korab wrote:
>
> On 07/18/2019 at 23:08, Job Snijders wrote:
> > A potential upside is that hamnet operators maybe have access to some RPKI
> > services now!
>
> OK, I'll bitehow do you mean?
Ah, let me clarify, I didn't mean t
A potential upside is that hamnet operators maybe have access to some RPKI
services now!
On Tue, Jul 16, 2019 at 01:24:11PM -0500, Mike Hammett wrote:
> All of the same tragedy can happen without BGP optimizers, and does.
I disagree. You are skipping over crucial distinction we should make
between common 'route leaks' (incorrect propagation of valid routing
information), and the
On Tue, Jul 16, 2019 at 6:10 PM Ryan Hamel wrote:
>
> Nowhere near the number as an engineer fat fingering a route.
How are you able to make that assertion?
> There are ISPs that accept routes all the way to /32 or /128, for traffic
> engineering with ease, and/or RTBH.
This strikes me as a
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.
I will ping you off list with contact details.
Kind regards,
Job
On Mon, Jul 8, 2019 at 6:20 PM Joe Nelson wrote:
>
> Does anyone know who to contact to have old information removed from
> Level3/CenturyLink's IRR. My ASN still shows in their registry with stale
> information from an old
> Anyway, you can now enjoy https://rpki.net/s/rpki-test even more! :-)
my apologies, I fumbled the ball on typing in that URL, I intended to
point here: https://www.ripe.net/s/rpki-test
On Thu, Jul 4, 2019 at 8:46 PM Francois Lecavalier
wrote:
> It's been close to 3 hours now since I dropped them - radio silence.
I am going to assume that "radio silence" for you means that your
network is fully functional and none of your customers have raised
issues! :-)
> Whoever fears
Dear Francois,
On Thu, Jul 04, 2019 at 03:22:23PM +, Francois Lecavalier wrote:
> Following that Verizon debacle I got onboard with ROV, after a couple
> research I stopped my choice on the drum roll CloudFlare GoRTR
> (https://github.com/cloudflare/gortr). If you trust them enough
Dear Stephen,
On Tue, Jun 25, 2019 at 07:04:12AM -0700, Stephen Satchell wrote:
> On 6/25/19 2:25 AM, Katie Holly wrote:
> > Disclaimer: As much as I dislike Cloudflare (I used to complain
> > about them a lot on Twitter), this is something I am absolutely
> > agreeing with them. Verizon failed
On Mon, Jun 24, 2019 at 08:18:27AM -0400, Tom Paseka via NANOG wrote:
> a Verizon downstream BGP customer is leaking the full table, and some more
> specific from us and many other providers.
It appears that one of the implicated ASNs, AS 33154 "DQE Communications
LLC" is listed as customer on
On Thu, Jun 20, 2019 at 4:21 PM Steller, Anthony J
wrote:
> because it really don’t matter in the whole scheme of things.
Indeed, it doesn't matter. The "traffic ratio" field in PeeringDB
probably should be deprecated, there is no formal definition nor is
are there any operational consequences
Dear Matt,
See this URL instead:
https://github.com/jda/maintnote-std/blob/master/standard.md
NTT / AS 2914’s NOC follows this process to keep customers and partners
informed about maintenances.
Kind regards,
Job
On Mon, Jun 17, 2019 at 15:32 Matt Harris wrote:
> On Mon, Jun 17, 2019 at
On Sat, Jun 15, 2019 at 4:45 PM Owen DeLong wrote:
> > On Jun 15, 2019, at 5:43 AM, Job Snijders wrote:
> >> On Sat, Jun 15, 2019 at 2:38 PM Owen DeLong wrote:
> >
owen> >> What I heard you say is: “I’m not going to offer a solution
to your problem, but you
On Sat, Jun 15, 2019 at 09:31:03AM -0400, Jon Lewis wrote:
> On Sat, 15 Jun 2019, Job Snijders wrote:
> > There is no signal from the remote ASN (the one that receive the
> > route announcement) to the Originator ASN about the remote ASN's
> > loop detection policies. Ther
On Sat, Jun 15, 2019 at 05:32:21AM -0700, Owen DeLong wrote:
> > What is the principal harm of doing this? Honest question. I'm not
> > advocating for anything, just curious.
> >
> > Excellent question.
> >
> > 1/ We can’t really expect on the loop detection to work that way at
> > the “jacked”
On Sat, Jun 15, 2019 at 2:38 PM Owen DeLong wrote:
> Job,
>
> Permit me to apply some reflective listening to your statement:
>
> What I heard you say is: “I’m not going to offer a solution to your problem,
> but you shouldn’t use the one you have that currently works because some
> things my
On Thu, Jun 13, 2019 at 11:18 Warren Kumari wrote:
> On Thu, Jun 13, 2019 at 9:59 AM Joe Abley wrote:
> >
> > Hey Joe,
> >
> > On 12 Jun 2019, at 12:37, Joe Provo wrote:
> >
> > > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote:
> > >> Send abuse complaint to the upstreams
Hi Joe,
On Thu, Jun 13, 2019 at 9:59 Joe Abley wrote:
> Hey Joe,
>
> On 12 Jun 2019, at 12:37, Joe Provo wrote:
>
> > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote:
> >> Send abuse complaint to the upstreams
> >
> > ...and then name & shame publicly. AS-path forgery "for
Indeed, I do not see this in the our current version of the
Default-Free Zone, so there may not be a problem for us to solve at
this moment.
I think your reaching out to NANOG or other operator forums is the
correct action. Someone is bound to know someone who knows someone who
can help.
Kind
Can you share more details? Perhaps we can put the human social network to
good use.
Other than that this is annoying - are right now operationally impacted?
Kind regards,
Job
On Wed, Jun 12, 2019 at 12:24 Filip Hruska wrote:
> I would contact upstreams of the upstream then. This is quite a
Dear Eric,
If you don't mind me showering you with some study resources... here we
go!
On Fri, Jun 07, 2019 at 10:58:48AM -0400, Eric Dugas wrote:
> I was wondering if there was a list of networks that enforce RPKI
> validation and dropping invalids.
The last list that was compiled is available
On Wed, May 15, 2019 at 11:52:16AM +, Mann, Jason via NANOG wrote:
> ?Is BGPmon going away?
Yes, see
https://bgpmon.net/wp-content/uploads/2019/01/BGPMon.net-EOL-EOS-faq.pdf
Kind regards,
Job
On Wed, May 15, 2019 at 11:37:57AM +0100, Carlos Friaças wrote:
> It relies *exclusively* on "RIPE RIS Live", or does it also use other
> sources?
The first useful version will rely exclusively on the "RIS Live"
interface. In a later stage we can consider adding something like the
NLNOG Looking
Hi,
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
Dear Jared,
This was a very interesting read. Thank you for sharing it with us. The
paper contained new information for me, if I hope I summarize it correctly:
by combining AS_PATH poisoning and botnets, the botnet’s firing power can
be more precisely aimed at a specific target.
Can you clarify
Dear Nick,
I sympathize with you plight, network debugging can be quite a test of
character at times.
I am snipping some text as I can't comment on on specific details in
this case, but you do raise two excellent questions which I can maybe
help with.
On Thu, May 09, 2019 at 03:05:43PM +,
Hi Chuck,
On Thu, May 09, 2019 at 06:34:21AM -0400, Chuck Church wrote:
> Are you sure the problem isn’t NTT? My buddy’s WISP peers with Spirit
> and had a boatload of problems with random packet loss affecting
> initially just SIP and RTP (both UDP). Spirit was blaming NTT.
> Problems went away
Dear Lars,
On Wed, May 08, 2019 at 09:56:33AM +0200, Lars Prehn wrote:
> do you NTP sync your AS boundary routers?
yes
> If so, what are incentives for doing so? Are there incentives, e.g.
> security considerations, not to do it?
The major advantage of NTP syncing your routers is that it
Dear Mehmet,
On Wed, May 01, 2019 at 03:22:57PM -0400, Mehmet Akcin wrote:
> I am trying to buy a GPS based NTP server like this one
>
> https://timemachinescorp.com/product/gps-time-server-tm1000a/
>
> but I will be placing this inside a data center, do these need an
> actual view of a sky to
Dear Anne,
On Wed, Apr 24, 2019 at 11:07:51PM -0600, Anne P. Mitchell, Esq. wrote:
> How can this not be a violation of the ToS of just about every major
> provider?
Can you perhaps cite ToS excerpts from one or more major providers to
support your assertion?
> Anne P. Mitchell,
> Attorney
Hi all,
On Wed, Apr 03, 2019 at 10:59:18AM -0400, Jay Borkenhagen wrote:
> I urge folks facing similar problems to publish RPKI ROAs for their IP
> resources. [snip] the verifiable statements in RPKI ROAs can be
> attributed to you as the actual resource holder, thus helping folks
> base their
Ack for NTT
On Mon, Apr 1, 2019 at 21:36 Christopher Morrow
wrote:
> (from offline chat and pokery)
>
> It looks like 701/1239/3356 are permitting 4837 to announce this prefix
> because:
> $ whois -h whois.radb.net 192.139.135.0
> route: 192.139.135.0/24
> descr: managedway company
>
A careful observer will note multiple fractures/rifts in the ipv6
default-free zone. It’s not as meshed as ipv4, unfortunately.
Kind regards,
Job
On Wed, Mar 27, 2019 at 09:36:20PM +, Graham Johnston wrote:
> This afternoon at around 12:17 central time today we began learning
> the subnet for the Equinix IX in Chicago via a transit provider; we
> are on the IX as well. The subnet in question is 208.115.136.0/23.
> Using stat.ripe.net I
On Thu, Mar 28, 2019 at 02:59:43PM +0100, Niels Bakker wrote:
> * christopher.morrell.na...@gmail.com (Christopher Morrell) [Thu 28 Mar 2019,
> 14:35 CET]:
> > I've been bit by this in the past at two different exchanges. I too
> > have a policy applied to deny IXP LANs from upstreams and peers.
On Thu, Mar 21, 2019 at 06:59:18PM +0300, Frank Habicht wrote:
> On 20/03/2019 21:05, James Shank wrote:
> > I'm not clear on the use cases, though. What are the imagined use cases?
> >
> > It might make sense to solve 'a method to request hot potato routing'
> > as a separate problem. (Along
Hi,
On Thu, Mar 14, 2019 at 02:04:39PM +, Jeroen Wunnink wrote:
> The route-leak was something different that seems to have mainly hit
> west-Europe between 16:52 UTC to 17:08 UTC. There’s a few people in
> the *NOG communities still digging at the complete details of that
> right now, but it
On Wed, Mar 6, 2019 at 8:32 Smith, Courtney
wrote:
> On 3/5/19, 6:04 PM, "NANOG on behalf of Job Snijders"
> j...@instituut.net> wrote:
>
> On Sun, Mar 03, 2019 at 08:42:02PM -0500, Joshua Miller wrote:
> > A while back I read somewhere that tra
1 - 100 of 417 matches
Mail list logo
