[Tfug] Ethernet frame "immutables" wrt switch silicon

Louis Taber ltaber at gmail.com
Sun May 12 21:22:00 MST 2013


On Sun, May 12, 2013 at 2:29 PM, Bexley Hall <bexley401 at yahoo.com> wrote:
>
>
> [Should a switch be able to *fix* a bad CRC when it retransmits??]
>
> It can't.  CRCs contain no error correction information.

>
>  At a minimum, if the switch can do a cut through, it will
>> need to see the destination MAC address prior to sending the packet
>> forward.
>>
>
> There still is buffering present in a cut through -- it's just
> not "deferred" to the extent that it might otherwise be (e.g.,
> in the case where the destination port is busy at the time).
>
>
>  Does anyone know of a switch that can do a cut through on
>> broadcast packets to available ports while using a store and forward
>> strategy for the remaining interfaces?  - Louis
>>
>
> I sincerely doubt any manufacture would bother.  As the switch gets larger
it makes more sense, but as a switch gets larger it also needs to deal with
virtual networks as well.  And if the broadcast packet is bad,  it will be
sending bad packets to most recipients


>
> OTOH, I can't see why a switch wouldn't do this as a natural
> consequence of its design -- it decides whether to cut through
> or store based on how busy the destination i/f is... why would
> it not use a similar algorithm when processing an incoming broadcast
> packet?  I.e., "get this packet out *your* port as soon as it
> makes sense to you..." (regardless of what the other ports are
> doing, now)
>
> How a switch manufacturer assures that each port gets the packet will
vary.  Mixing cut-through and store and forward will complicate the design,
and my guess, to little advantage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20130512/16462971/attachment-0002.html>


More information about the tfug mailing list