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
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
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
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,
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
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
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,
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
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
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
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.
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,
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
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
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
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
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
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
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
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
1 - 100 of 2576 matches
Mail list logo