>
> Not disputing, just curious. I assume you are talking about federal
> law in the US, can you be specific about what the law says?
>
Just standard contract law is all I was referring too.
On Fri, Oct 11, 2024 at 9:55 AM Saku Ytti wrote:
> On Fri, 11 Oct 2024 at 16:36, Tom
https://www.google.com/intl/en/ipv6/statistics.html
On Tue, Oct 8, 2024 at 1:19 PM Jon Lewis wrote:
> I'm not so sure about that. Our customers are all offered dual-stack
> (DHCPv6, DHCPv6-PD). Do any of the common streaming services support v6
> yet? Last I checked, Hulu did not.
>
> On Tu
Hi Jon,
Are you dual stack? v6 would solve some of these issues?
On Tue, Oct 8, 2024 at 12:20 PM Jon Lewis wrote:
> We started rolling out CGNAT about 6 months ago. It was smooth sailing
> for the first few months, but we eventually did run into a number of
> issues.
>
> Our customer base i
>
> I really really really find it disgusting that companies have no problem
> asking for this kind of information!! Its not only Juniper but also other
> major brands.
>
Pretty standard capitalism feature. Everyone wants to know what else they
might be able to sell you.
I just bought a single sw
>
> How can such a large company have something so simple as SIP
> registration mangled up?
>
Very little incentive to fix it. The number of customers that are able to
switch providers when something like this doesn't work is a fractional
percentage of overall customer churn.
The MBAs say it's ch
Not really an escalation point above the registrar level.
https://www.icann.org/resources/pages/about-icann-faqs-2019-02-25-en
Q: Does ICANN help with domain ownership or registration disputes?
>
> A: *No*, ICANN does not get involved in disputes regarding domain
> ownership or registration. ICAN
>
> I've been fighting a similar issue. I'd like to throw in, a lot of mobile
> devices are geolocation dependent for time, and may completely disregard
> DHCP timezone and instead rely entirely on GeoLocation *even if it is
> woefully inaccurate, or unobtainable*.
>
1. RFC4833 *presumes* that the
My understanding has been that generally, if the cellular network signal
was above a certain threshold, phones won't even attempt to use wifi
calling. Some carriers used to let you flip a switch to force the phone to
prefer wifi over cellular, but some have removed that. ( Verizon for
example. )
I
On Tue, Jul 30, 2024 at 12:35 PM Innocent Obi
>> wrote:
>>
>>> Luckily it seems my org has since mitigated this, but it would be
>>> interesting to know the broader impacts/who is broadly impacted.
>>>
>>> On Tue, Jul 30, 2024 at 12:20 PM Tom Beecher wro
If you're only getting this now, you're probably in trouble, because
they're revoking affected certs in about 15 mins.
On Tue, Jul 30, 2024 at 2:53 PM Innocent Obi
wrote:
> Just in-case this hasn't made its way around:
> https://www.digicert.com/support/certificate-revocation-incident.
>
>
No, because there's no set schedule for these things.
Some publishers / consoles get content/patches up in advance to allow user
to pre-load. This can smooth out the bandwidth hits, but only if the users
enable the pre-load feature. Many don't. Other publishers just enable the
updates at once for
answers all of your
> concerns. Further, they remark that this was an especially sophisticated
> infection, that hid its tracks well.
>
>
>
> Lee
>
>
>
> *From:* NANOG *On
> Behalf Of *Tom Beecher
> *Sent:* Sunday, June 2, 2024 4:23 PM
> *To:* Dave Taht
> *Cc
That post from Mr. Perens about this is honestly really shitty.
1. Is he right that Lumen has to shoulder blame for not keeping CPE updated
with exploit free software? Certainly.
2. Making a claim that all 600k of these routers were being used as botnet
zombies without any supporting evidence is r
to be
solved.
Not engaging with RPKI because it doesn't perfectly solve every
BGP-adjacent issue is a poor argument.
On Fri, May 17, 2024 at 7:24 PM Ca By wrote:
>
>
> On Fri, May 17, 2024 at 4:20 PM Tom Beecher wrote:
>
>> RPKI is not a good solution for all network
>
> RPKI is not a good solution for all networks, especially those that are
> non-transit in nature and take reasonable mitigation actions like IRR
> prefix lists.
>
Some of the largest , most impactful route leaks have come from non-transit
networks reliant on IRR managed prefix lists.
On Fri, M
>
> Just because they were presented with the information doesn't mean they
> understand.
It's our job as operators to get involved and help them understand as best
as can be done, so that the proposals are as well informed as possible.
> Just because they understand doesn't mean they execute b
Same, this address for me is also gmail.
This is what Gmail shows me from earlier today, when the SPF record was not
present :
Message ID <
bff409fd0177c9caf1461e2439691...@polarismail--com.w.emailarray.com>
Created at: Thu, May 16, 2024 at 11:59 AM (Delivered after 77 seconds)
From: "Scott Q."
>
> I'm surprised nobody noticed for close to 10 days.
Probably because it wasn't 10 days.
On Thu, May 16, 2024 at 10:26 PM Scott Q. wrote:
> I'm surprised nobody noticed for close to 10 days. I was away from work
> and upon coming back I saw the little discussion there was , in my Spam
> fold
>
> That means that some IP addresses in the block 192.0.0.0/24 may be
> routable.
>
> So, I would not make this a bogon.
>
This ignores note 2 on the IANA definitions page, next to 192.0.0.0/24 :
> [2]
>
> Not useable unless by virtue of a more specific reservation.
>
> Which then lists the mor
What are using for small campus border routers? So four to eight 10G ports
with a FIB for full scale L3?
Tom
Validin, made an interesting observation on this. I am also a Spectrum
residential customer, none of their equipment, run my own DNS server
(pihole).
My DHCP Assigned DNS servers are
2001:1998:f00:1::1
2001:1998:f00:2::1
bash-3.2$ dig -x 2001:1998:f00:1::1 +short
dns-cac-lb-01.rr.com.
bash-3.2$
now if this FEC stuff I see concurring is actually
> contained in Ethernet Frames? If so, please send a link to show the
> ethernet frame structure as it pertains to this 400g fec stuff. If so, I'd
> really like to know the header format, etc.
>
> -Aaron
> On 4/18/2024 1:17 PM, T
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 wil
>
> 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, proba
Notes I found that I took from smart optical people :
"PAM4 runs at much lower SNRs than NRZ, because you're trying to read 4
distinct voltage levels instead of 2.Even the cleanest system will have
some of that, so the only way to make it usable is to have FEC in place."
On Wed, Apr 17, 2024 at
Isn't FEC required by the 400G spec?
On Wed, Apr 17, 2024 at 3:45 PM Aaron Gould wrote:
> i did. Usually my NANOG and J-NSP email list gets me a quicker solution
> than JTAC.
>
> -Aaron
> On 4/17/2024 2:37 PM, Dominik Dobrowolski wrote:
>
> Open a JTAC case,
> That looks like a work for them
>
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
circumsta
>
> 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:
>
I don't think anything is 'easily fixed' on this topic.
I do however hope that everyone accepts at face value that the board,
staff, and PC are *trying* to do the right things here. Doesn't mean that
it *will* always be the right thing, or even that a majority of people can
agree on what the right
>
> My memory is a little fuzzy, but I think I recall one of the early WiT
> lunches hosted at NANOG that was women-only, where some men were upset
> for being "left out". Whether that was good or bad is less important
> than understanding what the outcome of a women-only activity is for
> women, e
There was a Women in Tech Mixer on Sunday in Charlotte as well. As I recall
there was a pretty decent attendance.
During my time on the PC, we always got a lot of feedback about Sunday when
the topic came up. Some members were strongly opposed to anything on Sunday
and didn't even like the Hackath
Yeah, cost to implement dst_as_path lookups far outweighs the usefulness
IMO. If you really want that it's much better to get it via BMP. ( Same
with communities and localpref in the extended gateway definition of
sflow. )
Fundamentally I've always disagreed with how sFlow aggregates flow data
wi
Lots of people are encountering this, yes.
You can try opening a case yourself, and hope it gets to someone with a
clue. If you don't have a support contract with them, your chances are
almost 0. If you do, your chances are slightly higher, but not by much.
most likely they will just tell you to '
>
> It may be a pain in the butt to get Cisco equipment, but their TAC is
> sublime. If something is critical enough, and you push hard enough, Cisco
> will move heaven and earth to solve your issue.
>
This was an amazing laugh on a Monday morning. Thanks!
On Thu, Mar 7, 2024 at 2:47 PM Joel Esl
>
> I think there is
> a very careful attitude around making sure not just anyone can get
> this information, especially after the Nashville bombing on Christmas
> Day 2020.
>
Keeping fiber location info close to the vest is nothing new. I'm not now
sure why/how you feel like this connects to the
>
> Erik Prince was on the PBD podcast saying he has a 70% chance in his head
> it was China.
>
Why do we care what his (almost certainly uninformed) opinion is?
On Thu, Feb 29, 2024 at 2:56 PM Javier J wrote:
> Where did you see this? Erik Prince was on the PBD podcast saying he has a
> 70% ch
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 A
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.
Perh
Does anyone know what the minimum traffic is to qualify for an Akamai AANP
cache?
Tom
>
> and it's affecting our customers' access to various ===>> websites.<<===
>
On Tue, Feb 20, 2024 at 6:15 PM Pui Ee Luun Edylie wrote:
> There must be a reason why the web site chooses the WAF list to block out
> the victim? If so why not the victim to contact the website to request them
> to
>
> I'm not going to participate in the security conversation, but we do
> absolutely need something to fill the role of NAT in v6. If it's already
> there or not, I don't know. Use case: Joe's Taco Shop. Joe doesn't want a
> down Internet connection to prevent transactions from completing, so he
>
>
> Any given layer of security can be breached with expense and effort.
> Breaching every layer of security at the same time is more challenging
> than breaching any particular one of them. The use of NAT adds a layer
> of security to the system that is not otherwise there.
>
>
> Think of it like
$/IPv4 address peaked in 2021, and has been declining since.
On Thu, Feb 15, 2024 at 16:05 Brian Knight via NANOG
wrote:
> On 2024-02-15 13:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > I've said it before, and I'll say it again:
> >
> > The only thing stopping global IPv6 deployment is
> >
e we can
> encourage and help people move towards IPv6 we can't force adoption through
> prevention of access to IPv4.
>
> Regards,
> Christopher Hawker
> --
> *From:* Owen DeLong
> *Sent:* Thursday, February 15, 2024 4:23 AM
> *To:* Chris
> Maybe this should have gone to the members mailing list, but I couldn’t
> find one.
>
>
>
memb...@nanog.org
On Thu, Feb 15, 2024 at 10:31 AM Howard, Lee via NANOG
wrote:
> I’m jumping on an earlier part of the thread.
>
>
>
> Based on what I heard at the Members Meeting and several follow up
>
> All we can do is educate people on the importance of IPv6 uptake, we can
> not force people to adopt it.
>
At this stage of the game, networks and products that don't support V6
aren't likely to do so unless there is a forcing function to make them do
it. Meaning money.
On Wed, Feb 14, 2024
None of the conversation was about COVID protocols.
Lowered in person attendance because of *individual concerns about health
risks* was mentioned. The conversation then went sideways into public
health policy and definitions, which absolutely doesn't belong on the list.
On Wed, Feb 14, 2024 at 7
world re-address to IPv6. It’s not a race.
Tom
n the current state of
COVID, if it's referred to as 'pandemic' or 'endemic' , etc. Nor does that
sort of convo really belong anywhere near this list.
On Tue, Feb 13, 2024 at 7:58 PM Glen A. Pearce wrote:
> On 11/02/2024 7:56 a.m., Tom Beecher wrote:
> > Yup. Pos
n, it's never going to happen.
On Tue, Feb 13, 2024 at 5:15 PM Christopher Hawker
wrote:
> Hi Tom,
>
> We aren't trying to have a debate on this. All we can do is present our
> case, explain our reasons and hope that we can gain a consensus from the
> community.
>
>
>
> PS: I know this because it will take 98 years of process before the
> RIRs can start allocating it.
>
Intense optimism detected!
On Tue, Feb 13, 2024 at 4:27 PM John Levine wrote:
> It appears that Lyndon Nerenberg (VE7TFX/VE6BBM) said:
> >And what are they going to do when 240/4 runs out?
>
> Now, we know there's definitely going to be some pushback on this. This
> won't be easy to accomplish and it will take some time.
It won't ever be 'accomplished' by trying to debate this in the media.
On Tue, Feb 13, 2024 at 5:05 AM Christopher Hawker
wrote:
> Hello all,
>
> [Note: I have
Yup. Post pandemic, the unfortunate hotel situation, and a non-zero number
of companies still have tight travel budgets.
It's been slowly creeping back though.
On Sun, Feb 11, 2024 at 8:44 AM Ryan Hamel wrote:
> Mike,
>
> The numbers have not bounced back to pre-pandemic levels, and it doesn't
>
>
> This sounded perfect, and I could beat my friend around the head with
> it… but reading further reveals:
> "Route aggregation and information reduction techniques (see
> Section 9.2.2.1) may optionally be applied.
>
> Any local policy that results in routes being added to an Adj-RIB-Out
> wi
ards.
On Thu, Feb 1, 2024 at 2:21 AM Frank Habicht wrote:
> On 01/02/2024 01:45, Tom Beecher wrote:
> > Seems a bit dramatic. Companies all over the world have been using other
> > people's public IPs internally for decades. I worked at a place 20 odd
> > years ago that
>
> Even though it is very risky to steal resources from an organization
> that can deploy a black helicopter or a nuclear warhead over you
>
Seems a bit dramatic. Companies all over the world have been using other
people's public IPs internally for decades. I worked at a place 20 odd
years ago th
>
> I see it mentioned in this doc:
>
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book/irg-origin-as.pdf
You see SOVC mentioned, yes. But you don't see the word 'stale'.
Please don't just paste what ChatGPT says. It's not an authoritative
source.
>
> It that always true? I'd started off thinking that, but a friend of mine
> (yes, the same one that started this argument) convinced me that
> some forms of BGP summarization/aggregation don't always generate a "local"
> route…
>
> I'd also thought that I'd seen this when redistributing an IGP
>
> Unless overridden, BGP takes -distance- into account where distance =
> AS path length.
>
An AS_PATH length of 10 could be a physical distance of 1 mile.
An AS_PATH length of 1 could be a physical distance of 1000 miles.
BGP TE communities exist to provide signalling in the event that the
st
>
> Because big operators think it reasonable to localpref distance routes
> ahead of nearby ones so long as the distant routes arrive from
> customers. I'll remember that the next time folks complain about the
> size of the routing table. This one you did to yourselves.
>
That has absolutely noth
>
> Apparently there is a conflict between what you want and what 47787 wants.
> As you both seem to be paying customers, you should probably ask 3356 to
> resolve that instead of us random internet folks.
>
Calling 3356 and saying "I know your global routing policy is to prefer a
customer learned
>
> I feel your pain Bill, but from a slightly different angle. For years the
> large CDNs have been disregarding prepends. When a source AS disregards
> BGP best path selection rules, it sets off a chain reaction of silliness
> not attributable to the transit AS's. At the terminus of that chain
>
> As I already explained, neither the primary nor any of the backup
> providers directly peer with Centurylink, thus have no communities for
> controlling announcements to Centurylink.
No, but they do have an option to not announce to 47787.
https://docs.freerangecloud.com/en/bgp/communities
>
> I’d bet that 47787 is a paying century link customer. As such, despite the
> ugliness of the path, CL probably local prefs everything advertised by them
> higher than any non-paying link. I’m willing to bet 1299 is peered and not
> paying CL.
>
It's almost as if you've done this before. :)
Co
disagree.
On Sun, Jan 21, 2024 at 1:22 AM Jay R. Ashworth wrote:
> ----- Original Message -
> > From: "Tom Beecher"
> > To: "Lamar Owen"
> > Cc: nanog@nanog.org
> > Sent: Wednesday, January 17, 2024 8:06:07 PM
> > Subject: Re: "
>
> Because people keep responding.
>
Doesn't really make any difference. Mr. Chen filed his first draft in Dec
2016. He finds a reason to talk about it on every mailing list and forum
he can find, but doesn't spend any time engaging in the standards
processes, other than renewing his draft every
tix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> --
> *From: *"Tom Beecher"
> *To: *"Mike Hammett"
>
> and none in the other two facilities you operate in that same building had
> any failures.
Quoting directly from their outage ticket updates :
CH2 does not have chillers, cooling arrangement is DX CRACs manufactured by
> another company. CH3 has Smart chillers but are water cooled not air co
Many CDNs have hardware options for self hosted caches. I think there would
likely be concerns about <20G of connectivity to those caches though. With
an incorrect setup, you could end up maxing out those links just with cache
fill traffic itself.
On Thu, Jan 18, 2024 at 6:54 AM Jérôme Nicolle w
>
> If these chillers are connected to BACnet or similar network, then I
> wouldn't rule out the possibility of an attack.
>
Don't insinuate something like this without evidence. Completely
unreasonable and inappropriate.
On Wed, Jan 17, 2024 at 8:31 AM Lamar Owen wrote:
> >This sort of mass fa
It only applies if you are purchasing their monitoring services. Not just
to use the site for info.
On Tue, Jan 16, 2024 at 5:04 PM scott via NANOG wrote:
>
>
> On 1/16/24 2:44 PM, Ian Chilton wrote:
>
> > Not a direct answer to your question, but if you're not aware of it,
> > https://bgp.tools
The AS rank is calculated by a program. I think they would be unwilling to
modify it manually.
I think you have to wait for the monthly re-generate.
Tom
> On Jan 16, 2024, at 1:34 PM, wrote:
>
> Hello Community,
>
> I am looking for an operational contact for a
>
> If "EzIP" is about using 240/4 as CGNAT space, let's call it what it is,
> not rename something that already exists and attempt to claim it as a new
> idea.
>
Yes he is essentially re-creating NAT/CGNAT, but in a worse way.
If you ignore all the multitude of technical issues, if you grabbed a
I have good success with nsc.global@
The last email I’ve received from them was Dec 12, 2023, and they typically
respond in two days or less.
Tom
> On Jan 15, 2024, at 11:49 AM, Eric Dugas via NANOG wrote:
>
> Hello,
>
> I'm searching for a technical contact,
>
> Gmail is therefore in violation of the RFC5822. It's quite clear how it
> should work per the RFC appendix.
>
Well, no. Asterisks added for emphasis.
This specification is intended as a definition of what message
>content format is to be passed between systems. Though some message
>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Figure 9 TCP/IP Header: From T4a to SPR4
>
>
Oh my.. you actually meant it.
The draft authors don't appear to understand that TCP headers and IP
headers **are not the same thing**.
I would suggest reviewing RFC 791 (
<http://www.midwest-ix.com/>
> <https://www.facebook.com/mdwestix>
> <https://www.linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrothe
I go into my cave to finish the todo list for the week, and I come out to
see Mr. Chen :
- Telling Randy Bush he should "read some history" on IPv6
- Implying that Vint Cerf ever said anything about EzIP
Fairly impressive sequence of self ownage.
On Fri, Jan 12, 2024 at 5:46 PM Randy Bush wrote:
tions>
> <https://twitter.com/ICSIL>
> Midwest Internet Exchange <http://www.midwest-ix.com/>
> <https://www.facebook.com/mdwestix>
> <https://www.linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://w
>
> How far are we from that, in reality? I don't have any intention on using
> the space, but I would like to put some definition to this boogey man.
It's unknowable really.
Lots of network software works just fine today with it. Some don't. To my
knowledge some NOS vendors have outright refuse
t; accounted for <1 per year IIRC), it seemed the 240/4 lasting a year was an
> optimistic count.
>
> Owen
>
>
> On Jan 11, 2024, at 13:15, Christopher Hawker
> wrote:
>
> Hi Tom,
>
> I'm not too sure I understand where the idea came from that 2 x /8 w
s 'squatting'. Today, nobody's
usage of 240/4 internally impacts anyone else.
On Thu, Jan 11, 2024 at 12:37 PM Dave Taht wrote:
> On Thu, Jan 11, 2024 at 12:26 PM Tom Beecher wrote:
> >
> > Christopher-
> >
> >> Reclassifying this space, would add
strong case was presented to convert this space.
>
> https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html
>
> Regards,
> Christopher Hawker
>
> On Thu, 11 Jan 2024 at 20:40, Dave Taht wrote:
>
>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher wrote
ould get IPs for free , and
implied if he reached out to you off list , you could help him make it
work. That was intentionally misleading, and frankly doesn't reflect very
well on you at all.
On Wed, Jan 10, 2024 at 11:09 PM Abraham Y. Chen wrote:
> Hi, Tom:
>
> 1)Your
024 at 10:45 AM Michael Butler
wrote:
> On 1/10/24 10:12, Tom Beecher wrote:
> > Karim-
> >
> > Please be cautious about this advice, and understand the full context.
> >
> > 240/4 is still classified as RESERVED space. While you would certainly
> > be able
Karim-
Please be cautious about this advice, and understand the full context.
240/4 is still classified as RESERVED space. While you would certainly be
able to use it on internal networks if your equipment supports it, you
cannot use it as publicly routable space. There have been many proposals
o
>
> I did some research on this and it seems like perhaps the on-boot event
> handler launching a python daemon to do this active probing out each isp
> circuit and then making config changes in response to transit failures
> might be the best option available to us.
>
Pretty much, yes. They don't
>
> But why would AliExpress be redirecting to DDN space? Is this legitimate?
> Ali hoping to get away with squatting, or something else?
I've seen a large number of cases that a company was using someone else's
non-RFC1918 space for some reason, and that was accidentally exposed via
application
Me too. Fastly has been promising me peering every year for the past five
years.
They are just a few cabinets over, so it has been pretty frustrating.
Tom
Sent from my iPad
> On Dec 5, 2023, at 1:25 PM, Ian Chilton wrote:
>
>
> Hi Peter,
>
> Sorry you didn't
>
> i would expect that google announces the /16 at least from 'everywhere',
> yes.
>
I see the specific /18s Drew asked about initially. Didn't check for the
covering /16.
On Tue, Dec 5, 2023 at 1:29 PM Christopher Morrow
wrote:
> On Tue, Dec 5, 2023
>From my observations, all us-east-5 IPs are announced via transit and
peering at all of my locations Chicago and east.
On Mon, Dec 4, 2023 at 9:11 AM Drew Weaver wrote:
> Hello,
>
>
>
> We are trying to reduce latency to a region in Google Cloud which we are
> in the same city of. Latency is cu
172.253.X.X are Google DNS : https://www.gstatic.com/ipranges/publicdns.json
172.71.X.X are Cloudflare : https://www.cloudflare.com/ips-v4/#
On Sun, Dec 3, 2023 at 1:49 PM John Levine wrote:
> At contacts.abuse.net, I have a little stunt DNS server that provides
> domain contact info, e.g.:
>
They are probably spoofed IPs. So those are the target IP IPs of a DDoS
What king of amplification factor does your DNS server have? I bet with the
changes you’ve made, it’s super high. People are looking for DNS servers like
that.
Tom
> On Dec 3, 2023, at 10:49 AM, John Levine wr
Trying to put technical requirements like this into law and public policy
is an extremely terrible idea. This letter should never be sent.
The regulatory agencies today don't have the manpower or expertise to
adequately enforce the more generic broadband deployment rules. What
fantasy world exists
The era of “buffer bloat” has passed. Buffer bloat is just about jitter, and
jitter mitigation is just better now.
I don’t think jitter needs to be part of public policy.
Tom
Not sure we need the FCC telling us how to build products or run networks.
Seat belts are life-or-death, but bufferbloat is rarely fatal ;-) Let it
be a point of differentiation.
-- Tom
On Thu, Nov 30, 2023 at 4:56 PM Dave Taht wrote:
> Over here:
>
>
> https://docs.google.co

m_sm_configuring_dying_gasp
PDF Document · 1.1 MB
Dying gasp is just a Ethernet OAM frame broadcast on (usually) all ports just
before loss of power. If anything, Ethernet had this first, and ONTs just
included it into their standards.
Tom
> On Nov 27, 2023, at 11:40 AM, Josh Luth
> On Nov 21, 2023, at 7:42 AM, Dale W. Carder wrote:
>
> Thus spake Tom Samplonius (t...@samplonius.org) on Mon, Nov 20, 2023 at
> 07:02:52PM -0800:
>>> On Nov 17, 2023, at 6:58 AM, Christopher Morrow
>>> wrote:
>>> IRR filters provide control ove
fiber cut.
Tom
> On Nov 27, 2023, at 6:41 AM, Josh Luthman wrote:
>
> Around here, Spectrum uses an Adva for demarc and it can not do rfc2544
> testing. They will unplug the Adva and plug in the techs' mobile unit (Viavi
> I think). VZW/Tmo/Sprint/etc don't seem to
I don't know about specific SKUs, but IP Infusion make a very popular set
of L2 switches.
On Wed, Nov 22, 2023 at 8:42 PM Ross Tajvar wrote:
> I'm evaluating CPEs for one of my clients, a regional ISP. Currently,
> we're terminating the customer's service (L3) on our upstream equipment and
> ex
1 - 100 of 1005 matches
Mail list logo