[Tfug] Ethernet frame "immutables" wrt switch silicon

[vaca at grazeland.com]

If only some vendor could just make this, alas, nobody makes efficient Ethernet switches or embedded chips for custom applications. 

On May 11, 2013, at 2:21 PM, Bexley Hall <bexley401 at yahoo.com> wrote:

> 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".
> 
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org