[jantao]

Добрый день, коллеги!

 

Читаю документацию для nexus 3k и никак не могу разобраться в следующих моментах:

1)

Cut-Through Switching Mode Guidelines and Limitations

    Packets with frame check sequence (FCS) errors are dropped.

        For the Cisco Nexus 3064PQ platform, packets smaller than or equal to 768 bytes are dropped.

        For Cisco Nexus 3016, 3064E, 3064X, and 3048 platforms, packets smaller than or equal to 560 bytes are dropped.

        For the Cisco Nexus 3064PQ platform, packets larger than 769 or equal to bytes are forwarded.

        For 3016, 3064E, 3064X, and 3048 platforms, packets larger than or equal to 561 bytes are forwarded.

При чем тут FCS, если в режиме cut-through он не проверяется? И почему (при каких условиях) дропаются пакеты определенного размера?

 

 

2)

The store-and-forward mode activates automatically for a port when the switch identifies that the ingress rate is less than the switching capacity of the egress port. For example, when the port ingress rate is 1 GB, the switching capacity of the egress port is 10 GB. 

Почему буферизация пакетов включается при прохождении трафика с порта с меньшей емкостью на порт с большей емкостью? Разве наоборот не логичнее?

 

 

P.S. Буду признателен за любые мысли по теме. Вопрос изучается в рамках выбора альтернативы 2960S с более широкими возможностями работы с микроберстами (аплинк в свитче 10Г, а потребители 1Г).

[jffulcrum]

Немного обсуждалось в 

 Смотрите там, логику поймете. В целом, все это истории прошлого, по-большей части. В современном железе эффекты от CT надо в лабе искать

[Victor Tkachenko]

16 часов назад, jantao сказал:

При чем тут FCS, если в режиме cut-through он не проверяется? И почему (при каких условиях) дропаются пакеты определенного размера?

Обратите внимание на отступы в тексте, они намекают, что это часть условий для дропов кадров с ошибками в FCS.

Режим cut-through не отменяет проверку корректности FCS в общем случае, он лишь ограничен в возможности дропнуть кадр при наличие ошибок, так как они могут быть обнаружены позже начала передачи кадра в исходящий порт.

 

Суть в том, что процедуры match-action для заголовков требуют некоторое время. Грубо говоря, если весь кадр может быть принят коммутатором быстрее, чем заголовки кадра пройдут цепочку match-action юнитов на чипе, то может быть обеспечена сверка FCS до отправки кадра в исходящий порт. Таким образом дропы при некорректной FCS возможны для кадров размером не более X байт, где X зависит от задержек коммутации (то есть модели чипа / модели коммутатора).

[surgeon]

На самом деле проверяется, только уже на выходе. Т.е коммутатор увидел начало фрейма, начинает его двигать в выходящий интерфейс, тут замечает FCS ошибку и дроп идет уже на исходящем порту. Как сказали выше, все зависит от размера фрейма.
Минус в том, что при дропе на исходящем порту, вы не узнаете откуда идут плохие фреймы, придется включать store and forward