We recently added MPC10E-15C-MRATE cards to our MX960's to upgrade our core to
400g. During initial testing of the 400g interface (400GBASE-FR4), I see
constant FEC errors. FEC is new to me. Anyone know why this is occurring?
Shown below, is an interface with no traffic, but seeing constant
Open a JTAC case,
That looks like a work for them
Kind Regards,
Dominik
W dniu śr., 17.04.2024 o 21:36 Aaron Gould napisał(a):
> We recently added MPC10E-15C-MRATE cards to our MX960's to upgrade our core
> to 400g. During initial testing of the 400g interface (400GBASE-FR4), I see
> consta
i did. Usually my NANOG and J-NSP email list gets me a quicker solution
than JTAC.
-Aaron
On 4/17/2024 2:37 PM, Dominik Dobrowolski wrote:
Open a JTAC case,
That looks like a work for them
Kind Regards,
Dominik
W dniu śr., 17.04.2024 o 21:36 Aaron Gould napisał(a):
We recently added
I'm no TAC engineer, but the purpose of FEC is to take and correct errors
when the port is going so fast that errors are simply inevitable. Working
as Intended.
Easier (read: cheaper) to build in some error correction than make the bits
wiggle more reliably.
No idea if that rate of increment is a
Isn't FEC required by the 400G spec?
On Wed, Apr 17, 2024 at 3:45 PM Aaron Gould wrote:
> i did. Usually my NANOG and J-NSP email list gets me a quicker solution
> than JTAC.
>
> -Aaron
> On 4/17/2024 2:37 PM, Dominik Dobrowolski wrote:
>
> Open a JTAC case,
> That looks like a work for them
>
fec cliff? is there a level of fec erros that i should be worried about
then? not sure what you mean.
-Aaron
On 4/17/2024 2:46 PM, Matt Erculiani wrote:
I'm no TAC engineer, but the purpose of FEC is to take and correct
errors when the port is going so fast that errors are
simply inevitable
Thanks Joe and Schylar, that's reassuring. Tom, yes, I believe fec is
required for 400g as you see fec119 listed in that output... and i
understand you can't (or perhaps shouldn't) change it.
-Aaron
On 4/17/2024 2:43 PM, Joe Antkowiak wrote:
Corrected FEC errors are pretty normal for 400G FR
Hi.
Looks like normal behavior:
https://supportportal.juniper.net/s/article/PTX-FEC-corrected-errors-increasing-on-link-between-QSFP-100GBASE-SR4-740-058734-and-QSFP-100G-SR4-T2-740-061405?language=en_US
"An incrementing FEC Corrected Errors counter is normal for a link that
is running FEC. It
Notes I found that I took from smart optical people :
"PAM4 runs at much lower SNRs than NRZ, because you're trying to read 4
distinct voltage levels instead of 2.Even the cleanest system will have
some of that, so the only way to make it usable is to have FEC in place."
On Wed, Apr 17, 2024 at
At some point, an error rate would exceed the ability of forward error
correction (FEC) overhead to compensate, resulting in CRC errors. You're
not seeing those so all is technically well.
It's not so much how many packets come in with errors that causes a
problem, but what percentage of each pack
Interesting, thanks all, the JTAC rep got back to me and also pretty
much said it's not an issue and is expected... also, JTAC rep sited 2
KB's, shown here, both using 100g as an example... question please,
should I understand that this is also true about 400g, even though his
KB's speak about
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."
-Aaron
On 4/17/2024 4:04 PM, Aaron Gould wrote:
Interesting, thanks all, the JTAC rep got back to me and also pretty
much said it
12 matches
Mail list logo
