*LAST CALL for Presentations! *
*Submission Deadline is Monday *
Whether you are on the stage or as a live remote presenter, we want to hear
from you!
Submit a presentation proposal, including draft slides, no later than
Monday, 22 April.
*Submit Now*
I'm being sloppy with my verbiage, it's just been a long time since
I thought about this in detail, sorry.
The MAC layer hands bits to the Media Independent Interface, which connects
the MAC to the PHY. The PHY converts the digital 1/0 into the form required
by the media transmission type; the
On 4/18/24 11:45, Aaron Gould wrote:
Thanks. What "all the ethernet control frame juju" might you be
referring to? I don't recall Ethernet, in and of itself, just sending
stuff back and forth. Does anyone know if this FEC stuff I see
concurring is actually contained in Ethernet Frames?
> What "all the ethernet control frame juju" might you be referring
> to? I don't recall Ethernet, in and of itself, just sending stuff back and
> forth.
I did not read the 100G Ethernet specs, but as far as I remember
FastEthernet (e.g. 100BASE-FX) uses 4B/5B coding on the line, borrowed
from
Thanks. What "all the ethernet control frame juju" might you be
referring to? I don't recall Ethernet, in and of itself, just sending
stuff back and forth. Does anyone know if this FEC stuff I see
concurring is actually contained in Ethernet Frames? If so, please send
a link to show the
FEC is occurring at the PHY , below the PCS.
Even if you're not sending any traffic, all the ethernet control frame juju
is still going back and forth, which FEC may have to correct.
I *think* (but not 100% sure) that for anything that by spec requires FEC,
there is a default RS-FEC type that
Not to belabor this, but so interesting... I need a FEC-for-Dummies or
FEC-for-IP/Ethernet-Engineers...
Shown below, my 400g interface with NO config at all... Interface has no
traffic at all, no packets at all BUT, lots of FEC hits. Interesting this
FEC-thing. I'd love to have a fiber
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.
>
> We've seen the same between Juniper and Arista boxes in the same rack
> running at 100G, despite cleaning fibres, swapping optics, moving ports,
> moving line cards, e.t.c. TAC said it's a non-issue, and to be expected,
> and shared the same KB's.
>
>
Just for extra clarity off those KB,
Standard deviation is now your friend. Learned to alert on outside of SD
FEC and CRCs. Although the second should already be alerting.
On Thu, Apr 18, 2024 at 8:15 AM Mark Tinka wrote:
> On 4/17/24 23: 24, Aaron Gould wrote: > Well JTAC just said that it seems
> ok, and that 400g is going to
In my reading the 400GBASE-R Physical Coding Sublayer (PCS) always
includes the FEC. This is defined in clause 119 of IEEE Std 802.3-2022,
and most easily seen in "Figure 119–2—Functional block diagram" if you
don't want to get buried in the prose. Nothing there seems to imply that
the FEC is
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,
Corrected FEC errors are pretty normal for 400G FR4
On Wednesday, April 17th, 2024 at 3:36 PM, Aaron Gould wrote:
> 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 on 400G is required and expected. As long as it is “corrected”, you have
nothing to worry about. We had the same realisation recenty when upgrading to
400G.
-Schylar
From: NANOG on behalf of Aaron
Gould
Date: Wednesday, April 17, 2024 at 2:38 PM
To: nanog@nanog.org
Subject: constant
14 matches
Mail list logo
