Ultimately, I think every vendor will have customers with good
experiences, and customers with not-so-good experiences. Without
sufficient data, it is hard to say which vendor, in general, does a good
job for their customer base re: TAC.
What I will say, albeit anecdotally also, is that TAC
On 10/25/23 01:56, Neader, Brent wrote:
Hello!
Interested in getting the larger community’s thought on this.
The primary question being does XGS-PON have a place in providing a
dedicated enterprise level service (at least sold as one) in the
marketplace? Delivered via a residential (per
On 10/21/23 16:03, Amir Herzberg wrote:
Hi Owen, Randy, Job and other NANOGers,
I surely agree with you all that we shouldn't expect discarding of
ROA-unknown `anytime soon' (or ever?). But I have a question: what
about discarding ROA-unknowns for very large prefixes (say, /12), or
for
On 10/19/23 22:24, Chad Lamb via NANOG wrote:
XKL is still here ...
Some caveats on 400G ZR/ZR+ devices:
- They are power hungry, cooling is a challenge. 800G even more so.
The OSFP package for 800G looks like the better choice than QSFP-DD
for this reason. We'll see, we need more
On 10/17/23 03:20, Ryan Kozak wrote:
"The MX204 router supports two inline tunnels - one per PIC. To
configure the tunnel interfaces, include the tunnel-services statement
and an optional bandwidth of 1 Gbps through 200 Gbps at the \[edit
chassis fpc fpc-slot pic number\] hierarchy
On 10/16/23 21:49, Jeff Behrns via NANOG wrote:
Also leaving tunnel-services bandwidth unspecified is not possible on the 204.
This is true of other MX platforms as well, unless I misunderstand.
Mark.
questions or concerns should be addressed to the Programme Committee
Chairs by e-mail at:
pc-chairs at apricot.net
We look forward to receiving your presentation proposals.
Mark Tinka, Achie Atienza & Mark Duffell
APRICOT 2024 Programme Committee Chairs
--
On 10/11/23 04:34, Dobbins, Roland via NANOG wrote:
To clarify, Sightline has supported virtualization for many years, FYI.
It does do, yes. But pricing for the software license is not too far off
from if you chose to buy Netscout's own hardware.
Not a major drama for me - I appreciate
Finally, the name came to me :-):
https://www.xkl.com/
Looks like they are still in business.
Mark.
On 10/6/23 16:02, Mark Tinka wrote:
On 10/6/23 15:52, Dave Bell wrote:
Smartoptics?
https://smartoptics.com/
Not them.
I want to say they had an "X" in their name, but memor
On 10/7/23 14:32, Willy Manga wrote:
How about we educate each other to not assume you must deaggregate
your prefix especially with IPv6?
I see 'some' (it's highly relative) networks on IPv4, they 'believe'
they have to advertise every single /24 they have. And when they start
with IPv6,
On 10/6/23 15:53, Dave Cohen wrote:
My experience is primarily with the traditional carrier-grade folks
like Ciena, Infinera, etc. but over the last decade all of those
vendors have focused on improving how they scale down without
sacrificing (most of the) quality and functionality - to
On 10/6/23 15:52, Dave Bell wrote:
Smartoptics?
https://smartoptics.com/
Not them.
I want to say they had an "X" in their name, but memory is fuzzy.
Mark.
On 10/6/23 15:07, Mike Hammett wrote:
I've been using various forms of passive WDM for years. I have a couple
different projects on my plate that require me to look at the next level of
platform.
In some projects, I'll be looking for needing to have someone long distances of
glass
nd a brief description about why
you would make a good addition to the PC.
The PC Chairs will accept nominations received by 17:00 UTC+8 on Friday
20th October 2023, and will announce the new PC shortly thereafter.
Many thanks!
Mark Tinka & Mark Duffell
For the APRICOT 2024 Organising Committee
--
On 10/5/23 08:32, Geoff Huston wrote:
Not really.
The stability of number in IPv4 as compared to the monotonic rise in IPv6 is
what I find to be curious.
I think the fact that RIR's allocate very large IPv6 address space to
their members may well be what is driving this.
Historically,
On 10/5/23 08:24, Geoff Huston wrote:
The IPv6 FIB is under the same pressure from more specifics. Its taken
20 years to get there, but the IPv6 FIB is now looking stable at 60%
opf the total FIB size [2]. For me, thats a very surprising outcome in
an essentially unmanaged system.
Were
On 10/5/23 07:49, Crist Clark wrote:
But if the assumption is that networks will always eventually totally
deaggregate to the maximum, we're screwed. Routing IPv4 /32s would be
nothing. The current practice of accepting /48s could swell to about
2^(48 - 3) = 2^45 = 35184372088832.
What
On 10/4/23 09:27, Elmar K. Bins wrote:
Justin,
I'm not sure you're not confusing scope here.
Everybody and their sister accept smaller blocks from their customers; we're
all talking about the DFZ here, not customer routes that you aggregate.
Actually, we don't.
From our customers, the
On 10/4/23 12:11, Musa Stephen Honlue wrote:
Which one is easier,
1. Convincing the tens of thousands of network operators and
equipment vendors to modify configs and code to accept more specifics
than /24, or
Equipment vendors can already support 10 million entries in FIB. They
just
On 10/2/23 22:59, Matthew Petach wrote:
Huh?
In all my decades of time in the network industry, I have never seen a
case where a smaller transit contract had lower per mbit cost than a
larger volume contract.
I would expect that HE would make *more* money off 10 smaller customer
On 10/2/23 20:44, Tim Franklin wrote:
Had NOT considered the looping - that's what you get for writing in
public without thinking it all the way through *blush*.
Thanks for poking holes appropriately,
Like I said, it's going to be a messy experiment - for probably a
decade, at least.
On 10/2/23 20:58, Tim Burke wrote:
Hurricane has been doing the same thing lately... but their schtick is to say that
"we are seeing a significant amount of hops in your AS path and wanted to know if
you are open to resolve this issue".
I get what HE are trying to do here, as I am sure
On 9/30/23 01:36, William Herrin wrote:
If I were designing the product, I'd size the SRAM with that in mind.
I'd also keep two full copies of the FIB in the outer DRAM so that the
PPEs could locklessly access the active one while the standby one gets
updated with changes from the RIB. But
On 9/29/23 22:56, William Herrin wrote:
Actually, BGP can swing that. Routing involves two distinct
components: the routing information base (RIB) and the forwarding
information base (FIB). BGP is part of the RIB portion of that
process. It's always implemented in software (no hardware
On 9/29/23 06:43, VOLKAN SALİH wrote:
But when everybody upgrades, memory and processor unit prices
decrease.. Vendors gain from demand.
I am yet to see that trend...
Mark.
On 9/28/23 23:25, VOLKAN SALİH wrote:
hello,
I believe, ISPs should also allow ipv4 prefixes with length between
/25-/27 instead of limiting maximum length to /24..
I also believe that RIRs and LIRs should allocate /27s which has 32
IPv4 address. considering IPv4 world is now mostly
On 9/20/23 17:39, Jeff Moore wrote:
We have also used https://www.shrubbery.net/tac_plus/ for some time as
well. Great product!
Yes, that's one of the ones in the FreeBSD ports.
Works very well.
Mark.
On 9/20/23 17:09, Bryan Holloway wrote:
Ah, the good old days when I could download the latest tac_plus code
from the Cisco FTP site, compile it, and off I go.
But I digress.
Curious if there are any operators out there that have a good
recommendation on a lightweight TACACS+ server for
On 9/19/23 18:05, Mike Hammett wrote:
Some of it is scale-related. Someone's operating just fine at the size
they are, but the next order of magnitude larger enjoys many benefits
from that size, but it takes either A) luck or B) the right skills to
be able to move up to get those benefits.
On 9/19/23 17:54, Mike Hammett wrote:
Well sure, and I would like to think (probably mistakenly) that just
no one important enough (to the money people) made the money people
that these other things are *REQUIRED* to make the deal work.
Obviously, people lower on the ladder say it all of
On 9/19/23 17:40, Anne Mitchell wrote:
And sometimes the acquisition is really just about acquiring the assets, such
as the customer list*, and then they are left with having to run something that
they never really wanted until they can figure out what to do with it.
Right, buying the
On 9/19/23 16:48, Mike Hammett wrote:
As someone that has been planning to be in the acquiring seat for a
while (but yet to do one), I've consistently passed to the money
people that there's the purchase price and then there's the % on top
of that for equipment, contractors, etc. to
On 9/19/23 16:41, Matthew Petach wrote:
c) your executives have promised there will be cost savings after the
merger due to "synergies" between the two companies.
Couldn't have said the exact same words any better myself - "cost
savings from synergies" :-).
Always interesting when a year
On 9/19/23 14:19, Mike Hammett wrote:
I've never understood companies that acquire and don't completely
integrate as quickly as they can.
Sometimes it does not add any material value to either network.
Sometimes it takes too long.
If the acquired company is orders of magnitude smaller
On 9/9/23 22:29, Dave Cohen wrote:
At a previous $dayjob at a Tier 1, we would only support LAG for a
customer L2/3 service if the ports were on the same card. The response
we gave if customers pushed back was "we don't consider LAG a form of
circuit protection, so we're not going to
On 9/9/23 20:44, Randy Bush wrote:
i am going to be foolish and comment, as i have not seen this raised
if i am running a lag, i can not resist adding a bit of resilience by
having it spread across line cards.
surprise! line cards from vendor do not have uniform hashing
or rotating
On 9/7/23 09:51, Saku Ytti wrote:
Perhaps if congestion control used latency or FEC instead of loss, we
could tolerate reordering while not underperforming under loss, but
I'm sure in decades following that decision we'd learn new ways how we
don't understand any of this.
Isn't this partly
On 9/7/23 09:31, Benny Lyne Amorsen 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 do not
know about any equipment that offers actual round-robin
load-balancing.
Cisco had both
On 9/6/23 18:52, Tom Beecher wrote:
Well, not exactly the same thing. (But it's my mistake, I was
referring to L3 balancing, not L2 interface stuff.)
Fair enough.
load-balance per-packet will cause massive reordering, because it's
random spray , caring about nothing except equal loading
On 9/6/23 12:01, Saku Ytti wrote:
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 packet1 coming from
interfaceI1 and packet2 coming from interfaceI2, which packet first
On 9/6/23 11:20, 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
reassemble the out-of-order TCP packets into a 64k packet and the OS
will never even know they were reordered.
On 9/6/23 17:27, Tom Beecher wrote:
At least on MX, what Juniper calls 'per-packet' is really 'per-flow'.
Unless you specifically configure true "per-packet" on your LAG:
set interfaces ae2 aggregated-ether-options load-balance per-packet
I ran per-packet on a Juniper LAG 10 years
On 9/6/23 16:14, Saku Ytti wrote:
For example Juniper offers true per-packet, I think mostly used in
high performance computing.
Cisco did it too with CEF supporting "ip load-sharing per-packet" at the
interface level.
I am not sure this is still supported on modern code/boxes.
Mark.
On 9/6/23 09:12, Masataka Ohta wrote:
you now recognize that per-flow load balancing is not a very
good idea.
You keep moving the goal posts. Stay on-topic.
I was asking you to clarify your post as to whether you were speaking of
per-flow or per-packet load balancing. You did not do
On 9/4/23 13:27, Nick Hilliard wrote:
this is an excellent example of what we're not talking about in this
thread.
It is amusing how he tried to pivot the discussion. Nobody was talking
about how lane transport in optical modules works.
Mark.
On 9/4/23 13:04, Masataka Ohta wrote:
Are you saying you thought a 100G Ethernet link actually consisting
of 4 parallel 25G links, which is an example of "equal speed multi
parallel point to point links", were relying on hashing?
No... you are saying that.
Mark.
On 9/3/23 15:01, Masataka Ohta wrote:
Why, do you think, you can rely on existence of flows?
You have not quite answered my question - but I will assume you are in
favour of per-packet load balancing.
I have deployed per-packet load balancing before, ironically, trying to
deal with
On 9/3/23 15:01, Masataka Ohta wrote:
Why, do you think, you can rely on existence of flows?
You have not quite answered my question - but I will assume you are in
favour of per-packet load balancing.
I have deployed per-packet load balancing before, ironically, trying to
deal with
On 9/3/23 09:59, Masataka Ohta wrote:
If you have multiple parallel links over which many slow
TCP connections are running, which should be your assumption,
the proper thing to do is to use the links with round robin
fashion without hashing. Without buffer bloat, packet
reordering
On 9/2/23 17:38, Masataka Ohta wrote:
Wrong. It can be performed only at the edges by policing total
incoming traffic without detecting flows.
I am not talking about policing in the core, I am talking about
detection in the core.
Policing at the edge is pretty standard. You can police a
On 9/2/23 17:04, Masataka Ohta wrote:
Both of you are totally wrong, because the proper thing to do
here is to police, if *ANY*, based on total traffic without
detecting any flow.
I don't think it's as much an issue of flow detection as it is the
core's ability to balance the Layer 2
On 9/2/23 08:43, Saku Ytti wrote:
What in particular are you missing?
As I explained, PTX/MX both allow for example speculating on transit
pseudowires having CW on them. Which is non-default and requires
'zero-control-word'. You should be looking at 'hash-key' on PTX and
'enhanced-hash-key'
On 9/1/23 21:52, Mike Hammett wrote:
It doesn't help the OP at all, but this is why (thus far, anyway), I
overwhelmingly prefer wavelength transport to anything switched. Can't
have over-subscription or congestion issues on a wavelength.
Large IP/MPLS operators insist on optical transport
On 9/1/23 15:55, Saku Ytti wrote:
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 will be extremely hard to root
cause, because you will never hear it, because the person
On 9/1/23 15:59, Mike Hammett wrote:
I wouldn't call 50 megabit/s an elephant flow
Fair point.
Mark.
On 9/1/23 15:44, Mike Hammett wrote:
and I would say the OP wasn't even about elephant flows, just about a
network that can't deliver anything acceptable.
Unless Cogent are not trying to accept (and by extension, may not be
able to guarantee) large Ethernet flows because they can't balance
On 9/1/23 15:29, Saku Ytti wrote:
PTX and MX as LSR look inside pseudowire to see if it's IP (dangerous
guess to make for LSR), CSR/ASR9k does not. So PTX and MX LSR will
balance your pseudowire even without FAT.
Yes, this was our conclusion as well after moving our core to PTX1000/10001.
On 9/1/23 10:50, Saku Ytti wrote:
It is a very plausible theory, and everyone has this problem to a
lesser or greater degree. There was a time when edge interfaces were
much lower capacity than backbone interfaces, but I don't think that
time will ever come back. So this problem is systemic.
On 8/30/23 18:56, michael brooks - ESC wrote:
I, too, am looking for something sexy (explained below). But can you
explain why you think AS_PATH is "useless," Mark?
Because most network operators use LOCAL_PREF heavily, and no amount of
AS_PATH prepending will be able fight that with any
On 8/28/23 07:55, Daniel Marks wrote:
(Enterprise AS for context)
This hasn’t been my experience in the US, however we mostly deal in
tier 2 markets (I.e. Detroit, Miami, Dallas, etc…) and we have plenty
of 40G private interconnects. I don’t doubt 40G is going away, I’ve
just never had
On 8/28/23 03:05, Mike Hammett wrote:
Well, or they simply found a potential deal on hardware that came with
40 gig ports. 40 gigs is still a lot of bits to a lot of people.
For internal use, sure.
But when connecting to another AS, the chances of them supporting 40Gbps
in one or more
On 8/27/23 04:52, Eric Kuhnke wrote:
I sincerely doubt there is much demand for *new* 40G these days.
Look at the population of 40G members on major IXes.
People have either one 10G, 2 x 10G, or 100G.
40G was a dead-end 9 years ago and much so more now.
We have customers that sometimes
On 8/26/23 00:54, Tom Beecher wrote:
It would, sure. Instead of storing a single prefix/next-hop with flags
in memory, you now have to store every prefix/next-hop that you are
announcing as well.
Indeed.
But it has been worth it. The load balancing from PE-to-PE has been
fantastic,
On 8/25/23 19:16, Tom Beecher wrote:
In my experience and testing with them, you have a decent bit of
headroom past the published RIB/FIB limits before they'll fall over.
They are holding up pretty well for us, mainly because we do a lot more
BGP on MX480's than on MX204's. We use the
On 8/23/23 17:14, Matt Erculiani wrote:
Does Fusion not make sense in this case? I've not had a ton of
experience with it, but it does well to add a crazy port count to an
otherwise very port limited device.
In small edge PoP's, we attach an Arista 1U switch with tons of 1/10Gbps
ports
On 8/25/23 09:41, Tarko Tikan wrote:
AFAIK this reflects the reality very well. There are huge PBB
deployments in very large networks but the overall number of networks,
using PBB, is very low. Even in those networks PBB is/will be phased
out so don't expect any new deployments. It is
On 8/23/23 18:29, t...@pelican.org wrote:
Not Trio, and different PLM :)
Yes, aware... I was just speaking in general for what is likely to be a
very popular platform :-).
MX304 (well, strictly LMIC16) has the same restriction, and a need for another entry in the
magic port checker
On 8/23/23 17:01, Tom Beecher wrote:
I'm not sure they allow oversubscription on anything in the MX line
anymore honestly. I could be wrong, I've been face down in a specific
subset of equipment for a while, someone please correct me if I am.
On the new ACX line, yes.
If I look at the
On 8/23/23 08:00, Pascal Masha wrote:
Thanks just wanted to know whether it was a supported feature.
What would have been nice is if Juniper oversubscribed the face plate of
this platform, as most people are more likely to run out of ports than
they would the 400Gbps forwarding capacity
On 8/22/23 16:46, Tom Beecher wrote:
Again, as it was stated, the size of or number of BGP communities
wasn't the problem anyway; it was hashing / memory storage. And you
know what? Hashing / memory storage HAS been a problem with multiple
vendors in many other contexts, not just BGP
On 8/21/23 17:44, Tom Beecher wrote:
So, while this all sounds good, without any specifics on vendor,
box, code, code revision number, fix, year it happened, current
status, e.t.c., I can't offer any meaningful engagement.
If you clicked Matt's link to the Google search, you
On 8/21/23 16:51, Ryan Hamel wrote:
Paschal,
It is not supported, nor is it recommended for redundancy in a routed
setup. Please describe your (desired) topology, that way the community
can discuss alternatives.
Sounds like the OP wants to build a chassis-based system out of
On 8/19/23 00:22, Matthew Petach wrote:
Hi Mark,
I know it's annoying that I won't mention specifics.
Unfortunately, the last time I mentioned $vendor-specific information
on NANOG, it was picked up by the press, and turned into a
multimillion dollar kerfuffle with me at the center of the
On 8/18/23 22:40, Matthew Petach wrote:
Hi Robert,
Without naming any names, I will note that at some point in the
not-too-distant past, I was part of a new-years-eve-holiday-escalation
to $BACKBONE_ROUTER_PROVIDER when the global network I was involved
with started seeing excessive
On 8/18/23 22:20, Jakob Heitz (jheitz) via NANOG wrote:
We support platforms of various capacities.
While we would all like to sell the large ones, people buy the cheap
ones too.
Even a bare bones x86 platform of some sort with at least 8GB of RAM
would make the cheapest routers still,
On 8/18/23 19:38, Jakob Heitz (jheitz) via NANOG wrote:
That's true Robert.
However, communities and med only work with neighbors.
Communities routinely get scrubbed because they cause increased memory
usage and convergence time in routers.
Really?
We only scrub a specific string of
On 8/18/23 09:38, Robert Raszuk wrote:
Jakob,
With AS-PATH prepend you have no control on the choice of which ASN
should do what action on your advertisements.
My comprehension of DPA would have been more directed than the "spray &
pray" approach AS_PATH prepending provides.
However,
On 8/18/23 09:38, Robert Raszuk wrote:
Jakob,
With AS-PATH prepend you have no control on the choice of which ASN
should do what action on your advertisements.
My comprehension of DPA would have been more directed than the "spray &
pray" approach AS_PATH prepending provides.
However,
On 8/17/23 21:43, Jakob Heitz (jheitz) via NANOG wrote:
"prepend as-path" has taken its place.
That pours water on my imaginary fire :-).
I was imagining something sexier, especially given how pretty "useless"
AS_PATH prepending is nowadays.
Mark.
On 8/16/23 16:16, michael brooks - ESC wrote:
Perhaps (probably) naively, it seems to me that DPA would have been a
useful BGP attribute. Can anyone shed light on why this RFC never
moved beyond draft status? I cannot find much information on this
other than IETF's data tracker
On 8/16/23 00:28, Nick Hilliard wrote:
Whatever about the web / winbox UI, there are some fairly serious
weaknesses in the cli and api:
1. there's no atomic configuration commit + auto rollback.
2. the CLI is non-idempotent, for example if you're in a list context
and issue the command
On 8/11/23 12:56, Nick Hilliard wrote:
bgp is a policy based distance vector protocol. If you can't adjust
the primary inter-domain metric to handle your policy requirements,
it's not much use.
I am not talking about appending one's own AS in the AS_PATH. I am
talking about appending
On 8/11/23 11:26, Nick Hilliard wrote:
If your asn is 327933, then:
add chain=foo prefix=192.0.2.0/24 action=accept set-bgp-prepend=2
... will produce: "327933 327933", and:
add chain=foo prefix=192.0.2.0/24 action=accept set-bgp-prepend-path=2
... will produce: "327933 2".
Routeros
On 8/11/23 11:08, Nick Hilliard wrote:
yep, sure did. Check out the "set-bgp-prepend" action on routeros -
it's right next to "set-bgp-prepend-path".
https://wiki.mikrotik.com/wiki/Manual:Routing/Routing_filters
So how would one fumble it to the degree where a fat-finger results in
On 8/11/23 10:15, b...@uu3.net wrote:
Haha :) you are right.
I just checked Caida AS ranking:
http://as-rank.uu3.net/?as=2
A lot of "providers" for UDEL-DCN. Yeah right..
They all indeed probably try to prepend their AS 2 times
ending up having ASN 2 in path.
Did I miss the memo where
On 8/11/23 05:17, Eric Kuhnke wrote:
Recently saw an aerial video where an entire neighborhood in Laihana
had burned down *except* for the concrete block structure small ILEC CO.
Pictures I have seen of other ILEC sites in Hawaii closely resemble
some GTE sites in the Pacific Northwest
On 8/10/23 20:43, Randy Bush wrote:
classic microtik prepend syntax confusion?
Uncertain. I have a Mikrotik CPE for my home router, but I can't tell
you how BGP works on it.
It seems that AS2, in the path, is not genuine. We are verifying that,
though.
Mark.
On 8/10/23 15:22, Frank Habicht wrote:
ouch!
I see in your LG that this AS 2 is originating 197.157.254.0/24 .
which seems to mean that it's not just a plain "we want to prepend 2
times, put the number 2 into config and the NOS takes this as the ASN
to insert"
putting someone from
On 8/10/23 12:01, d...@darwincosta.com wrote:
I know someone you might know them. Happy to introduce off-list.
Yes, Darwin. That would be most appreciated. Thanks.
Mark.
On 8/10/23 11:38, Frank Habicht wrote:
from a 2019 DB snapshot:
aut-num: AS327933
as-name: GROUPE-TELECOM-SPRL
descr: GROUPE TELECOM SPRL
status: ASSIGNED
org: ORG-GTS2-AFRINIC
admin-c: YM8-AFRINIC
tech-c: YM9-AFRINIC
notify:
Hi all.
Anyone know anything about this AS:
https://bgp.he.net/AS327933
Mark.
On 8/7/23 11:04, Giovane C. M. Moura via NANOG wrote:
TL;DR: I'd guess your NTP Server IP address is geolocated to
Mauritius. The Mauritius zone[0] on the pool has only one server, so
you'll only see this one. To fix it, use europe.pool.ntp.org (_do not_
use pool.ntp.org).
So the Anycast
On 8/5/23 21:26, Mel Beckman wrote:
Mark,
You might consider setting up your own GPS-based NTP network. Commercial
Ethernet GPS-sourced NTP servers, such as the Time Machines, TM1000A, are as
little as $400. Or you can roll your own using a Raspberry Pi or similar nano
computer with a
On 8/5/23 20:17, Chris Adams wrote:
It's the NTP pool people you need to talk to - the .freebsd. bit is just
a vendored entry into the pool (more for load tracking and management).
Yes, Andreas clarified in unicast. Will do. Thanks.
Mark.
On 8/5/23 19:51, Andreas Ott wrote:
See for yourself how his pool server scores at
https://www.ntppool.org/scores/197.224.66.40
I am not sure why it would be inserted into DNS answers for a
worldwide pool like 0.freebsd as it clearly does have connectivity
issues from some of the pool
On 8/5/23 18:30, Matthew McGehrin wrote:
Hi Mark.
Wouldn't a local server be more optimal?
IE:
server 0.nl.pool.ntp.org
server 1.nl.pool.ntp.org
server 2.nl.pool.ntp.org
server 3.nl.pool.ntp.org
I have a bunch of servers all over Europe I'd
Hi all.
I have NTP servers in Europe that are choosing Tata (6453) to get to
0.freebsd.pool.ntp.org which lives on 197.224.66.40:
traceroute -I 0.freebsd.pool.ntp.org
traceroute to 0.freebsd.pool.ntp.org (197.224.66.40), 64 hops max, 48
byte packets
1 ae-2-24.er-01-ams.nl.seacomnet.com
On 8/1/23 21:34, Mike Hammett wrote:
*nods* I know optical transport can be difficult to track down, but
they had admitted to a faulty card, then said they weren't going to do
anything because it hadn't faulted again.
Yeah, it's probably just being cheap. Well, kinda. I mean they've also
On 8/1/23 20:18, Mike Hammett wrote:
I have a wave transport vendor that suffered issues twice about ten
days apart, causing my link to flap a bunch. I put in a ticket on the
second set of occurrences. I was told that there was a card issue
identified and would be notified when the
On 8/1/23 20:37, Jared Mauch wrote:
Some providers have a much more disruptive layer-1 infrastructure and will ask
you to configure a 1s+ up timer. I think there’s an interesting question that
could go either way, do you want transport side faults to be exposed to you, or
should the
1 - 100 of 2549 matches
Mail list logo