ru.networks

 
 - RU.NETWORKS ------------------------------------------------------------------
 From : Ivan Voytas                          2:5020/400     24 Jun 2004  11:25:51
 To : Denis Volkov
 Subject : Re: Свитчи
 -------------------------------------------------------------------------------- 
 

 >  То, что IEEE ограничило диаметр STP-сети по умолчанию 7ю "хопами", не
 
 значит,
 
 Hеправильно нашел. :) Значения по умолчанию таймеров STP вычислены на
 основании предположения, что диаметр сети (кстати тоже понятие не такое уж
 очевидное ;) равен 7, в сети потеряется не более 3х BPDU, на обработку BPDU
 свитчу нужно не более 1й секунды и т.д. Значения - Hello Time, Forward
 Delay, Max Age регулируются по формулам, исходя из принципа "не знаешь - не
 трогай". Формулы очень впечатляющие. Могу закинуть, если надо :))
 
 >  что нельзя поставить сколько угодно свичей в ряд. Просто качество работы
 
 STP
 
 >  резко падает при увеличении размеров сети.
 
 "Резко падает" - это вплоть до постоянной перестройки STA и, как следствие,
 полной неработоспособности сети. Еще для любителей извращений можно путем
 изменений параметров добиться того, что перестройка вообще не будет
 заканчиваться.
 
 Еще про STP. Есть свитчи, в которых STP включается только на весь свитч,
 т.е. отключить отдельные порты нельзя. Это приводит к тому, что любой другой
 свитч (хакер Петя на линуксе) может сделать себя корнем STA или просто
 послать TCN BPDU, что вызовет перестройку всей сети (30 секунд при дефолтных
 таймерах). Hикакой защиты от этого нет.
 Это что касается STP. Его вообще-то можно отключить, если в сети нет петель.
 :)
 
 Идем дальше. Есть еще размер CAM-таблицы. При ее переполнении свитч
 превращается в хаб (грубое приближение). Ее размер на нормальных свитчах -
 4096 мак-адресов (всключая свои собственные). Hа говносвитчах (с)
 значительно меньше. Были даже мелкие китайские поделки, где один мак на
 порт.
 
 Идем дальше. Броадкасты. В нормальной сети их вроде бы немного. Hо не надо
 забывать, что свитчи при устаревании записи в CAM-таблице и при пересылке
 фрейма на неизвестный им мак-адрес рассылают его во все порты, кроме того,
 откуда он прилетел (тут еще одна крупная засада). При увеличении размеров
 сети количество броадкастов в каждом сегменте растет быстрее, чем собственно
 размер.
 
 Идем дальше. Про крупную засаду, упомянутую выше: если вдруг какой-нибудь
 говносвитч (с) решит отправлять фрейм во все порты (в том числе туда, откуда
 получил), то это приведет к неработоспособности _всей_ сети (симптомы похожи
 на наличие петли). Такое замечено за Surecom и еще какой-то гадостью. Причем
 выловить это в большой сети в сжатые сроки не представляется возможным.
 
 Идем еще дальше. Механизм коммутации (Cut-Through, Store-And-Forward,
 Fragment-Free). Тут не скажу однозначно, но что-то мне подсказывает, что
 китайские друзья в целях экономии используют первый метод, который приводит
 к пересылке обломков и огрызков. А если случайно где-то есть несовпадение
 дуплекса (не подружились surecom, 3com и microsoft.com например :), то
 коллизия может случиться в поле мак-адреса, что приведет к появлению двух
 вещей: неизвестного в сети мак-адреса и битого фрейма, который замечательно
 разброадкастится по всей сети (имеется в виду, что на принимающей стороне
 включился full-duplex и принимающий свитч коллизий не обнаруживает).
 Hеизвестные мак-адреса будут каждый раз разные, что переполнит нафиг
 CAM-таблицы всех свитчей (мы же говорим про действительно большую сеть,
 правда? ;), превратит их в хабы. Работа в такой сети приведет наконец к
 непосредственному объективному пониманию, что фраза "свитчей в сети может
 быть сколько хочешь" нуждается мягко говоря в уточнении :))
 А с точки зрения математики и простой человеческой логики является бредом.
 
 P.S. Ухх, аж устал. Работа стоит, а тут блин эссе писать надо. :))
 --- ifmail v.2.15dev5.3
  * Origin: Demos online service (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    Свитчи   Alexandr Thibizov   13 Jun 2004 10:02:00   Свитчи   Artyom Voronchihin   14 Jun 2004 21:45:08   Re: Свитчи   Ivan Voytas   15 Jun 2004 11:07:00   Свитчи   Sultan Azhiguzhayev   19 Jun 2004 20:03:09   Свитчи   Sergey Dorozhkin   21 Jun 2004 01:27:54   Re: Свитчи   Ivan Voytas   22 Jun 2004 10:56:19   Свитчи   Denis Volkov   23 Jun 2004 00:50:00   Re: Свитчи   Ivan Voytas   23 Jun 2004 10:30:05   Свитчи   Denis Volkov   23 Jun 2004 23:54:25   Свитчи   Denis Volkov   24 Jun 2004 01:49:10   Свитчи   Alexander Gusak   24 Jun 2004 10:42:28   Re: Свитчи   Ivan Voytas   24 Jun 2004 11:25:51   Re: Свитчи   Sergei V.Dubrov   24 Jun 2004 11:56:44   Re: Свитчи   Ivan Voytas   24 Jun 2004 12:06:35   Re: Свитчи   Andrey Ivanov   24 Jun 2004 12:10:42   Свитчи   Denis Volkov   24 Jun 2004 23:36:55   Re: Свитчи   Ivan Voytas   25 Jun 2004 11:48:51   Свитчи   Denis Volkov   25 Jun 2004 22:11:02   Re: Свитчи   Alexander Gusak   25 Jun 2004 10:34:15   Re: Свитчи   Ivan Voytas   25 Jun 2004 11:21:31   Re: Свитчи   Alexander Gusak   25 Jun 2004 21:20:08   Re: Свитчи   Ivan Voytas   28 Jun 2004 11:03:59   Re: Свитчи   Alexander Gusak   28 Jun 2004 20:47:53   Re: Свитчи   Ivan Voytas   29 Jun 2004 10:19:54   Re: Свитчи   Alexander Gusak   29 Jun 2004 11:11:55   Свитчи   Denis Volkov   30 Jun 2004 20:55:04   Re: Свитчи   Ivan Voytas   24 Jun 2004 12:20:29   Re: Свитчи-2   Dmitri Zubko   14 Jun 2004 20:10:36