[Tfug] Ethernet frame "immutables" wrt switch silicon

Bexley Hall bexley401 at yahoo.com
Sat May 11 14:21:54 MST 2013


Hi Zack,

On 5/11/2013 2:09 PM, Zack Breckenridge wrote:
> This is an interesting question... I don't have your answer, but it's
> fun to speculate. From Wikipedia:
>
> "A frame starts with a 7-byte preamble and 1-byte start frame
> delimiter (SFD)...the corresponding hexadecimal representation is 0x55
> 0x55 0x55 0x55 0x55 0x55 0x55 0xD5.
>
> PHY transceiver chips used for Fast Ethernet feature a 4-bit (one
> nibble) Media Independent Interface. Therefore the preamble will
> consist of 14 instances of 0x5, and the start frame delimiter 0x5 0xD.
> Gigabit Ethernet transceiver chips use a Gigabit Media Independent
> Interface that works 8-bits at a time, and 10 Gbit/s (XGMII) PHY works
> with 32-bits at a time."
>
> Then there's the rest of the frame, and an interframe gap. So what
> happens when some "non conforming" hardware ignores the interframe
> gap, or somehow mangles/overlaps frame start sequences, etc? I'm

There are NIC's that can push packets out with "too small" of a gap.
Using one of these (without a deliberate workaround) can lead to
connectivity problems -- as the NIC *thinks* it is passing packets
correctly but other devices can't recover quick enough to sense
the start of the "next" packet.

> willing to bet this "smallest" frame portion is undocumented/assumed
> for the obvious reason that manufacturers aren't handling all of the
> possibilities.. It might be a fun hardware experiment to see how
> different switches react :)

I'm more interested in what *parts* of the (legitimate) frame
are parsed/relied upon by the switch(es).

E.g., the switch (differing from a "hub") would have to watch the
destination MAC to know to which port the packet should get sent.
Also, the source MAC to know what nodes *generate* traffic on that
(incoming) port.

Presumably, the CRC would need to be monitored so the switch could
decide if the packet has been corrupted (I suppose a switch *could*
just pass along a corrupted packet "as it" but that seems silly).

That leaves the frame type as the only field that seems to have
some wiggle room regarding interpretation/significance.

And, of course, there's the whole issue of how switch silicon
deals with "broken" frames -- or, frames that go beyond their
idea of what a frame "should be".




More information about the tfug mailing list