On Fri, 10 Jan 2025 at 13:02, Jason Iannone wrote:
> Saku speaks from the privileged position of an infrastructure owner. We
> assume that interface connectivity is provided by L1 links, with OEO in
> transit nodes as a worst case.
>
> But the clever budget conscious among us have deployed rout
On Fri, 10 Jan 2025 at 00:34, David Zimmerman via NANOG wrote:
> Towards Saku's, Tore's, and Tom's comments about watching error counters,
> I'll keep that in mind, though I expect I'll want to cover situations where
> frames are simply lost rather than errored. For example (tapping into Alex'
On Thu, 9 Jan 2025 at 00:23, David Zimmerman via NANOG wrote:
> find any formal or semi-formal writing about quantification of BFD's
> effectiveness. For example, my mental picture is a 3D graph where, for a
> given Control rate and corresponding Detection Time, the X axis is percentage
> of
On Thu, 26 Dec 2024 at 17:51, Bryan Fields wrote:
> I believe it was that one side was vlan tagged and the other wasn't or
> something to the effect of how the ISO MTU was calculated in the classic-IOS
> version vs. Junos. As this was for less than a carrier grade setup (tactical
> deployment du
On Thu, 26 Dec 2024 at 05:55, Bryan Fields wrote:
> vlan {
> unit 405 {
> family iso {
> # holy shit this is important. CISCO and Juniper will not talk unless the
> MTU is set
> mtu 1492;
> }
>}
> }
This is almost certainly the wrong solution to a real problem. Real
On Wed, 25 Dec 2024 at 05:34, Matthew Petach wrote:
> Power is a *huge* part of the equation that I think many people overlook.
> When you look at what a really big chassis takes in terms of power feeds,
> it's not uncommon to need relatively specialized 3-phase 240V power feeds
> for the very-hi
On Tue, 24 Dec 2024 at 21:38, Mike Hammett wrote:
"what benefits is OP seeing here when it comes to pizzabox"
>
> I'm more learning and questioning than stating. I've thoroughly enjoyed
> the thread.
>
> One of the main advantages I saw from the outset was that I could start
> with a single box a
On Tue, 24 Dec 2024 at 17:22, Tom Beecher wrote:
> It's possible I s/chip/ in my head with a different meaning than you
> intended, and I am answering a different question.
>
> I generally won't put all LAG members on the same ASIC, or even same
> linecard, for failure domain reasons. I also do
On Tue, 24 Dec 2024 at 17:00, Tom Beecher wrote:
>> Isn't the solution here the same? Have all LACP member ports in the same
>> chip?
> Which any self-respecting operator usually doesn't want to do because of
> failure domains.
I'm just struggling to understand the difference between
stack-of-
On Tue, 24 Dec 2024 at 16:50, David Sinn wrote
Actually distributed BFD (not "it's all running on one line card because
> customers like LACP bundles spread between line cards and that's really
> hard to distribute reliably), solved.
>
Isn't the solution here the same? Have all LACP member port
On Fri, 6 Dec 2024 at 05:30, Mark Tinka wrote:
> I ran Ethernet to every room, some of it using STP through conduits crossing
> the roof to get across one end of the house to the other. It helped me avoid
> wireless extenders and meshing technologies.
In the EU at least you cannot do that, you
I wish this would have good outcomes, but almost no customers use
advanced features, which cost money to develop and maintain.
Likely by voting with your feet, support expensive customers aggregate
to feature full companies, and support cheap customers aggregate to
feature empty companies, creatin
On Mon, 21 Oct 2024 at 20:34, John Schiel wrote:
> 1) May not work over wireless LAN devices?
I guess it depends on wireless technology, but 802.11xyzzy comes with
an encryption solution already so isn't really a target of interest.
> 2) Needs a centralized key server.
Not really, impl
On Sat, 12 Oct 2024 at 18:00, Tom Beecher wrote:
> I disagree with the premise here. I never said I 'commonly need to remind
> Juniper' about anything in relation to software updates. I was simply stating
> to the OP that if he had a support contract, and he's getting the runaround
> on access
On Fri, 11 Oct 2024 at 23:02, Tom Beecher wrote:
> Just standard contract law is all I was referring too.
More specifically, were you referring to the support contract Juniper
wrote? What is the applicable part in the contract that you commonly
need to remind Juniper about and helps you in procu
On Fri, 11 Oct 2024 at 16:36, Tom Beecher wrote:
> If you purchased a support contract with the switch, they are legally
> required to provide you access to software updates. You may wish to remind
> them of that fact.
Not disputing, just curious. I assume you are talking about federal
law in
On Thu, 3 Oct 2024 at 07:04, Jeff Behrns via NANOG wrote
> This seems like a total misuse of the RFC framework / process and more a grab
> at publicity, but I'll play along...bogon. You should include the term
> "bogon". Someday when I'm done keeping actual production networks alive, I
> may
On Wed, 7 Aug 2024 at 20:05, Christopher Morrow wrote:
> I'd bet the real answer is that someone wants to connect a commodity
> server to an IX and pretend to be
> some network/asn and then do some not terrific things with that setup :(
>
> seen this in AMSIX and DECIX ... don't know that I've no
On Wed, 7 Aug 2024 at 17:41, Brandon Martin wrote:
> Among the other reasons folks have given, the 10GBASE-T PHY has added
> latency beyond the basic packetization/serialization delay inherent to
> Ethernet due to the use of a relatively long line code plus LDPC. It's
> not much (2-4us which is
I can't help you, but I'm just awfully curious and must ask, why
specifically optical ports? Seems very strange and a limiting
requirement for upside that my imagination struggles to find.
On Tue, 6 Aug 2024 at 21:51, Walt wrote:
>
> Asking for a friend, please contact me off list.
>
>
>
> The as
I don't think that URL explains how commonly it is used.
In my experience TCP-AO use is extremely limited, partly because it's
super new in practice. Juniper had it for a long time, but it was
pre-standard even years after the standard was published, which
probably didn't matter much, as no one el
This threat is interesting to me, but I'm surprised how no
requirements or use-cases are mentioned.
Like what is OP trying to do?
Looking at some of the proposals, it's obvious some of them are
intended for use cases where one side is an external party with email,
and one side is an internal part
On Sat, 18 May 2024 at 10:38, Bill Woodcock wrote:
> So, yes, I think having an open peering policy should be a requirement for
> operating a root nameserver. I don’t think there’s any defensible rationale
> that would support root nameservers being a private benefit to be used to
> worsen th
On Sat, 18 May 2024 at 01:07, William Herrin wrote:
> I don't understand why Cogent is allowed to operate one of the root
> servers. Doesn't ICANN do any kind of technical background check on
> companies when letting the contract?
>
> For those who haven't been around long enough, this isn't Coge
On Fri, 26 Apr 2024 at 19:43, Warren Kumari wrote:
> I've been on the same quest, and I have some additional requests / features.
> Ideally it:
>
> 1: would be small - my particular use-case is for a "traveling rack", and so
> 0U is preferred.
> 2: would be fairly cheap.
> 3: would not be a Ras
On Fri, 26 Apr 2024 at 19:43, Warren Kumari wrote:
>> Curious if anyone has particular hardware they like for OOB / serial
>> management, similar to OpenGear, but preferably with 5G support, maybe even
>> T-Mobile support? It’s becoming increasingly difficult to get static IP 4g
>> machine acc
On Fri, 26 Apr 2024 at 03:11, David H wrote:
> Curious if anyone has particular hardware they like for OOB / serial
> management, similar to OpenGear, but preferably with 5G support, maybe even
> T-Mobile support? It’s becoming increasingly difficult to get static IP 4g
> machine accounts out
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 vs
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 ma
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 haul has a t
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
> comp
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 E
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, th
On Fri, 29 Mar 2024 at 20:10, Steven Bakker wrote:
> To top it off, both the sFlow and IPFIX specs are sufficiently vague about
> the meaning of the "frame size", so vendors can implement whatever they want
> (include/exclude padding, include/exclude FCS). This implies that you
> shouldn't tru
On Fri, 29 Mar 2024 at 02:15, Nick Hilliard wrote:
> Overall, sflow has one major advantage over netflow/ipfix, namely that
> it's a stateless sampling mechanism. Once you have hardware that can
> Obviously, not all netflow/ipfix implementations implement flow state,
> but most do; some impleme
On Thu, 28 Mar 2024 at 20:36, Peter Phaal wrote:
> The documentation for IOS-XR suggests that enabling extended-router in the
> sFlow configuration should export "Autonomous system path to the
> destination", at least on the 8000 series routers:
> https://www.cisco.com/c/en/us/td/docs/iosxr/cis
Hey,
On Thu, 28 Mar 2024 at 17:49, Peter Phaal wrote:
> sFlow was mentioned because I believe Brian's routers support the feature and
> may well export the as-path data directly via sFlow (I am not aware that it
> is a feature widely supported in vendor NetFlow/IPFIX implementations?).
Export
On Wed, 27 Mar 2024 at 21:02, Peter Phaal wrote:
> Brian, you may want to see if your routers support sFlow (vendors have added
> the feature over the last few years).
Why is this a solution, what does it solve for OP? Why is it
meaningful what the wire-format of the records are? I read OP's
qu
On Wed, 6 Mar 2024 at 22:57, michael brooks - ESC
wrote:
> Funny you should mention this now, we were just discussing (more like
> lamenting...) if support is a dying industry. It seems as though vendor
> budgets are shrinking to the point they only have a Sales/Pre-Sales
> department, and fro
On Fri, 23 Feb 2024 at 19:42, 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 busine
On Fri, 26 Jan 2024 at 10:23, Phil Lavin via NANOG wrote:
> 88.99.88.67 to 216.147.3.209:
> Host Loss% Snt Last Avg
> Best Wrst StDev
> 1. 10.88.10.254 0.0% 1760.2 0.1
> 0.1 0.3 0.1
> 7.
On Wed, 17 Jan 2024 at 03:18, wrote:
> Others have pointed to references, I found some others, it's all
> pretty boring but perhaps one should embrace the general point that
> some equipment may not like abrupt temperature changes.
Can you share them? Only one I've found is:
https://www.ashrae.o
On Tue, 16 Jan 2024 at 12:22, Nathan Ward wrote:
> Here’s some manufacturer specs:
> https://www.dell.com/support/manuals/en-nz/poweredge-r6515/per6515_ts_pub/environmental-specifications?guid=guid-debd273c-0dc8-40d8-abbc-be059a0ce59c&lang=en-us
>
> 3rd section, “Maximum temperature gradient”.
T
On Tue, 16 Jan 2024 at 11:00, William Herrin wrote:
> You have a computer room humidified to 40% and you inject cold air
> below the dew point. The surfaces in the room will get wet.
I think humidity and condensation is well understood and indeed
documented but by NEBS and vendors as verboten.
On Tue, 16 Jan 2024 at 08:51, wrote:
> A rule of thumb is a few degrees per hour change but YMMV, depends on
> the equipment. Sometimes manufacturer's specs include this.
Is this common sense, or do you have reference to this, like paper
showing at what temperature change at what rate occurs wha
On Mon, 15 Jan 2024 at 21:08, Michael Thomas wrote:
> An ipv4 free network would be nice, but is hardly needed. There will
> always be a long tail of ipv4 and so what? You deal with it at your
I mean Internet free DFZ, so that everyone is not forced to maintain
two stacks at extra cost, fragilit
On Mon, 15 Jan 2024 at 10:59, jordi.palet--- via NANOG wrote:
> No, I’m not saying that. I’m saying "in actual deployments", which doesn’t
> mean that everyone is deploying, we are missing many ISPs, we are missing
> many enterprises.
Because of low entropy of A-B pairs in bps volume, seeing m
On Mon, 15 Jan 2024 at 10:05, jordi.palet--- via NANOG wrote:
> In actual customer deployments I see the same levels, even up to 85% of IPv6
> traffic. It basically depends on the usage of the caches and the % of
> residential vs corporate customers.
You think you are contributing to the IPv6
On Mon, 15 Jan 2024 at 06:18, Forrest Christian (List Account) <
li...@packetflux.com> wrote:
If 50٪ of the servers and 50% of the clients can do IPv6, the amount of
> IPv6 traffic will be around 25% since both ends have to do IPv6.
>
This assumes cosmological principle applies to the Internet, b
On Thu, 11 Jan 2024 at 12:57, Christopher Hawker wrote:
> Reclassifying this space, would add 10+ years onto the free pool for each
> RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of
> a /8 pool available for delegation, another 1/6th reserved. Reclassification
> w
On Wed, 3 Jan 2024 at 01:05, Mike Hammett wrote:
> It suggests that 60 meg is what you need at 10G. Is that per interface? Would
> it be linear in that I would need 600 meg at 100G?
Not at all.
You need to understand WHY buffering is needed, to determine how much
you want to offer buffering.
On Mon, 27 Nov 2023 at 21:45, Josh Luthman
wrote:
Can you have an ethernet switch with dying gasp?
> Our ONTs (Calix, PON) have it but I don't see how you'd do it with
> ethernet.
>
At least via efm-oam you can have a dying gasp.
You could probably add it to autonegotiation, by sending some sym
On Thu, 2 Nov 2023 at 10:32, Mark Andrews wrote:
> You missed the point I was trying to make. While I think that that source is
> trying to enumerate some part of the namespace. NS queries by themselves
> don’t indicate an attack. Others would probably see the series of NS queries
> as a sig
On Wed, 18 Oct 2023 at 17:39, Tom Beecher wrote:
> Auto-bandwidth won't help here if the bandwidth reduction is 'silent' as
> stated in the first message. A 1G interface , as far as RSVP is concerned, is
> a 1G interface, even if radio interference across it means it's effectively a
> 500M lin
On Mon, 16 Oct 2023 at 22:49, wrote:
> JTAC says we must disable a physical port to allocate BW for tunnel-services.
> Also leaving tunnel-services bandwidth unspecified is not possible on the
> 204. I haven't independently tested / validated in lab yet, but this is what
> they have told me.
On Tue, 17 Oct 2023 at 00:28, Delong.com wrote:
> The MX-204 appears to be an entirely fixed configuration chassis and looks
> from the literature like it is based on pre-trio chipset technology.
> Interesting that there are 100Gbe interfaces implemented with this seemingly
> older technology
Unfortunately not yet, as far as I know. Long time ago I gave this to
my account team
Title: Direct routes must support tag and or community
Platform: Trio, priority MX80, MPC2
JunOS: 12.4Rx
Command: 'set interfaxe ge-4/2.0 family inet address 10.42.42.1/24
tag|community X'
JTAC: n
On Thu, 5 Oct 2023 at 20:45, Niels Bakker wrote:
> The recommendation is to make Router-IDs globally unique. They're used
> in collision detection. What if you and a peer pick the same non
> globally unique address? Any session will never come up.
https://datatracker.ietf.org/doc/html/rfc6286
On Mon, 2 Oct 2023 at 20:21, Jeff Behrns via NANOG wrote:
> Encountered an issue with an MX204 using all 4x100G ports and a logical
> tunnel to hairpin a VRF. The tunnel started dropping packets around 8Gbps.
> I bumped up tunnel-services BW from 10G to 100G which made the problem
> worse; the t
On Sun, 1 Oct 2023 at 21:19, Matthew Petach wrote:
> Unfortunately, many coders today have not read Godel, Escher, Bach: An
> Eternal Golden Braid,
> and like the unfortunate Crab, consider their FIB compression algorithms to
> be unbreakable[0].
>
> In short: if you count on FIB compression wo
On Sun, 1 Oct 2023 at 06:07, Owen DeLong via NANOG wrote:
> Not sure why you think FIB compression is a risk or will be a mess. It’s a
> pretty straightforward task.
Also people falsely assume that the parts they don't know about, are
risk free and simple.
While in reality there are tons of pr
On Sat, 30 Sept 2023 at 09:42, Mark Tinka wrote:
> > But when everybody upgrades, memory and processor unit prices
> > decrease.. Vendors gain from demand.
> >
> I am yet to see that trend...
Indeed. If you look like 10k/10q for Juniper their business is fairly
stable in revenue and ports sold.
On Fri, 29 Sept 2023 at 23:43, William Herrin wrote:
> My understanding of Juniper's approach to the problem is that instead
> of employing TCAMs for next-hop lookup, they use general purpose CPUs
> operating on a radix tree, exactly as you would for an all-software
They use proprietary NPUs, wi
On Fri, 29 Sept 2023 at 08:24, William Herrin wrote:
> Maybe. That's where my comment about CPU cache starvation comes into
> play. I haven't delved into the Juniper line cards recently so I could
> easily be wrong, but if the number of routes being actively used
> pushes past the CPU data cache,
On Wed, 20 Sept 2023 at 19:06, Chris Boyd wrote:
> We run Teams Telephony in $DAYJOB, and it does use SILK.
>
> https://learn.microsoft.com/en-us/microsoftteams/platform/bots/calls-and-meetings/real-time-media-concepts
Looks like codecs still are rapidly evolving in walled gardens. I just
learne
On Wed, 20 Sept 2023 at 03:15, Dave Taht wrote:
> I go back many, many years as to baseline numbers for managing voip networks,
> including things like CISCO LLQ, diffserv, fqm prioritizing vlans, and running
> voip networks entirely separately... I worked on codecs, such as oslec, and
> early
On Sat, 9 Sept 2023 at 21:36, Benny Lyne Amorsen
wrote:
> The Linux TCP stack does not immediately start backing off when it
> encounters packet reordering. In the server world, packet-based
> round-robin is a fairly common interface bonding strategy, with the
> accompanying reordering, and gener
On Fri, 8 Sept 2023 at 09:17, Mark Tinka wrote:
> > Unfortunately that is not strict round-robin load balancing.
>
> Oh? What is it then, if it's not spraying successive packets across
> member links?
I believe the suggestion is that round-robin out-performs random
spray. Random spray is what th
On Thu, 7 Sept 2023 at 15:45, Benny Lyne Amorsen
wrote:
> Juniper's solution will cause way too much packet reordering for TCP to
> handle. I am arguing that strict round-robin load balancing will
> function better than hash-based in a lot of real-world
> scenarios.
And you will be wrong. Packet
On Thu, 7 Sept 2023 at 00:00, David Bass wrote:
> Per packet LB is one of those ideas that at a conceptual level are great, but
> in practice are obvious that they’re out of touch with reality. Kind of like
> the EIGRP protocol from Cisco and using the load, reliability, and MTU
> metrics.
T
On Wed, 6 Sept 2023 at 19:28, Mark Tinka wrote:
> Yes, this has been my understanding of, specifically, Juniper's
> forwarding complex.
Correct, packet is sprayed to some PPE, and PPEs do not run in
deterministic time, after PPEs there is reorder block that restores
flow, if it has to.
EZchip is
On Wed, 6 Sept 2023 at 17:10, Benny Lyne Amorsen
wrote:
> TCP looks quite different in 2023 than it did in 1998. It should handle
> packet reordering quite gracefully; in the best case the NIC will
I think the opposite is true, TCP was designed to be order agnostic.
But everyone uses cubic, and
On Wed, 6 Sept 2023 at 10:27, Mark Tinka wrote:
> I recognize what happens in the real world, not in the lab or text books.
Fun fact about the real world, devices do not internally guarantee
order. That is, even if you have identical latency links, 0
congestion, order is not guaranteed between p
On Fri, 1 Sept 2023 at 22:56, Mark Tinka wrote:
> PTX1000/10001 (Express) offers no real configurable options for load
> balancing the same way MX (Trio) does. This is what took us by surprise.
What in particular are you missing?
As I explained, PTX/MX both allow for example speculating on tran
On Fri, 1 Sept 2023 at 18:37, Lukas Tribus wrote:
> On the hand a workaround at the edge at least for EoMPLS would be to
> enable control-word.
Juniper LSR can actually do heuristics on pseudowires with CW.
--
++ytti
On Fri, 1 Sept 2023 at 16:46, Mark Tinka wrote:
> Yes, this was our conclusion as well after moving our core to PTX1000/10001.
Personally I would recommend turning off LSR payload heuristics,
because there is no accurate way for LSR to tell what the label is
carrying, and wrong guess while rare
On Fri, 1 Sept 2023 at 14:54, Mark Tinka wrote:
> When we switched our P devices to PTX1000 and PTX10001, we've had
> surprisingly good performance of all manner of traffic across native
> IP/MPLS and 802.1AX links, even without explicitly configuring FAT for
> EoMPLS traffic.
PTX and MX as LSR
On Thu, 31 Aug 2023 at 23:56, Eric Kuhnke wrote:
> The best working theory that several people I know in the neteng community
> have come up with is because Cogent does not want to adversely impact all
> other customers on their router in some sites, where the site's upstreams and
> links to n
On Tue, 22 Aug 2023 at 03:30, Lyndon Nerenberg (VE7TFX/VE6BBM)
wrote:
> Because I've been writing yacc grammars for decades. I just wanted to
> see if someone had already done it, as that would save me some time.
> But if there's nothing out there I'll just roll one myself.
I sympathise with yo
Does anyone have a traceroute path example where transit responds with
RFC5837 EO?
https://github.com/8enet/traceroute/blob/master/traceroute/extension.c#L101
Output should be '2/x: '
At least JNPR seems to support this:
https://www.juniper.net/documentation/us/en/software/junos/transport-ip/top
This seems worse :)
'we are collecting data about you, but didn't bother thinking if it is needed'
On Fri, 16 Jun 2023 at 22:55, Livingood, Jason via NANOG
wrote:
>
> In the meantime please just select some unrelated industry on the form. We
> don’t care – it seems to be boilerplate.
>
>
>
> Fr
I can't tell what large is. But I've worked for enterprise ISP and
consumer ISPs, and none of the shops I worked for had capability to
monetise information they had. And the information they had was
increasingly low resolution. Infraprovider are notoriously bad even
monetising their infra.
I'm sur
On Fri, 21 Apr 2023 at 20:44, Jason Healy via NANOG wrote:
> This is not intended as snark: what do people recommend for IPv6? I try to
> maintain forward/reverse for all my server/infrastructure equipment. But
> clients? They're making up temporary addresses all day long. So far, I've
>
On Wed, 22 Mar 2023 at 16:04, Alexander Huynh via NANOG wrote:
> I'll take this feedback to our developers.
Many thanks.
> I took a look at the above tickets, and it seems that one of the egress
> ranges from that datacenter cannot connect to the authoritative
> nameservers of `www.moi.gov.cy`:
perati...@lists.dns-oarc.net for someone at CloudFlare.
>
> For what it's worth, it works for me. I'm in Troy, OH.
>
> C:\Users\jluthman>dig www.moi.gov.cy @1.1.1.1 +short
> 212.31.118.26
>
>
> On Wed, Mar 22, 2023 at 9:43 AM Saku Ytti wrote:
>>
>>
On Wed, 22 Mar 2023 at 15:26, Matt Harris wrote:
> When something is provided at no cost, I don't see how it can be unethical
> unless they are explicitly lying about the ways in which they use the data
> they gather.
> Ultimately, you're asking them to provide a costly service (support for
> en
i.gov.cy. 3600 IN NS ns01.gov.cy.
> moi.gov.cy. 3600 IN NS ns02.gov.cy.
>
> ;; ADDITIONAL SECTION:
> ns02.gov.cy. 86400 IN A 212.31.118.20
> ns01.gov.cy. 86400 IN A 212.31.118.19
>
> ;; Query time: 374 msec
> ;; SERVER: 212.31.118.19#53(212.31.118.19) (UDP)
> ;; WHEN: We
Am I correct to understand that 1.1.1.1 only does support via community forum?
They had just enough interest in the service to collect user data to
monetise, but 0 interest in trying to figure out how to detect and
solve problems?
Why not build a web form where they ask you to explain what is not
On Mon, 27 Feb 2023 at 10:16, Rolf Winter wrote:
> "https://downforeveryoneorjustme.com/";. But, somebody might use your
> server for this. How do people feel about this? Restrict the reverse
> traceroute operation to be done back to the source or allow it more
> freely to go anywhere?
What are
╰─ dig NS intuit.com|grep ^intuit|ruby -nae 'puts $F[-1]'|while read dns;do
echo $dns:;dig smartlinks.intuit.com @$dns|grep CNAME
done
a7-66.akam.net.:
smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
a11-64.akam.net.:
smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.co
On Sun, 5 Feb 2023 at 07:50, Chris Adams wrote:
> Electric heat pumps are great for power efficiency until the temperature
> drops and they switch over to pure electric heat.
Here is graph from popular air heat pump Mitsubishi MSZ/MUZ 25
https://scanoffice.fi/wp-content/uploads/2022/09/rw-vtt-tu
On Fri, 3 Feb 2023 at 16:15, Israel G. Lugo wrote:
> Could anyone with last mile experience help with some ballpark figures?
> I.e. 15 min vs 8h or 8 days.
This would be highly market specific. In many cases, probably most
cases, there is no regulatory requirement for availability for
internet s
On Sat, 28 Jan 2023 at 08:48, Mark Tinka wrote:
> Apparently, the shortage of chips for the MX204 and MPC7E is now resolved,
> and there is no longer any need to force customers to move to the MX304.
There is still just Micron for HMC, and as far as I can find, they've
not revoked their EOL. Yo
On Thu, 22 Dec 2022 at 08:41, William Herrin wrote:
> Suppose you have a loose network cable between your Linux server and a
> switch. Layer 1. That RJ45 just isn't quite solid. It's mostly working
> but not quite right. What does it look like at layer 2? One thing it
> can look like is a periodi
There certainly aren't any temporal buffers in SP gear limiting the
buffer to 100ms, nor are there any mechanisms to temporally decrease
TTL or hop-limit. Some devices may expose temporal configuration to
UX, but that is just a multiplier for max_buffer_bytes, and what is
programmed is a fixed amou
On Fri, 9 Dec 2022 at 20:19, t...@pelican.org wrote:
Hey Tim,
> Or at least, you've moved the problem from "generate config" to "have
> complete and correct data". Which statement should probably come with some
> kind of trigger-warning...
I think it's a lot easier than you think. I understa
On Fri, 9 Dec 2022 at 17:58, Joshua Miller wrote:
> In terms of structured vs unstructured data, sure, assembling text is not a
> huge lift. Though, when you're talking about layering on complex use cases,
> then it gets more complicated. Especially if you want to compute the inverse
> config
On Fri, 9 Dec 2022 at 17:30, Tom Beecher wrote:
> Pushing thousands of lines via CLI/expect automation is def not a great idea,
> no. Putting everything into a file, copying that to the device, and loading
> from there is generally best regardless. The slowness you refer to is almost
> certain
On Fri, 9 Dec 2022 at 17:07, Joshua Miller wrote:
> I don't know that Netconf or gRPC are any faster than loading cli. Those
> protocols facilitate automation so that the time it takes to load any one
> device is not a significant factor, especially when you can roll out changes
> to devices i
Can Andrian and Joshua explain what they specifically mean, and how
they expect it to perform over what Steffann is already doing (e.g.
load https://nms/cfg/router.txt)? How much faster will it be, and why?
Can Steffan explain how large a file they are copying, over what
protocol, how long does it
1 - 100 of 890 matches
Mail list logo
