We’ve had success with multiple VLAN tagged handoffs/BGP sessions w/ Cogent
with various customers of ours in similar scenarios.
Perhaps you can ask for multiple VLANs each with a /31 + /127 + BGP sessions.
> On Jun 11, 2024, at 07:35, Justin Wilson (Lists) wrote:
>
> We were able
ltiple BGP sessions against a wider address scope than
standard p2p toward the same Cogent edge router, rather than just paying
for the wider address scope space itself?
In other words; p2p BGPv6 session = free; p2mp BGPv6 session = $$.
Mark.
al Message -
From: "Peter Potvin via NANOG"
To: "Justin Wilson (Lists)"
Cc: nanog@nanog.org
Sent: Monday, June 10, 2024 4:47:37 PM
Subject: Re: Cogent BGP session more than 1 router ipv6
Cogent stopped offering anything larger than a /31 IPv4 and /127 IPv6 on new
We were able to get a /28 from cogent for peering on ipv4. I believe we are
paying for this, but our rep is not getting the concept of it in ipv6. He says
he can only order a /127 or /48. I don’t mind paying. I
Justin Wilson
j...@mtin.net
—
https://j2sw.com (AS399332)
https
Cool, I’ll give it a look, thanks AaronOn Jun 10, 2024, at 6:24 PM, Peter Potvin wrote:That was resolved a couple years back I believe, I'm receiving Google's IPv6 DNS prefix (2001:4860::/32) from Cogent currently but it goes via 6453 before entering 15169's network.PeterOn Mon,
That was resolved a couple years back I believe, I'm receiving Google's
IPv6 DNS prefix (2001:4860::/32) from Cogent currently but it goes via 6453
before entering 15169's network.
Peter
On Mon, Jun 10, 2024 at 5:53 PM Aaron1 wrote:
> Also related to Cogent and v6… I recal
>From what I recall both HE and Google over v6 are not accessible via Cogent
On Mon, Jun 10, 2024 at 17:53 Aaron1 wrote:
> Also related to Cogent and v6… I recall having Google v6 DNS reachability
> issue through Cogent previously… is that still a problem?
>
> Aaron
>
>
It’s Cogent, what do you expect?Friends don’t let friends use Cogent.-MikeOn Jun 10, 2024, at 14:49, Peter Potvin via NANOG wrote:Cogent stopped offering anything larger than a /31 IPv4 and /127 IPv6 on new DIA circuits earlier this year, when previously they provided a /29 IPv4 and /112 IPv6
Also related to Cogent and v6… I recall having Google v6 DNS reachability issue through Cogent previously… is that still a problem?AaronOn Jun 10, 2024, at 4:48 PM, Peter Potvin via NANOG wrote:Cogent stopped offering anything larger than a /31 IPv4 and /127 IPv6 on new DIA circuits earlier this
Cogent stopped offering anything larger than a /31 IPv4 and /127 IPv6 on
new DIA circuits earlier this year, when previously they provided a /29
IPv4 and /112 IPv6 without issue at no additional cost. Now they expect you
to pay additional for this functionality, including for redundant sessions
I am trying to get our Cogent rep to give us a /124 to peer on a Cogent circuit
with. We have multipl routers we want to peer to a cogent transit circuit
with.on.
Does anyone have the magic words or a circuit ID example you are doing multiple
BGP conenctions on a single circuit?
Justin
It appears that Bryan Fields said:
>Suppose the community wanted to change this or make a formal policy on root
>server hosting requirements. Where would this be done? Could a party submit
>a proposal to ICANN via the policy development process? If not where should
>the community start this?
T
Oops. Missed a (significant) word.
On May 19, 2024, at 3:02 PM, David Conrad via NANOG wrote:
> On May 19, 2024, at 1:12 PM, Bryan Fields wrote:
>> Suppose the community wanted to change this or make a formal policy on root
>> server hosting requirements. Where would this be done? Could a par
On May 19, 2024, at 1:12 PM, Bryan Fields wrote:
> Suppose the community wanted to change this or make a formal policy on root
> server hosting requirements. Where would this be done? Could a party submit
> a proposal to ICANN via the policy development process? If not where should
> the commun
On 5/19/24 3:13 PM, David Conrad via NANOG wrote:
> When you say “ICANN” who, exactly, do you mean? ICANN the organization or
> ICANN the community? If the former, ICANN Org can’t do anything outside of
> ICANN community defined policy or process or risk all sorts of
> unpleasantness from interna
John,
On May 19, 2024, at 12:53 PM, John R. Levine wrote:
> On Sun, 19 May 2024, David Conrad wrote:
>>> They provide this to Verisign, the Root Zone Maintainer, who create the
>>> root zone and distribute it to the root server operators.
>>
>> Technically, IANA provides database change requests
On Sun, 19 May 2024, David Conrad wrote:
They provide this to Verisign, the Root Zone Maintainer, who create the
root zone and distribute it to the root server operators.
Technically, IANA provides database change requests to Verisign. The actual
database is maintained by the Root Zone Maintai
On May 17, 2024, at 10:14 PM, Bill Woodcock wrote:
>> On May 18, 2024, at 02:30, William Herrin wrote:
>> So Cogent operates a root server because they bought PSI who ran a
>> root server and ICANN has never chosen to throw down the gauntlet.
>
> As John said, ICANN ha
John,
On May 17, 2024, at 6:53 PM, John R. Levine wrote:
> ICANN as the IANA Functions Operator maintains the database of TLD info.
Sort of.
> They provide this to Verisign, the Root Zone Maintainer, who create the
> root zone and distribute it to the root server operators.
Technically, IANA
as
> you have single pop, and open policy to peer with anyone who wants to connect
> to your pop, you qualify?
The topic of the conversation was Cogent, and this question doesn’t apply to
them. We have to recognize that there are a limited number of public-benefit
entities with the mi
er to use to compel payments from its
competitors. For a for-profit network, that’s a perfectly reasonable trade-off
to make, and is undoubtedly good for short-term shareholder returns. For
something that should be public-benefit network, it’s counterproductive.
Anyway, I thought the conversation
On 18/05/2024 08:38, Bill Woodcock wrote:
L-root, ICANN, selective: https://www.dns.icann.org/imrs/
...
So, of the thirteen root nameservers, ten are potentially available
for interconnection, and of those, only two, Cogent and ICANN, don’t
have open peering policies.
IIUC, most of L
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 May 18, 2024, at 08:56, Saku Ytti wrote:
> What are we asking in terms of your proposed policy change of allowing
> host a root DNS? You must peer with everyone and anyone, at any terms?
Well, putting aside Cogent per se, and focusing on this much more interesting
issue, I woul
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
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
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 ru
p_docs/129-root-zone-maintainer-service-agreement-v-28sep16
Absent interdiction from NTIA it gives ICANN the authority to direct
Verisign to do exactly what I said. And Cogent disconnecting the C
servers from a sizable part of the Internet is almost certainly
sufficient excuse to do it on an "
> On Fri, May 17, 2024, 6:05 PM William Herrin wrote:
> For those who haven't been around long enough, this isn't Cogent's
> first depeering argument. Nor their second.
They’re also still in the middle of one with NTT.
https://en.wikipedia.org/wiki/Cogent_Communications#Peering_disputes
> On May 18, 2024, at 02:30, William Herrin wrote:
> So Cogent operates a root server because they bought PSI who ran a
> root server and ICANN has never chosen to throw down the gauntlet.
As John said, ICANN has nothing to do with who runs root servers. Last I knew,
NTIA still
> On May 18, 2024, at 03:53, John R. Levine wrote:
> On Fri, 17 May 2024, William Herrin wrote:
>> That said, ICANN generates the root zone including the servers
>> declared authoritative for the zone.
> Nope.
>
>> So they do have an ability to
>> say: nope, you've crossed the line to any of the
Perhaps Cogent is permitted to operate a root server's infrastructure as an
on-going, real-time disaster scenario - demonstrating what happens to critical
DNS infrastructure when there's considerable routing loss.
Not much, it seems.
-joe
On 5/17/2024 at 5:06 PM, "William
On Fri, 17 May 2024, William Herrin wrote:
On Fri, May 17, 2024 at 9:55 AM Ben Cartwright-Cox via NANOG
wrote:
Also poking around on RIPE Atlas suggests that for a non-zero amount
of networks in India the C DNS Root Server that cogent runs is
inaccessible: https://atlas.ripe.net/measurements
On Fri, 17 May 2024, William Herrin wrote:
That said, ICANN generates the root zone including the servers
declared authoritative for the zone.
Nope.
So they do have an ability to
say: nope, you've crossed the line to any of the root operators.
Very very nope.
ICANN as the IANA Functions Op
On Fri, May 17, 2024 at 4:28 PM John Levine wrote:
> It appears that William Herrin said:
> >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 con
It appears that William Herrin said:
>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?
You must be new here. There is no contract for running root se
Not even the first time tata and cogent separated. Will avoid public
details but I was on the keyboard at 6453 that time.
On Fri, May 17, 2024, 6:05 PM William Herrin wrote:
> On Fri, May 17, 2024 at 9:55 AM Ben Cartwright-Cox via NANOG
> wrote:
> > Also poking around on RIPE At
On Fri, May 17, 2024 at 9:55 AM Ben Cartwright-Cox via NANOG
wrote:
> Also poking around on RIPE Atlas suggests that for a non-zero amount
> of networks in India the C DNS Root Server that cogent runs is
> inaccessible: https://atlas.ripe.net/measurements/71894623#probes
I don't
It would appear that ( as of yesterday ) some but not all BGP routes
between Cogent and TATA are gone.
>From my own observations it seems like all TATA Routes in APAC and
India are now not visible from cogent connections/customers.
There's also a report of a cogent support ticket respo
On Mon, Oct 2, 2023 at 7:27 PM Collider
wrote:
> Congrats! LIOAWKI is a hapax legomenon in DuckDuckGo's search results!
> Could you please tell me & the list what it means?
>
Large Internet Outages Are What Kills Income!
It's a phrase that is uttered by members of the finance organization every
Based on my personal experience of getting onto the contact list of an
extremely persistent Cogent sales person, mostly, I am morbidly curious
what their CRM system looks like for cold and stale leads, and how often
these sets of non-responsive leads get passed on to new junior salespeople.
And
ongrats! LIOAWKI is a hapax legomenon in DuckDuckGo's search results! Could
>> you please tell me & the list what it means?
>>
>>
>> Le 2 octobre 2023 15:28:03 UTC, Mel Beckman a écrit :
>>> This morning I received an email from someone at Cogent askin
Problem with that theory is the ratio of collateral damage to pain inflicted.
Filter or deeper cogent and they don’t feel anything themselves. Their
customers _might_ miss being able to reach your customers (or you), but then it
is Cogent’s customers that feel the pain the most and Cogent to a
This is not the outcome of internet ecosystem, this is outcome
of commercialization, where money is what is all cared, not good
product, ethical behavior, etc.
This is also because good guys do NOT fight back strong enough.
Cogent start to give you hard time? Start to filter they whole
prefixes
3, 2023, at 18:18, Mike Lyon wrote:
>>
>> Give it time :)
>>
>> -Mike
>>
>>> On Oct 3, 2023, at 18:06, Owen DeLong via NANOG wrote:
>>>
>>> But I seem to have finally gotten Cogent trained not to spam this one, so
>>> I think
On Oct 3, 2023, at 11:52 AM, Bryan Fields wrote:
On 10/2/23 11:28 AM, Mel Beckman wrote:
I believe they got the contact information from ARIN
I'd suggest everyone use an alias unique to ARIN for your POC and/or public
email. Makes it super simple to verify where it was sourced from.
(and yes
> On Oct 3, 2023, at 11:52 AM, Bryan Fields wrote:
>
> On 10/2/23 11:28 AM, Mel Beckman wrote:
>> I believe they got the contact information from ARIN
>
> I'd suggest everyone use an alias unique to ARIN for your POC and/or public
> email. Makes it super simple to verify where it was sourced
6, Owen DeLong via NANOG wrote:
>>
>> But I seem to have finally gotten Cogent trained not to spam this one, so I
>> think I’ll leave it as is.
>>
>> YMMV
>>
>> Owen
>>
>>
>>> On Oct 3, 2023, at 08:52, Bryan Fields wrote
Give it time :)
-Mike
> On Oct 3, 2023, at 18:06, Owen DeLong via NANOG wrote:
>
> But I seem to have finally gotten Cogent trained not to spam this one, so I
> think I’ll leave it as is.
>
> YMMV
>
> Owen
>
>
>> On Oct 3, 2023, at 08:52, Bryan Fields
But I seem to have finally gotten Cogent trained not to spam this one, so I
think I’ll leave it as is.
YMMV
Owen
> On Oct 3, 2023, at 08:52, Bryan Fields wrote:
>
> On 10/2/23 11:28 AM, Mel Beckman wrote:
>> I believe they got the contact information from ARIN
>
> I&#
* morrowc.li...@gmail.com (Christopher Morrow) [Tue 03 Oct 2023, 21:50 CEST]:
I'm sure telling dave shaeffer: "Hey, your sales droids are being
rude" is going to end as well as sending him ED pill emails.
Such outreach to technical contacts is counterproductive anyway. Which
is more likely, th
s helpful to keep re-litigating that end state :(
I'm sure telling dave shaeffer: "Hey, your sales droids are being
rude" is going to end as well as sending him ED pill emails.
On the other hand, it's actually nice knowing Cogent are up to their
same old tricks, so that when
On Tue, Oct 3, 2023 at 12:54 PM wrote:
>
> * morrowc.li...@gmail.com (Christopher Morrow) [Tue 03 Oct 2023, 18:29 CEST]:
> >this sort of thing (provider X scrapes Y and mails Z for sales leads)
> >every ~18 months.
> >the same outrage and conversation happens every time.
> >the same protection mec
* morrowc.li...@gmail.com (Christopher Morrow) [Tue 03 Oct 2023, 18:29 CEST]:
this sort of thing (provider X scrapes Y and mails Z for sales leads)
every ~18 months.
the same outrage and conversation happens every time.
the same protection mechanisms are noted every time.
Is there a reason that
this sort of thing (provider X scrapes Y and mails Z for sales leads)
every ~18 months.
the same outrage and conversation happens every time.
the same protection mechanisms are noted every time.
Is there a reason that: "killfileand move on" is not the answer
everytime for this?
(why do we need to
On 10/2/23 11:28 AM, Mel Beckman wrote:
I believe they got the contact information from ARIN
I'd suggest everyone use an alias unique to ARIN for your POC and/or public
email. Makes it super simple to verify where it was sourced from.
(and yes I've got the same spam)
--
Bryan Fields
727-40
3 UTC, Mel Beckman a écrit :
>>This morning I received an email from someone at Cogent asking about an ASN I
>>administer. They didn’t give any details, but I assumed it might be related
>>to some kind of network transport issue. I replied cordially, asking them
>>wha
Congrats! LIOAWKI is a hapax legomenon in DuckDuckGo's search results! Could
you please tell me & the list what it means?
Le 2 octobre 2023 15:28:03 UTC, Mel Beckman a écrit :
>This morning I received an email from someone at Cogent asking about an ASN I
>administer. They
; Other outfits have been spamming using the nanog attendees list, but I guess
>> that’s not as bad as the continued scraping of ARIN records, so I won't call
>> them out... yet, at least. 😊
>>
>> -Original Message-
>> From: NANOG On Behalf Of Me
s list, but I guess
>> that’s not as bad as the continued scraping of ARIN records, so I won't call
>> them out... yet, at least. 😊
>>
>> -----Original Message-
>> From: NANOG On Behalf Of Mel Beckman
>> Sent: Monday, October 2, 2023 10:28 AM
>>
using the nanog attendees list, but I guess
> that’s not as bad as the continued scraping of ARIN records, so I won't call
> them out... yet, at least. 😊
>
> -Original Message-
> From: NANOG On Behalf Of Mel Beckman
> Sent: Monday, October 2, 2023 10:28 AM
> To: na
transit contracts than one big tier 3 wholesaler transit contract.
That's my point.
Smaller ISP's will get better per-Mbps rates from their direct upstreams
than they would from HE/Cogent. The rates they'd get from HE/Cogent
would be to HE's/Cogen's favour, and not to the
On Mon, Oct 2, 2023, 12:14 Mark Tinka wrote:
>
>
> 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".
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
To: nanog list
Subject: cogent spamming directly from ARIN records?
This morning I received an email from someone at Cogent asking about an ASN I
administer. They didn’t give any details, but I assumed it might be related to
some kind of network transport issue. I replied cordially, asking them what
t
Jay,
Apparently my sarcasm was too subtle :)
-mel
> On Oct 2, 2023, at 10:01 AM, Jay Hennigan wrote:
>
> On 10/2/23 09:16, Mel Beckman wrote:
>> Tom,
>> Thanks for that pointer! apparently cogent has a history of abuse.
>
> Apparently?
>
> In other news,
On 10/2/23 09:16, Mel Beckman wrote:
Tom,
Thanks for that pointer! apparently cogent has a history of abuse.
Apparently?
In other news, apparently bears have been using our National Forests as
their personal toilets for decades.
--
Jay Hennigan - j...@west.net
Network Engineering - CCIE
t;>
>> Mel, I will reply to you off list. Thanks.
>>
>> On 10/2/23, 11:28 AM, "NANOG on behalf of Mel Beckman"
>> mailto:arin@nanog.org> on
>> behalf of m...@beckman.org <mailto:m...@beckman.org>> wrote:
>>
>>
>> This
Tom,
Thanks for that pointer! apparently cogent has a history of abuse.
-mel
On Oct 2, 2023, at 8:34 AM, Tom Beecher wrote:
complia...@arin.net<mailto:complia...@arin.net>
Refer back to an email John Curran sent to this list on Jan 6 2020 ,
"Suspension of Cogent access to ARIN
ckman.org <mailto:m...@beckman.org>> wrote:
>
>
> This morning I received an email from someone at Cogent asking about an ASN I
> administer. They didn’t give any details, but I assumed it might be related
> to some kind of network transport issue. I replied cordially, askin
complia...@arin.net
Refer back to an email John Curran sent to this list on Jan 6 2020 ,
"Suspension of Cogent access to ARIN Whois"
On Mon, Oct 2, 2023 at 11:29 AM Mel Beckman wrote:
> This morning I received an email from someone at Cogent asking about an
> ASN I administer.
Mel, I will reply to you off list. Thanks.
On 10/2/23, 11:28 AM, "NANOG on behalf of Mel Beckman"
mailto:arin@nanog.org> on
behalf of m...@beckman.org <mailto:m...@beckman.org>> wrote:
This morning I received an email from someone at Cogent asking about an ASN I
a
This morning I received an email from someone at Cogent asking about an ASN I
administer. They didn’t give any details, but I assumed it might be related to
some kind of network transport issue. I replied cordially, asking them what
they needed. The person then replied with a blatant spam
Some interesting new developments on this, independent of the divergent network
equipment discussion. 😊
Cogent had a field engineer at the east coast location where my local loop
(10gig wave) meets their equipment, i.e. (me – patch cable to loop provider’s
wave equipment – wave – patch cable
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 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
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 consider physical resiliency in the
design", whic
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
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 algorithms.
randy
Mark Tinka writes:
> Oh? What is it then, if it's not spraying successive packets across
> member links?
It sprays the packets more or less randomly across links, and each link
then does individual buffering. It introduces an unnecessary random
delay to each packet, when it could just place them
It was intended to detect congestion. The obvious response was in some way to
pace the sender(s) so that it was alleviated.
Sent using a machine that autocorrects in interesting ways...
> On Sep 7, 2023, at 11:19 PM, Mark Tinka wrote:
>
>
>
>> On 9/7/23 09:51, Saku Ytti wrote:
>>
>> Perhap
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 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
Saku Ytti wrote:
And you will be wrong. Packet arriving out of order, will be
considered previous packet lost by host, and host will signal need for
resend.
As I already quote the very old and fundamental paper on
the E2E argument:
End-To-End Arguments in System Design
https://groups.csa
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
Tom Beecher wrote:
Well, not exactly the same thing. (But it's my mistake, I was referring to
L3 balancing, not L2 interface stuff.)
That should be a correct referring.
load-balance per-packet will cause massive reordering,
If buffering delay of ECM paths can not be controlled , yes.
bec
Mark Tinka writes:
> set interfaces ae2 aggregated-ether-options load-balance per-packet
>
> I ran per-packet on a Juniper LAG 10 years ago. It produced 100%
> perfect traffic distribution. But the reordering was insane, and the
> applications could not tolerate it.
Unfortunately that is not
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
Benny Lyne Amorsen wrote:
TCP looks quite different in 2023 than it did in 1998. It should handle
packet reordering quite gracefully;
Maybe and, even if it isn't, TCP may be modified. But that
is not my primary point.
ECMP, in general, means pathes consist of multiple routers
and links. The l
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.
On Wed, Sep 6, 2023 at 1:13 PM Mark Tinka wrote:
>
>
> On 9/
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 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
>
> Unless you specifically configure true "per-packet" on your LAG:
>
Well, not exactly the same thing. (But it's my mistake, I was referring to
L3 balancing, not L2 interface stuff.)
load-balance per-packet will cause massive reordering, because it's random
spray , caring about nothing except e
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
> If you applications can tolerate reordering, per-packet is fine. In the public
> Internet space, it seems we aren't there yet.
Yeah this
During lockdown here in Italy one day we started getting calls about
performance issues performance degradation, vpns dropping or becoming unusable,
and gen
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.
>
> For example Juniper offers true per-packet, I think mostly used in
> high performance computing.
>
At least on MX, what Juniper calls 'per-packet' is really 'per-flow'.
On Wed, Sep 6, 2023 at 10:17 AM Saku Ytti wrote:
> On Wed, 6 Sept 2023 at 17:10, Benny Lyne Amorsen
> wrote:
>
> > TCP lo
1 - 100 of 1001 matches
Mail list logo
