On 10/1/24 19:38, Jared Mauch wrote:
As the market squeezes margins our tolerance for faults also narrows.
I think with the squeeze on margins getting tighter and tighter, all
manner of bad things will escalate.
Mark.
On 9/30/24 19:26, Udeme wrote:
Did you try https://www.mailop.org/?
I just took a look at the archives and don’t see any mention of a POC,
but it’s worth a try.
Thanks, Udeme.
Will give it a shot.
Mark.
Hi all.
If there is anyone from Zoom lurking, kindly reach out unicast.
Looking for someone who can help point me to a warm body about
authentication issues that seem like rocket science to fix.
All help appreciated.
Mark.
On 9/19/24 19:26, Sriram, Kotikalapudi (Fed) via NANOG wrote:
I know it makes sense for an AS to announce an aggregate less-specific prefix
to transit providers and peers without NO_EXPORT while announcing some
more-specific prefixes (subsumed under the aggregate) with NO_EXPORT towards
cu
On 8/8/24 03:37, William Herrin wrote:
Hi Eric,
All of these are excellent reasons why the DC -operator- should want
to use fiber in 10GE links.
The question was: why does a DC -customer- want 40 gigs of
specifically fiber optic connections in what is otherwise a minimum
server configurati
On 8/7/24 18:52, Saku Ytti wrote:
I think this is the least bad explanation, some explanations are that
copper may not be available, but that doesn't explain preference. Nor
do I think wattage/heat explains preference, as it's hosted, so
customers probably shouldn't care. Latency could very we
On 8/7/24 17:38, Elmar K. Bins wrote:
Which is really detrimental if you need to OOB connect a server. IPMI ports are
generally copper; I suppose that will change, but it hasn't yet.
Unless others have done it differently, what I used to do was run fibre
to whatever the local terminal serv
On 8/7/24 16:14, Bryan Holloway wrote:
Many of the big DCs don't do copper xconns anymore, so if you have a
server with optical NICs, you don't need a switch or media-converter.
If it's in-rack or in-cage (or even in-contiguous-row racks), most data
centres may permit your own copper x-co
On 8/7/24 08:01, Saku Ytti wrote:
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.
Many of the reasons I've heard for folk going optical for servers
On 7/23/24 16:15, Bryan Holloway wrote:
What irks me is that we have direct PNIs with -- without naming names
-- the "big guys" delivering this content, and yet the majority of
this traffic is coming over our public IX connections and transit.
Kinda defeats the purpose of a PNI ... anyone
On 7/20/24 14:08, Matt Corallo wrote:
Geosync is probably the highest unloaded latency, but add in a little
bufferbloat and you can easily get way more latency...I've definitely
seen a minute+ pings on a plane, which is almost all queuing. I assume
airplanes are not the only place with such
On 3/1/23 15:56, Jared Brown wrote:
On 2/28/23, Pascal Masha wrote:
How much will these cost?
ADVA said 4ish grand each. Probably less than five.
- Jared
So delayed again, as I understand it, due to challenges in achieving the
power class targets, especially for the high-power (0dB)
On 6/22/24 23:15, Michael Thomas wrote:
not exactly this list's main focus, but i suspect that lots of people
here's day job is to move these bits around as fast as possible once
they are being streamed.
https://www.theverge.com/2024/6/22/24171581/netflix-bet-advanced-encoding-anne-aaron
On 6/12/24 05:51, Mike Hammett wrote:
That doesn't even make any sense. IPv4 is a contended resource, but
IPv6 is not. They're already double-dipping by charging for the extra
BGP sessions.
Perhaps, is the issue that what customers are paying for is the ability
to have multiple BGP session
On 5/22/24 16:55, Scott Q. wrote:
Hi Mark,
thank you for the very informative post! In the meantime, our own
provider moved some routes from GTT to...Cogent and the times
decreased within the normal range. Also a few VPS providers such as
EdgeNext are using NTT & Cogent and show no issues
On 5/22/24 14:44, Paul Rolland wrote:
Yep, it hurts :(
1. Gi0-3.rtr-01.PAR.witbe.net0.0% 1790.3 0.3 0.2 10.4 0.7
2. 193.251.248.210.0% 1793.3 1.3 0.8 19.1 2.1
3. bundle-ether305.partr2.saint-den 6.7% 179 87.1 4.5 1.1 156.7
On 5/21/24 21:55, Dovid Bender wrote:
Could it be related to the fiber cut in the red sea?
Asia-Pac <=> North America is typically faster via the Pacific, not the
Indian Ocean.
The Red Sea cuts would impact Asia-Pac <=> Europe traffic.
SMW-5 had an outage on the 19th of April around the
On 5/18/24 08:56, Saku Ytti wrote:
As long as our toolbox only has a capitalist hammer, peering disputes
are going to be a thing. Cogent has outlived many of its peering
dispute history partners. They are the grandfather of disruptive
transit pricing, which many others have struggled to meet p
On 5/18/24 06:04, Jon Lewis wrote:
Cogent has been trying to establish themselves as a "tier 1" carrier
in markets outside their home turf, and Asia is one of the markets in
which the established operators are doing their best to keep Cogent out.
Back when I was helping to run a global a
On 5/16/24 21:53, Brandon Zhi wrote:
Are APNs like a vpn for mobile devices to access the public internet?
Based on the experience that I used Mobile roaming outside my country.
The provider would connect back to the original country via local
providers.
When roaming, the home mobile netwo
On 5/13/24 05:32, Brandon Martin wrote:
I doubt that's changed given my dealings with them since (which have
been fine, to be clear), but I can't be 100% sure. I suspect they did
at least turn up a few of them given that they went to the trouble of
creating a full-fledged product for it.
On 5/13/24 04:07, Dave Cohen wrote:
My point was that the technology has little to do with the operational
success of the service. Spectrum controllers better enabling providers
to get out of their own way in selling spectrum did not actually
enable the providers* to get out of their own wa
On 5/13/24 00:11, Dave Cohen wrote:
Mark,
Many/all of these points are fair. My experience is purely terrestrial and
obviously both the capacity and economic calculations are vastly different in
those situations, which I should have called out.
Actually, terrestrial economics are easier t
On 5/12/24 20:35, Dave Cohen wrote:
It’s one of those things that makes a lot more sense on paper than in practice.
Not anymore.
The majority of SDM subsea cables built with uncompensated fibre are
using managed spectrum and spectrum sharing as viable business models
for a not-so-insignifi
On 5/12/24 14:08, Mike Hammett wrote:
What are your experiences with alien waves, managed spectrum, spectrum as a
service, etc?
Your outcomes will vary depending on whether this is deployed for
terrestrial or subsea networks.
Subsea networks don't typically do alien waves, but rather, ma
On 4/28/24 18:54, Siyuan Miao wrote:
We use GL.inet and set up WireGuard VPNs back to our distributed VPN
servers. Our console servers support dual uplink, so we just connect
port 1 to the GL.inet LAN and port 2 to our management switch.
Currently, we're still using their LTE model, and it
On 4/27/24 17:49, Mel Beckman wrote:
Quite often I’m looking for OOBM at antenna sites or in remote DCs where there
is no Plan B carrier. Cellular has always been the goto choice for this, but we
keep getting pushed out of contracts by technology upgrades. 2g, then 3g, and
next 4g LTE are
On 4/27/24 07:56, Saku Ytti wrote:
For me Cisco is great here, because it's something an organisation
already knows how to source, turn-up, upgrade, troubleshoot, maintain.
And you get a broad set of features you might want, IPSEC, DMVPN, BGP,
ISIS, and so forth.
I tend to agree.
Cisco do t
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 multi
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, th
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 da
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).
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 di
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, Et
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 alread
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
On 4/19/24 10:08, Saku Ytti wrote:
Of course there are limits to this, as FEC is hop-by-hop, so in
long-haul you'll know about circuit quality to the transponder, not
end-to-end. Unlike in wan-phy, OTN where you know both.
Technically optical transport could induce FEC errors, if there are
FE
On 4/19/24 10:08, Saku Ytti wrote:
Of course there are limits to this, as FEC is hop-by-hop, so in
long-haul you'll know about circuit quality to the transponder, not
end-to-end. Unlike in wan-phy, OTN where you know both.
Technically optical transport could induce FEC errors, if there are
FE
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.
Lo
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.
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, des
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ios-dos-Hq4d3tZG
Mark.
On 4/4/24 08:25, Mike Lyon wrote:
I use it for config backups, diffs, etc. Love it.
Theres others such as Rancid but im not sure if it works on anything
other than Vendor C.
RANCID works perfectly for Cisco, Juniper, Arista, Brocade (Foundry) and HP.
They are also known to support other
On 4/3/24 04:13, aun Joe wrote:
is there anysi network simulator for carrier networks ?
well, from 2023 to 2024 there happes so many carrier network
outage caused by network operation.
to my limited knowledge , SP guru from riverbed could simulate
carrier network. but I just c
On 3/29/24 21:48, Matthew Petach wrote:
I'm with Randy Bush on this. The stakeholders in that event should
have the say in what happens with it; not the rest of us.
While I agree that women would know best how they want to socialize for
their own interests, I don't think that men engaging
On 3/30/24 03:45, Ryan Hamel wrote:
Paul,
Anne's opinion is just as valid as the others here. I have also
browsed through the recent attendee lists and do not see you listed
either, pot calling the kettle black. Your comments about her email
signature and which voices are valid here, are n
On 3/29/24 18:31, Tom Beecher 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 m
On 3/29/24 18:23, Tom Beecher wrote:
My recollection is that every WiT lunch was always open to all. Happy
to be corrected if any were that I don't recall.
There were definitely a few meetings during my PC years that someone
complained that men were not allowed to attend. If my memory se
On 3/29/24 07:03, Eric Parsonage wrote:
It's easily fixed by having a mixer at the same time for the other
half of the gathering population thus showing all the population
gathering matters equally.
My memory is a little fuzzy, but I think I recall one of the early WiT
lunches hosted at N
On 3/29/24 06:20, Ren Provo wrote:
I beg to differ here and second Ilissa’s comments. I miss WiT. Lunch
during the meeting worked. Giving up more of the weekend to travel
does not show half the population gathering matters.
It would be interesting to survey the % of attending women who:
On 3/28/24 21:08, Tom Beecher wrote
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 anythin
On 3/28/24 19:45, Ilissa Miller wrote:
For those that know me, I rarely provide constructive input
about NANOG matters due to my past affiliation, however, I just saw
that NANOG announced the Women mixer on Sunday before NANOG 91 and am
outraged for all of the young professional women who w
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 ex
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 t
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 su
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 mileage
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 level.
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 t
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 var
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 without
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, n
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 yo
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 wi
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 mos
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 as
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
transit
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 al
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 I'd
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
acceler
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 NAT'
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. I
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 th
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 reve
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 integrate
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 tha
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 consid
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 algori
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. U
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 ag
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 that
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 larg
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 larg
1 - 100 of 1481 matches
Mail list logo