Re: Help with removing DNS shinkhole FP from Charter/Spectrum

I'm not sure where you saw that message, but I got this message via email after I submitted an unblock request with Spectrum Shield: We have reviewed your request to unblock validin.com. This site was not found to be blocked by Spectrum Shield and should be accessible from your browser.

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

Bill is absolutely correct. The spammers lost their case because they were demonstrably spammers. No, really they did not. I read the decisions. Have you? Hint: under CAN SPAM a great deal of spam is completely legal so it didn't matter. We’ve had accidental black hole cases with *US*

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

On Mon, Apr 22, 2024 at 5:54 PM Validin Axon wrote: > Hi Bill, > > I'm not sure where you saw that message, but I got this > message via email after I submitted an unblock request with Spectrum Shield: Howdy, That was Christopher, not me. But you should check the talos link I sent you

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

Hi Bill, I'm not sure where you saw that message, but I got this message via email after I submitted an unblock request with Spectrum Shield: > We have reviewed your request to unblock validin.com. This site was not found to be blocked by Spectrum Shield and should be accessible from your

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

Bill is absolutely correct. The spammers lost their case because they were demonstrably spammers. We’ve had accidental black hole cases with *US* providers that removed the block once they received a C If they don’t have iron clad proof in hand. (More than just a few complaints and no traffic

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

On Mon, Apr 22, 2024 at 5:07 PM John R. Levine wrote: > a complaint would have to show that the > blocking was malicious rather than merited or accidental. In this case it > seems probably accidental, but for all I know there might have been bad > traffic to merit a block. Hi John, I'll try

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

On Mon, 22 Apr 2024, William Herrin wrote: Respectfully, you're mistaken. Look up "tortious interference." I'm familiar with it. But I am also familar with many cases were spammers have sued network operators claiming that they're falsely defamed, so the operator has to deliver their mail.

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

“We checked the website you are trying to access for malicious and spear-phishing content and found it likely to be unsafe.” perhaps charter thinks there's a reason to not permit folks to access a possibly dangerous site? (it's also possible it just got cough up amongst some other stuff in the

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

On Mon, Apr 22, 2024 at 4:00 PM John Levine wrote: > It appears that William Herrin said: > >If you can't reach a technical POC, use the legal one. Your lawyer can > The only response to a letter like that is "we run our network to > serve our customers and manage it the way we think is best"

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

It appears that William Herrin said: >On Sun, Apr 21, 2024 at 6:21 PM Validin Axon wrote: >> Looking for some help/advice. Spectrum is sinkholing my company's domain, >> validin[.]com, to 127.0.0.54. > >Howdy, > >If you can't reach a technical POC, use the legal one. Your lawyer can >find the

Re: Question about mutual transit and complex BGP peering

On Mon, Apr 22, 2024 at 7:35 AM Sriram, Kotikalapudi (Fed) via NANOG < nanog@nanog.org> wrote: > Requesting responses to the following questions. Would be helpful in some > IETF work in progress. > > Q1: Consider an AS peering relationship that is complex (or hybrid) > meaning, for example,

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

Hi Mel, I appreciate the suggestion. During my earlier research, I'd noticed that as well. However, the DNS block includes all validin.com subdomains, covering those on completely different ASNs. It also does NOT affect other domains that resolve to the exact same IP addresses (e.g.,

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

I notice from MXToolbox.com that your domain’s IP address is on the UCEPROTECTL3 blacklist. This is a notoriously evil blacklist that charges people for removal. This may be why Spectrum is blackholing your domain. Most respectable ISPs won’t use it. But Spectrum… There is no delisting

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

On Sun, Apr 21, 2024 at 6:21 PM Validin Axon wrote: > Looking for some help/advice. Spectrum is sinkholing my company's domain, > validin[.]com, to 127.0.0.54. Howdy, If you can't reach a technical POC, use the legal one. Your lawyer can find the appropriate recipient and write a

Re: constant FEC errors juniper mpc10e 400g

On 4/22/24 09:47, Vasilenko Eduard via NANOG wrote: Assume that some carrier has 10k FBB subscribers in a particular municipality (without any hope of considerably increasing this number). 2Mbps is the current average per household in the busy hour, pretty uniform worldwide. You could

RE: constant FEC errors juniper mpc10e 400g

ers are connected to the Internet at a fast rate. Ed/ -Original Message- From: NANOG On Behalf Of Tarko Tikan Sent: Saturday, April 20, 2024 19:19 To: nanog@nanog.org Subject: Re: constant FEC errors juniper mpc10e 400g hey, > That said, I don't expect any subsea cables getting

Re: constant FEC errors juniper mpc10e 400g

On 4/21/24 08:12, Saku Ytti wrote: Key difference being, WAN-PHY does not provide synchronous timing, so it's not SDH/SONET compatible for strict definition for it, but it does have the frame format. And the optical systems which could regenerate SONET/SDH framing, didn't care about timing,

Re: constant FEC errors juniper mpc10e 400g

On Sun, 21 Apr 2024 at 09:05, Mark Tinka wrote: > Technically, what you are describing is EoS (Ethernet over SONET, Ethernet > over SDH), which is not the same as WAN-PHY (although the working groups that > developed these nearly confused each other in the process, ANSI/ITU for the > former

Re: constant FEC errors juniper mpc10e 400g

On 4/20/24 21:36, b...@uu3.net wrote: Erm, WAN-PHY did not extend into 40G because there was not much of those STM-256 deployment? (or customers didnt wanted to pay for those). With SONET/SDH, as the traffic rate increased, so did the number of overhead bytes. With every iteration of the

Re: constant FEC errors juniper mpc10e 400g

-PHY anymore. -- Original message -- From: Mark Tinka To: Dave Cohen Cc: nanog@nanog.org Subject: Re: constant FEC errors juniper mpc10e 400g Date: Sat, 20 Apr 2024 17:50:04 +0200 WAN-PHY did not extend to 40G or 100G, which can explain one of the reasons it lost favour. For 10G

Re: constant FEC errors juniper mpc10e 400g

On 4/20/24 18:19, Tarko Tikan wrote: 10G wavelengths for new builds died about 10 years ago when coherent 100G became available, submarine or not. Putting 10G into same system is not really feasible at all. I was referring to 10G services (client-side), not 10G wavelengths (line side).

Re: constant FEC errors juniper mpc10e 400g

hey, That said, I don't expect any subsea cables getting built in the next 3 years and later will have 10G as a product on the SLTE itself... it wouldn't be worth the spectrum. 10G wavelengths for new builds died about 10 years ago when coherent 100G became available, submarine or not.

Re: constant FEC errors juniper mpc10e 400g

On 4/20/24 14:41, Dave Cohen wrote: LAN PHY dominates in the US too. Requests for WAN PHY were almost exclusively for terrestrial backhaul extending off of legacy subsea systems that still commonly had TDM-framed services. It’s been a couple of years since I’ve been in optical transport

Re: constant FEC errors juniper mpc10e 400g

LAN PHY dominates in the US too. Requests for WAN PHY were almost exclusively for terrestrial backhaul extending off of legacy subsea systems that still commonly had TDM-framed services. It’s been a couple of years since I’ve been in optical transport directly but these requests were

Re: constant FEC errors juniper mpc10e 400g

On 4/20/24 13:39, Saku Ytti wrote: Oh I don't think OTN or WAN-PHY have any large deployment future, the cheapest option is 'good enough'... And what we find with EU providers is that Ethernet and OTN services are priced similarly. It's a software toggle on a transponder, but even then,

Re: constant FEC errors juniper mpc10e 400g

On 4/20/24 13:39, Saku Ytti wrote: Oh I don't think OTN or WAN-PHY have any large deployment future, the cheapest option is 'good enough' and whatever value you could extract from OTN or WAN-PHY, will be difficult to capitalise, people usually don't even capitalise the capabilities they

Re: constant FEC errors juniper mpc10e 400g

On Sat, 20 Apr 2024 at 14:35, Mark Tinka wrote: > Even when our market seeks OTN from European backhaul providers to extend > submarine access into Europe and Asia-Pac, it is often for structured > capacity grooming, and not for OAM benefit. > > It would be interesting to learn whether other

Re: constant FEC errors juniper mpc10e 400g

On 4/20/24 13:25, Saku Ytti wrote: In most cases, modern optical long haul has a transponder, which terminates your FEC, because clients offer gray, and you like something a bit less depressing, like 1570.42nm. This is not just FEC terminating, but also to a degree autonego terminating, like

Re: constant FEC errors juniper mpc10e 400g

On Sat, 20 Apr 2024 at 10:00, Mark Tinka wrote: > This would only matter on ultra long haul optical spans where the signal > would need to be regenerated, where - among many other values - FEC would > need to be decoded, corrected and re-applied. In most cases, modern optical long

Re: constant FEC errors juniper mpc10e 400g

, corrected and re-applied. SD-FEC already allows for a significant improvement in optical reach for a given modulation. This negates the need for early regeneration, assuming other optical penalties and impairments are satisfactorily compensated for. Of course, what a market defines as long

Re: constant FEC errors juniper mpc10e 400g

, corrected and re-applied. SD-FEC already allows for a significant improvement in optical reach for a given modulation. This negates the need for early regeneration, assuming other optical penalties and impairments are satisfactorily compensated for. Of course, what a market defines as long

Re: Whitebox Routers Beyond the Datasheet

Fri, Apr 12, 2024 at 08:03:49AM -0500, Mike Hammett: > I'm looking at the suitability of whitebox routers for high through, low port > count, fast BGP performance applications. Power efficiency is important as > well. > > > What I've kind of come down to (based on little more than spec

Re: constant FEC errors juniper mpc10e 400g

On Fri, 19 Apr 2024 at 10:55, Mark Tinka wrote:> FEC is amazing. > At higher data rates (100G and 400G) for long and ultra long haul optical > networks, SD-FEC (Soft Decision FEC) carries a higher overhead penalty > compared to HD-FEC (Hard Decision FEC), but the net OSNR gain more than >

Re: constant FEC errors juniper mpc10e 400g

On 4/19/24 08:01, Saku Ytti wrote: The frames in FEC are idle frames between actual ethernet frames. So you recall right, without FEC, you won't see this idle traffic. It's very very good, because now you actually know before putting the circuit in production, if the circuit works or not.

Re: constant FEC errors juniper mpc10e 400g

On Thu, 18 Apr 2024 at 21:49, Aaron Gould wrote: > Thanks. What "all the ethernet control frame juju" might you be referring > to? I don't recall Ethernet, in and of itself, just sending stuff back and > forth. Does anyone know if this FEC stuff I see concurring is actually > contained in

Re: constant FEC errors juniper mpc10e 400g

I'm being sloppy with my verbiage, it's just been a long time since I thought about this in detail, sorry. The MAC layer hands bits to the Media Independent Interface, which connects the MAC to the PHY. The PHY converts the digital 1/0 into the form required by the media transmission type; the

Re: constant FEC errors juniper mpc10e 400g

On 4/18/24 11:45, Aaron Gould wrote: Thanks.  What "all the ethernet control frame juju" might you be referring to?  I don't recall Ethernet, in and of itself, just sending stuff back and forth.  Does anyone know if this FEC stuff I see concurring is actually contained in Ethernet Frames? 

Re: constant FEC errors juniper mpc10e 400g

> What "all the ethernet control frame juju" might you be referring > to?  I don't recall Ethernet, in and of itself, just sending stuff back and > forth. I did not read the 100G Ethernet specs, but as far as I remember FastEthernet (e.g. 100BASE-FX) uses 4B/5B coding on the line, borrowed from

Re: constant FEC errors juniper mpc10e 400g

Thanks.  What "all the ethernet control frame juju" might you be referring to?  I don't recall Ethernet, in and of itself, just sending stuff back and forth.  Does anyone know if this FEC stuff I see concurring is actually contained in Ethernet Frames?  If so, please send a link to show the

Re: constant FEC errors juniper mpc10e 400g

FEC is occurring at the PHY , below the PCS. Even if you're not sending any traffic, all the ethernet control frame juju is still going back and forth, which FEC may have to correct. I *think* (but not 100% sure) that for anything that by spec requires FEC, there is a default RS-FEC type that

Re: constant FEC errors juniper mpc10e 400g

Not to belabor this, but so interesting... I need a FEC-for-Dummies or FEC-for-IP/Ethernet-Engineers... Shown below, my 400g interface with NO config at all... Interface has no traffic at all, no packets at all BUT, lots of FEC hits. Interesting this FEC-thing. I'd love to have a fiber

Re: constant FEC errors juniper mpc10e 400g

On 4/18/24 15:45, Tom Beecher wrote:  Just for extra clarity off those KB, probably has nothing to do with vendor interop as implied in at least one of those. Yes, correct. Mark.

Re: constant FEC errors juniper mpc10e 400g

> > We've seen the same between Juniper and Arista boxes in the same rack > running at 100G, despite cleaning fibres, swapping optics, moving ports, > moving line cards, e.t.c. TAC said it's a non-issue, and to be expected, > and shared the same KB's. > > Just for extra clarity off those KB,

Re: constant FEC errors juniper mpc10e 400g

Standard deviation is now your friend. Learned to alert on outside of SD FEC and CRCs. Although the second should already be alerting. On Thu, Apr 18, 2024 at 8:15 AM Mark Tinka wrote: > On 4/17/24 23: 24, Aaron Gould wrote: > Well JTAC just said that it seems > ok, and that 400g is going to

Re: constant FEC errors juniper mpc10e 400g

0 Max nh cache: 75000, New hold nh limit: 75000, Curr nh cnt: 1, Curr new hold cnt: 0, NH drop cnt: 0 Flags: Sendbcast-pkt-to-re Addresses, Flags: Is-Preferred Is-Primary Destination:10.10.10.76/30 <http://10.10.10.7

Re: constant FEC errors juniper mpc10e 400g

On 4/17/24 23:24, Aaron Gould wrote: Well JTAC just said that it seems ok, and that 400g is going to show 4x more than 100g "This is due to having to synchronize much more to support higher data." We've seen the same between Juniper and Arista boxes in the same rack running at 100G,

Re: constant FEC errors juniper mpc10e 400g

Link Degrade : > Link Monitoring : Disable > Interface transmit statistics: Disabled > > Logical interface et-7/1/4.0 (Index 420) (SNMP ifIndex 815) > Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2 > Input packets : 1 > Output packets: 1 > Protocol inet, MTU: 1500 > Max nh cache: 75000, New hold nh limit: 75000, Curr nh cnt: 1, Curr new > hold cnt: 0, NH drop cnt: 0 > Flags: Sendbcast-pkt-to-re > Addresses, Flags: Is-Preferred Is-Primary > Destination: 10.10.10.76/30, Local: 10.10.10.77, Broadcast: > 10.10.10.79 > > -- > -Aaron

Re: constant FEC errors juniper mpc10e 400g

x4004000 Encapsulation: ENET2 Input packets : 1 Output packets: 1 Protocol inet, MTU: 1500 Max nh cache: 75000, New hold nh limit: 75000, Curr nh cnt: 1, Curr new hold cnt: 0, NH drop cnt: 0 Flags: Sendbcast-pkt-to-re Addresses, Flags: Is-Preferred Is-Primary De

Re: constant FEC errors juniper mpc10e 400g

Max nh cache: 75000, New hold nh limit: 75000, Curr nh cnt: 1, Curr new hold cnt: 0, NH drop cnt: 0 Flags: Sendbcast-pkt-to-re Addresses, Flags: Is-Preferred Is-Primary Destination:10.10.10.76/30 <http://10.10.10.76/30>, Loca

Re: constant FEC errors juniper mpc10e 400g

Output packets: 1 Protocol inet, MTU: 1500 Max nh cache: 75000, New hold nh limit: 75000, Curr nh cnt: 1, Curr new hold cnt: 0, NH drop cnt: 0 Flags: Sendbcast-pkt-to-re Addresses, Flags: Is-Preferred Is-Primary

Re: constant FEC errors juniper mpc10e 400g

k flags : None >>> CoS queues : 8 supported, 8 maximum usable queues >>> Schedulers : 0 >>> Last flapped : 2024-04-17 13:55:28 CDT (00:36:19 ago) >>> Input rate : 0 bps (0 pps) >>> Output rate: 0 bps (0 pps) >>>

Re: constant FEC errors juniper mpc10e 400g

statistics Errors > > FEC Corrected Errors 801787 > > FEC Uncorrected Errors 0 > > FEC Corrected Errors Rate2054 > > FEC Uncorrected Errors Rate 0 > > Link Degrade : > > Link Monitoring : Disable > > Interface transmit statistics: Disabled > > > > Logical interface et-7/1/4.0 (Index 420) (SNMP ifIndex 815) > > Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2 > > Input packets : 1 > > Output packets: 1 > > Protocol inet, MTU: 1500 > > Max nh cache: 75000, New hold nh limit: 75000, Curr nh cnt: 1, > > Curr new hold cnt: 0, NH drop cnt: 0 > > Flags: Sendbcast-pkt-to-re > > Addresses, Flags: Is-Preferred Is-Primary > > Destination: 10.10.10.76/30, Local: 10.10.10.77, Broadcast: > > 10.10.10.79 > > > > -- > > -Aaron >

Re: constant FEC errors juniper mpc10e 400g

500 Max nh cache: 75000, New hold nh limit: 75000, Curr nh cnt: 1, Curr new hold cnt: 0, NH drop cnt: 0 Flags: Sendbcast-pkt-to-re Addresses, Flags: Is-Preferred Is-Primary Destination: 10.10.10.76/30, Local: 10.10.10.77, Broadcast: 10.10.10.79 -- -Aaron

Re: constant FEC errors juniper mpc10e 400g

p SNMP-Traps 0x4004000 Encapsulation: ENET2 Input packets : 1 Output packets: 1 Protocol inet, MTU: 1500 Max nh cache: 75000, New hold nh limit: 75000, Curr nh cnt: 1, Curr new hold cnt: 0, NH drop cnt: 0 Flags: Sendbcast-pkt-to-re Addresses, Flags: I

Re: constant FEC errors juniper mpc10e 400g

Protocol inet, MTU: 1500 Max nh cache: 75000, New hold nh limit: 75000, Curr nh cnt: 1, Curr new hold cnt: 0, NH drop cnt: 0 Flags: Sendbcast-pkt-to-re Addresses, Flags: Is-Preferred Is-Primary Destination:10.10.10.76/30 <http

Re: constant FEC errors juniper mpc10e 400g

nds >> Bit errors 0 >> Errored blocks 0 >> Ethernet FEC Mode : FEC119 >> Ethernet FEC statistics Errors >> FEC Corrected Errors 801787 >> FEC Uncorrect

Re: constant FEC errors juniper mpc10e 400g

ks 0 >> Ethernet FEC Mode : FEC119 >> Ethernet FEC statistics Errors >> FEC Corrected Errors 801787 >> FEC Uncorrected Errors 0 >> FEC Corrected Errors Rate

Re: constant FEC errors juniper mpc10e 400g

Input packets : 1 Output packets: 1 Protocol inet, MTU: 1500 Max nh cache: 75000, New hold nh limit: 75000, Curr nh cnt: 1, Curr new hold cnt: 0, NH drop cnt: 0 Flags: Sendbcast-pkt-to-re Addresses, Flags: Is-Preferred Is-Primary Dest

Re: constant FEC errors juniper mpc10e 400g

s Rate 0 > Link Degrade : > Link Monitoring : Disable > Interface transmit statistics: Disabled > > Logical interface et-7/1/4.0 (Index 420) (SNMP ifIndex 815) > Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2 >

Re: Upcoming LACNIC RPKI Migration

Hi Carlos, Congrats to you and the team for the smooth migration. I can speak for all of us at NLnet Labs that we’re super proud that LACNIC is now running Krill. Also, a special thanks to Tim Bruijnzeels (now back at the RIPE NCC) for the years of hard work on our open-source RPKI project

Re: Upcoming LACNIC RPKI Migration

Hi all, it's me again. The switch is complete. Thank you all for your patience. /Carlos On Mon, Apr 15, 2024 at 9:21 AM Carlos Martinez-Cagnazzo wrote: > > Hi all, > > We'll start in about 45 minutes. > > /Carlos > > On Mon, Apr 8, 2024 at 5:18 PM Carlos Martinez-Cagnazzo > wrote: > > > >

Re: Upcoming LACNIC RPKI Migration

Hi all, We'll start in about 45 minutes. /Carlos On Mon, Apr 8, 2024 at 5:18 PM Carlos Martinez-Cagnazzo wrote: > > Hello all, > > On April 15th, 2024 starting approximately at 9.30am UTC-3 LACNIC will > be migrating from our current legacy RPKI CA system to a new > Krill-based RPKI core. > >

Re: 2600:: No longer pings

> Wonderful news, this has now been fixed :) > Thank you to Cogent for fixing this indee. otoh, i still can not resist https://www.kame.net/ randy

Re: Whitebox Routers Beyond the Datasheet

Agreed. I think as a practical matter, the large majority of operators probably only care about time from last update / EoRIB -> FIBs forwarding working. As long as that time delta is acceptable for their environment and circumstances, that's 'good enough'. Definitely some edge cases and

Re: Open source Netflow analysis for monitoring AS-to-AS traffic

On 2024-03-27 09:09, Marinos Dimolianis wrote: My only "concern" was that it did not provide an API for consuming data externally. This is very high on my todo list, notably because I don't want to reimplement Grafana. The API already exists (the current web interface uses it) but it is not

Re: PRIX update

Congrats, Mehmet! Your persistence is paying off! Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 202-1230 a...@andyring.com > On Apr 13, 2024, at 10:14 AM, Mehmet wrote: > > Hello NANOG > > Little bit less than 19 years ago when PRIX was launched I had a dream to >

Re: Whitebox Routers Beyond the Datasheet

> On Apr 13, 2024, at 12:15 AM, 7ri...@gmail.com wrote: > > >> I feel like this shouldn't be listed on a data sheet for just the whitebox >> hardware. The software running on it would be the gating factor. > There would be two things ... BGP convergence, and then the time required to > get

Re[2]: Whitebox Routers Beyond the Datasheet

I feel like this shouldn't be listed on a data sheet for just the whitebox hardware. The software running on it would be the gating factor. There would be two things ... BGP convergence, and then the time required to get routes from the RIB into the hardware forwarding tables. These are

Re: Whitebox Routers Beyond the Datasheet

On Fri, Apr 12, 2024 at 6:03 AM Mike Hammett wrote: > What I've kind of come down to (based on little more than spec sheets) > are the EdgeCore AGR400 and the UfiSpace S9600-30DX. > That's wonderful and all, but does it take it from 64k routes > to 512k routes, or does it take it from 256k

Re: Whitebox Routers Beyond the Datasheet

e Hammett" Cc: nanog@nanog.org Sent: Friday, April 12, 2024 1:30:04 PM Subject: Re: Whitebox Routers Beyond the Datasheet Also, BGP convergence isn't listed (nor do I rarely ever see it talked about in such sheets). I feel like this shouldn't be listed on a data sheet for just th

Re: Whitebox Routers Beyond the Datasheet

> > Also, BGP convergence isn't listed (nor do I rarely ever see it talked > about in such sheets). I feel like this shouldn't be listed on a data sheet for just the whitebox hardware. The software running on it would be the gating factor. On Fri, Apr 12, 2024 at 9:05 AM Mike Hammett wrote: >

Re: Whitebox Routers Beyond the Datasheet

I'm surprised they stopped showing those options in the datasheet. They used to have those in the spec sheet when I bought Edgecore hardware some years ago. Seems like you will have to contact sales teams. If it can help, I use AS5916-XKS and the TCAM supports millions of routes. Out of my mind,

Re: Anyone got a contact at OpenAI. They have a spider problem.

On Thu, Apr 11, 2024 at 1:39 PM Randy Bush wrote: > > Amazon's spider got stuck there a month or two ago but fortunately I was > > able to find someone to pass the word and it stopped. Got any contacts > > at OpenAI? > > why? you are doing a societal good by ensnaring them. dig a deeper >

Re: Attn Access ISPs - FCC BB Labels (machine-readable standards)

It is certainly possible – thanks for the suggestion! If you’d like to participate, let me know 1:1 off list. Jason From: NANOG on behalf of Bryan Ward Date: Thursday, April 11, 2024 at 16:58 To: Ben Cartwright-Cox via NANOG Subject: RE: Attn Access ISPs - FCC BB Labels (machine-readable

Re: Anyone got a contact at OpenAI. They have a spider problem.

On 4/11/24 12:38, Randy Bush wrote: Amazon's spider got stuck there a month or two ago but fortunately I was able to find someone to pass the word and it stopped. Got any contacts at OpenAI? why? you are doing a societal good by ensnaring them. dig a deeper hole. randy A random image

RE: Attn Access ISPs - FCC BB Labels (machine-readable standards)

Why reinvent new 4-digit codes to identify the type of service? Can't the existing ATIS service codes be used for this too? -- Bryan Ward Lead Network Engineer Dartmouth College Network Services bryan.w...@dartmouth.edu Scheduling a meeting? I prefer Zoom.

Re: Anyone got a contact at OpenAI. They have a spider problem.

On Thu, Apr 11, 2024 at 3:40 PM Randy Bush wrote: > > Amazon's spider got stuck there a month or two ago but fortunately I was > > able to find someone to pass the word and it stopped. Got any contacts > > at OpenAI? > > why? you are doing a societal good by ensnaring them. dig a deeper >

Re: Anyone got a contact at OpenAI. They have a spider problem.

> Amazon's spider got stuck there a month or two ago but fortunately I was > able to find someone to pass the word and it stopped. Got any contacts > at OpenAI? why? you are doing a societal good by ensnaring them. dig a deeper hole. randy

Re: Attn Access ISPs - FCC BB Labels (machine-readable standards)

I appreciate your effort in making a tool! This is another tool: https://bblmaker.com/ - I like it because I have one CSS file and then a few content pages for the plans. Just FYI the Oct 10 deadline is for 100k or less subscribers. April 10 for 100k+. On Thu, Apr 11, 2024 at 9:08 AM

Re: Anyone got a contact at OpenAI. They have a spider problem.

"John Levine" writes: > PS: If you were wondering what they're using to train GPT-5, well, now you > know. And it's not very trainable, it seems? I believe most amoebas respond better to 3 million identical events... Bjørn

Re: 2600:: No longer pings

Wonderful news, this has now been fixed :) Thank you to Cogent for fixing this On Sat, 6 Apr 2024 at 11:00, Ben Cartwright-Cox wrote: > > It appears that 2600:: no longer responds to ICMP. > > $ mtr -rwc 1 2600:: > Start: 2024-04-06T10:53:41+0100 > HOST: metropolis

Re: Upcoming LACNIC RPKI Migration

Thanks Job! Much appreciated! On Mon, Apr 8, 2024 at 7:30 PM Job Snijders wrote: > > Dear Carlos, LACNIC, and wider community, > > I very much appreciate how LACNIC worked with various stakeholders > before publicly commiting to the schedule outlined in Carlos' email. > > From what I can see,

Re: Upcoming LACNIC RPKI Migration

Dear Carlos, LACNIC, and wider community, I very much appreciate how LACNIC worked with various stakeholders before publicly commiting to the schedule outlined in Carlos' email. >From what I can see, LACNIC pro-actively and properly tested their purported post-migration environment with very

Re: Netskrt - ISP-colo CDN

icon.png]<https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> From: "Tim Burke" To: "Aaron Gould" Cc: nanog@nanog.org Sent: Saturday, April 6, 2024 10:00:05 PM Subject: Re: Netskrt - ISP-colo CDN I have been trying to get _away_ from caching appliances on our

Re: Netskrt - ISP-colo CDN

it. In many areas, space + power + port is cheaper than transport.-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISPFrom: "Tim Burke" To: "Aaron Gould" Cc: nanog@nanog.orgSent: Saturday, April 6, 2024 10:00:05 PMSubject: Re: Netskrt - ISP-colo C

Re: Netskrt - ISP-colo CDN

Message - From: "Tim Burke" To: "Aaron Gould" Cc: nanog@nanog.org Sent: Saturday, April 6, 2024 10:00:05 PM Subject: Re: Netskrt - ISP-colo CDN I have been trying to get _away_ from caching appliances on our network — other than Google, we are able to pick up most of the

Re: 2600:: No longer pings

On Sun, Apr 07, 2024 at 01:12:21PM +0200, Tomáš Holý wrote a message of 227 lines which said: > $ for i in `cat list.txt`; do fping -6 $i -t 500 -r 0; done | grep 'is alive' > 2409:: is alive > 2a09:: is alive > 2a11:: is alive > 2a12:: is alive All of them are public DNS resolvers, which

Re: 2600:: No longer pings

I'd be just as gutted if they ever pull the plug on ipv6.google.com - it's my go-to "first attempt" for an IPv6 test. :-) But this got me curious, so I grabbed a list of prefixes from [1] and decided to ping them all. Since I went through all that effort, might as well

Re: 2600:: No longer pings

On Sun, Apr 07, 2024 at 09:33:18AM +0530, Gaurav Kansal via NANOG wrote a message of 41 lines which said: > 2409:: is replying the ICMPv6 request, in case anyone interested Thank, I did not know this service. Note that the signatures on the reverse expired in february: % dig +cd -x 2409::

Re: Netskrt - ISP-colo CDN

Agreed ... it generally doesn't make sense to install caches where the content is just a few racks over. But if you have a network that serves smaller population centers where CDNs are sparse or non-existent, then it gets the content closer to the eyeballs and saves considerably on transport

Re: TFTP over anycast

On Sat, 6 Apr 2024 at 12:00, Bill Woodcock wrote: > That’s been the normal way of doing it for some 35 years now. iBGP > advertise, or don’t advertise, the service address, which is attached to the > loopback, depending whether you’re ready to service traffic. If we are talking about eBGP,

Re: 2600:: No longer pings

2409:: is replying the ICMPv6 request, in case anyone interested > On 6 Apr 2024, at 15:31, nanog@nanog.org wrote: > > It appears that 2600:: no longer responds to ICMP. > > $ mtr -rwc 1 2600:: > Start: 2024-04-06T10:53:41+0100 > HOST: metropolis Loss% >

Re: Netskrt - ISP-colo CDN

I have been trying to get _away_ from caching appliances on our network — other than Google, we are able to pick up most of the stuff that otherwise would be cacheable via private peering; so it doesn’t make a whole lot of sense for us to have appliances in the datacenter taking up space,

Re: 2600:: No longer pings

On Sat, Apr 06, 2024 at 06:19:57PM +0800, Soha Jin wrote a message of 50 lines which said: > I don't know what happed to 2600::, but 2a09:: and 2a11:: can be > used as alternatives. These are addresses of https://dns.sb/ running > by xTom. Very good DNS service, buy the way. But, although I

RE: 2600:: No longer pings

I don't know what happed to 2600::, but 2a09:: and 2a11:: can be used as alternatives. These are addresses of https://dns.sb/ running by xTom. > -Original Message- > From: NANOG On Behalf Of Ben > Cartwright-Cox via NANOG > Sent: Saturday, April 6, 2024 6:01 PM > To: North American

Re: TFTP over anycast

> On Apr 6, 2024, at 10:30, Ray Bellis wrote: > On 27/02/2024 18:47, William Herrin wrote: >> Then I'd write a script to monitor the local tftp server and stop frr if it >> detects any problems with the tftp server. > There are other ways to achieve this without actually stopping the routing

Re: TFTP over anycast

On 27/02/2024 18:47, William Herrin wrote: Then I'd write a script to monitor the local tftp server and stop frr if it detects any problems with the tftp server. There are other ways to achieve this without actually stopping the routing daemon. We have DNS servers where the anycast

RE: Netskrt - ISP-colo CDN

install it and let it run. As more services opt to use them, they will have more fill time as well though… Dennis From: NANOG On Behalf Of Aaron Gould Sent: Thursday, April 4, 2024 6:01 PM To: John Stitt ; Eric Dugas Cc: nanog@nanog.org Subject: Re: Netskrt - ISP-colo CDN Thanks

Re: Netskrt - ISP-colo CDN

re.  Looks like Cogent and Zayo for upstreams and only peer I see is AS1239 (Sprint Wireline (Cogent)) John Stitt *From:*NANOG *On Behalf Of *Aaron Gould *Sent:* Thursday, April 4, 2024 4:36 PM *To:* Eric Dugas *Cc:* nanog@nanog.org *Subject:* Re: Netskrt - IS

Re: Netskrt - ISP-colo CDN

It's free. - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "Eric Dugas via NANOG" To: "Aaron Gould" Cc: nanog@nanog.org Sent: Thursday, April 4, 2024 4:12:38 PM Subject: Re: Ne

<    1   2   3   4   5   6   7   8   9   10   >