Статья Строим Локальную Сеть

[Admin]

Все чинится, главное найти точно точку повреждения

Вот как починить разорванное оптоволокно - знаю :!: По стандартам :!:
А как медь поврежденную по стандартам восстановить - не знаю
А есть ли такие стандарты?

Для сращивания медного UTP кабеля необходимо использовать специальные кроссы. Больше всего мне нравятся 50 парные кроссы производства АМР. Кстати, они полностью соответствуют всем параметрам предъявляемым к 5 категории (в отличии от "телефонных" кроссов производства Krone). Уже несколько лет многие производители (в основном Тайваньские) начали выпуск "клонов" этих замечательных кроссов.

А вот мне идея пришла по поводу ремонта одного медного линка - использовать для этих целей розетку 5 категории. Лучше двойную. Кабель в месте разрыва заделывается в двойную розетку и гнезда RJ-45 соединяются коротеньким патчкордом. Получается все по науке - 5 категория на всем протяжении. Это по способу Igoras, только розетка двойная, чтобы в одном конструктиве получилось. Еще можно подумать и обойтись пез патчкорда запаяв (скроссировав) перемычки из витых пар прямо внутри двойной розетки. Только будет ли это соответствовать 5 категории?
Ну или проще - отрезается от многопарного вышеупомянутого кросса кусочек на 4 пары, разделываются пары один в один - и тоже все правильно. Только коробочка защитная не помешает.
Как вам такие технологии ремонта?

[Vitalik]

Начнем, наверное, сначала с количества свичей в сегменте. Могу на примере своей домашней сети показать, что в одном сегменте нормально моуг работать 11 свичей последовательно подключенных и еще 4 свича в ветвях.
При пинге с одного конца в другой все нормально потерь нет. Есть тока одна маленькая проблема. Если переглючивает хоть один свич то ложится вся сеть. Переглючивает тока из-за сгорания портов. Лечится это (по крайне мере я так делаю) вставкой в сгоревший порт куска кабеля с конектором , а с другой стороны простым скручиванием между собой 1 пары и скрутка второй пары. После этого свич начинает нормально функционировать.
Ограничения на количество хабов относится с хабам первого уровня. Для свичей это ограничение имеет гараздо больший придел. К сожелению точной информации по этому поводу нигде нету. А то, что НР написал для своих хабов 95 года производства как то не очень, наверное, применят к свичам даже 2002 года выпуска.
Но это, конечно, не значит, что так надо использовать. У меня в планах с ближайшее время разбить сеть на сегменты.

Далее насчет обрыва кабеля. Самое лучшее решение это спайка кабеля в месте разрыва. Это исключит окисление меди и ухудшения контакта в дальнейшем. У нас один кусок линка длиной 118 метров. В нем как-то был обрыв. Мы его спаяли и хорошенько все заизолировали. Весит уже второй год и никаких проблем.

[RDS]

...А то, что НР написал для своих хабов 95 года производства как то не очень, наверное, применят к свичам даже 2002 года выпуска...

HP писал "о не более 7" не для хабов, а именно для бриджей, мостов, свичей, комутаторов.
И еще, ответь мне, как комп отправивший пакет узнает, что этот покет успешно получен компом-получателем и отправленный пакет не надо отправлять повторно? И через какое время не получив подтверждение получателя отправится повторно пакет?

[Vitalik]

Я сейчас специально сделал пинг компа на 3 хабе от меня . наибольшее время 16мс среднее время 9 мс. Ни одной потери ,100 запросов.
И самого дальнего, т.е. 11 хаб, максимально 32мс среднее 19 мс.
Я прекрасно помню что по инструкции е должно быть больше 4 хабов сегменте. Но все тоже но. Пока все работает. В принципе по любому я буду делить сетку на сегменты и это не далекое будущее в вопрос максимум пары недель. Прост так получилось, в виду экономических проблем, что мы достигли 11 хабов но пока не поделились на сегменты.

[Igoras]

Переглючивает тока из-за сгорания портов. Лечится это (по крайне мере я так делаю) вставкой в сгоревший порт куска кабеля с конектором , а с другой стороны простым скручиванием между собой 1 пары и скрутка второй пары. После этого свич начинает нормально функционировать.

Не совсем понял, это че порты сгоревшие от этих действий работать начинают? :? тогда рецепт плс поподробнее, а то не совсем понял...

Далее насчет обрыва кабеля. Самое лучшее решение это спайка кабеля в месте разрыва. Это исключит окисление меди и ухудшения контакта в дальнейшем. У нас один кусок линка длиной 118 метров. В нем как-то был обрыв. Мы его спаяли и хорошенько все заизолировали. Весит уже второй год и никаких проблем.

Я писал уже тут где-то, что спайка не помогла, спайка была очень аккуратной, новый кусок продолжал завивку старого, даже постарался место спайки не раскручивать сильно, а после спайки закрутил назад, но линка не было, вернее аппаратно он вроде был, показывало 100 мегов, фулл дуплекс, но пинги не шли...

И еще такой вопрос - "у нас" (т.е. у вас) это где?

Ну а сегментация сетей с помощью роутеров не спасет от того, что упадет какой-то хаб или роутер (пока кольца не сделаете)... да и не падает у меня ничего, если с хабом глюки, просто сеть превращается в 2 изолированных сегмента - до хаба и после, страдают только те, кому непосчастливилось висеть на том хабе..

[Vitalik]

Извиняюсь, не представился. У нас это в Аэропорту. Сеть называется arplan. Зовут меня Виталик
Далее насчет портов. Порт не начинает работать. Зато теперь он не вешает весь хаб. У вас не было такого, что сгорает один из портов и перестает работать весь хаб ? И если вытащить все линки из хаба то порт все равно продолжает светиться. Как будто в нем активный линк. Не факт что хаб полностью выходит из строя. У меня были случаи, когда он продолжать исправну жужжать на оставшехся портах. Но были случаи, когда все кто подключен к нему имели 100 % потерь. Лечилось, как я уже описывал выше. После кз 1 и 2 пары лампочки тухнут и хаб начинает нормально функционировать.

Далее насчет спайки. У нас на донный момент есть 2 кабеля, которые работают уже не один год. Один имеет длину 118 метров. И второй примерено 90 метров. Второй я вообще спаивал в -15 С когда нам один умник его обрезал.

Далее насечет кольца. Просто у нас такая топология сети, что кольцо можно организовать только двумя способами
1. Кинуть оптику
2. Радио модем
А на данный момент мне нужно просто поставить несколько роутеров чтобы разбить на сегменты до 4 хабов в сегменте.
У нас 2 раз были случаи, когда подвешивался хаб и из за этого ложилась вся сеть. Наверняка скажут что это от того что у вас много хабов в сети . Могу сразу разочаровать. Первый раз это было когда в сети было 6 хабов. Просто пакеты уходили в никуда, не зависимо от местоположения в сети. Так что от этого спасут толь роутеры

[Igoras]

На данный момент у меня в сети из 6 хабов на магистрали (свитчинг хабы) у трех есть полетевшие порты, все из-за того, что нет грозозащит на них, как только будет возможность, постараюсь их сделать, хабы продолжают вполне исправно работать на остальных портах, ситуации с активным линком при отсутствии кабеля не видел, зато был баг, когда на одном конце сгорел порт, на другом хаб стал показывать линк на 10 мегов (в любом порту), когда пошел посмотреть на тот хаб со сгоревшим портом, его глюкнуло так, что он показывал во всех портах фулл дуплекс, даже в тех, которые не подключены вообще... решилось обычным ресетом хаба
Спайка на 118 метров - какие хабы там по краям и какая скорость??

И очень странно, что ложилась ВСЯ сеть при подвисании хаба, разве что там реально хабы (не свитчинг) и они просто усиливают сигнал, тогда конечно нужны или роутеры или хотя бы свитчинг хабы между ними, а пакеты в пределах одного хаба (свитча) не могут уходить никуда - они идут с порта отправителя на порт получателя, непосредственно подключенных к этом хабу.. кстати почему 4 хаба? 4 хаба было в стандарте 10Base-T, в 100Base-TX осталось 1 или 2 хаба в зависимости от его класса, если юзать свитчи или хотя бы свитчинг хабы предела _теоретически_ нет... что и обсуждалось на двух предыдущих страницах

[Vitalik]

У нас везде стоят Switching Hub как правило X-Net. То, что у тебя решилось простой перезагрузкой это хорошо. В принципе те хабы что имели сгоревший порт тоже лечились перезагрузкой. Но их иногда опять переклинивало. Есть делать, как я писал выше, то гарантированно работают без каких, либо проблем. Линк стоит между Switching Hub X-Net 8 prot и Switching Hub 5 port. Скорость 100мб фул дуплекс. Да и еще эти оба хаба запитаны удаленно по другим кабелям, которые имеют протяженность 108 и 99 метров.

И я боюсь не из-за ограничений. Как я писал выше у меня и так все работает. Я хочу разделить сеть на сегменты для повыше надежности и безопасности. Да и контролировать пользователей легче станет. Да и самим пользователям я думаю лучше. в случие их взлома я буду знать более конкретно кто мог это сделать. А так я знаю людей кто мог бы сделать а наказать не получится.

[Igoras]

1) Может стоит все же поставить грозозащиты чтобы порты не летели?
2) А каким образом осуществляется питание на такое большое расстояние?

А чтобы иметь статистику по юзверям можно поставить пару свитчей с мозгами и пусть они ее собирают, или хочешь на роутере сниффер поставить?

[Vitalik]

1 Начет грозозащиты я в курсе. Вот найду, кто мне платы протравит тогда и спаяю. Я думаю, за недельку управлюсь.
2 Питание осуществляется по незанятым парам в кабеле. По ним подается 36 вольт, которые возле хаба понижаются до 14 вольт. Если очень интересует схема могу выслать.
У нас так работают 3 хаба. И еще 2 тоже придется так запитать.
3 Мне не нужна статистика, мне просто нужно разделить на сегменты и запретить присвоение себе ip и чужих сегментов. И также как можно сильнее усложнить жизнь любителям посниферить.

[Igoras]

1. Мне бы найти разрядники с супрессорами, спаял бы уже Схемы бы наверно нашел чем протравить, FeCl3 кажется, и кажется у меня оно есть
2. 36в переменный или постоянный? у меня по витой паре запитаны 3 хаба, правда там расстояние от хаба до розетки не больше 20-25 метров, поэтому просто пустил питание от родных БП от этих же хабов, все работает нормально...
3. есть такая вещь - свитчи 3 уровня, они в принципе роутеры по каждому порту присвоение IP решается ну хотя бы привязкой к MACам, хотя это конечно очень ненадежно, но хоть как-то.... сниффить в сети со свитчами можно только броадкасты/мультикасты и пакеты, которые направлены тебе Зато в роутерной сети сразу появляется куча проблем с локальными чатами и кучей игр, которые обычно находят сервера через броадкаст..

[RDS]

...Мне бы найти разрядники с супрессорами, спаял бы уже Схемы бы наверно нашел чем протравить, FeCl3 кажется, и кажется у меня оно есть
...

Цепочка из 8 диодов в прямом направлении успешно заменит супрессор на 5,6 вольта. Неоновая лампа, тот-же разрядник, правда очень маломощный (от статики спасет на 100%). Если поставишь неонку, то запаралель ее разрядником из дорожки на плате, с тонким зазором посередине (чем тоньше зазор, тем лучше). Пока будешь искать оригинальные компоненты, воздушки твои будут боле-менее защищены...

P.S. Давайте обсуждать это в другой теме, пока Админ замечание не сделал!

[Andragen]

HP писал "о не более 7" не для хабов, а именно для бриджей, мостов, свичей, комутаторов.
И еще, ответь мне, как комп отправивший пакет узнает, что этот покет успешно получен компом-получателем и отправленный пакет не надо отправлять повторно? И через какое время не получив подтверждение получателя отправится повторно пакет?

Насколько я понимаю,хабы повторители , свитчи это лишь среда передачи даных,в лучшем случае они могут работать только с ip- протоколом(по крайней мере свитчи и smart hub воруют с него mac и ip адреса),ip- протокол это самый низкий протокол ,да он действительно не проверяет доставлен ли пакет или нет,но ведь над ним есть надстройка tcp-протокол насколько я знаю этот протокол ужё проверяет правильность доставки пакета в нём есть поля контрольной суммы,так вот если через базовый промежуток времени не приходит ответ о том что пакет благополучно доставлен то посылается новый, и увеличивается время ожидания посланого пакета и так несколько раз или пока покет не прийдёт или сообщение о том что нет связи,это его плюс и одновремено минус потому что весь последующий промежуток времени обмен пакетов будет происходить с той же задержкой,таким образом получаем что в теории нет большой разницы стоят у тебя 7 свитчей подряд или 57,так как задержки в сотые сикунды будут проглатываться скорость обмена информации соотвесвенно снижается,но то же самое будет происходить если у тебя будут стоять роутеры задержки даже увеличаться из-за того что роутеры уже "понимают" протоколы высокого уровня ,то есть могут делить пакеты не только по мак и ip адресам но и по другим критериям,что в свою очередь требует значительной затраты процесорного времени,а следовательно и времени реального, если что не так поправьте как говорится я не волшебник я только учусь

[Гость]

Насколько я понимаю,хабы повторители , свитчи это лишь среда передачи даных,в лучшем случае они могут работать только с ip- протоколом(по крайней мере свитчи и smart hub воруют с него mac и ip адреса),ip- протокол это самый низкий протокол ,да он действительно не проверяет доставлен ли пакет или нет,но ведь над ним есть надстройка tcp-протокол насколько я знаю этот протокол ужё проверяет правильность доставки пакета в нём есть поля контрольной суммы,так вот если через базовый промежуток времени не приходит ответ о том что пакет благополучно доставлен то посылается новый, и увеличивается время ожидания посланого пакета и так несколько раз или пока покет не прийдёт или сообщение о том что нет связи,это его плюс и одновремено минус потому что весь последующий промежуток времени обмен пакетов будет происходить с той же задержкой,таким образом получаем что в теории нет большой разницы стоят у тебя 7 свитчей подряд или 57,так как задержки в сотые сикунды будут проглатываться скорость обмена информации соотвесвенно снижается,но то же самое будет происходить если у тебя будут стоять роутеры задержки даже увеличаться из-за того что роутеры уже "понимают" протоколы высокого уровня ,то есть могут делить пакеты не только по мак и ip адресам но и по другим критериям,что в свою очередь требует значительной затраты процесорного времени,а следовательно и времени реального, если что не так поправьте как говорится я не волшебник я только учусь

это резко бросается в глаза... Но в целом верной дорогой идете товаришь - только вот еще немножко подучить теорию, в виде семиуровневой модели OSI да разобраться какой протокол на каком уровне работает и можно уже будет совсем серьезно постить в данный и другие форумы... Так скать авторитетно глуша своими сетевыми знаниями окружающее ламерьЁ.

[Andragen]

это резко бросается в глаза... Но в целом верной дорогой идете товаришь - только вот еще немножко подучить теорию, в виде семиуровневой модели OSI да разобраться какой протокол на каком уровне работает и можно уже будет совсем серьезно постить в данный и другие форумы... Так скать авторитетно глуша своими сетевыми знаниями окружающее ламерьЁ.

Ну вроде правильно написал,по крайней мене я так понял читая умную книженцию "Семенова",может мне в универе чо втолкуют на следующем курсе(я выбрал специализацию сети),я не претендую на достоверность моих слов я лишь проанализировал инфу полученую из разных источников в том числе и из выше упомянутого,так что если что не так поправьте,ведь вы тоже не сразу спецами стали

[RDS]

...ip- протокол это самый низкий протокол ,да он действительно не проверяет доставлен ли пакет или нет,но ведь над ним есть надстройка tcp-протокол насколько я знаю этот протокол ужё проверяет правильность доставки пакета в нём есть поля контрольной суммы,так вот если через базовый промежуток времени не приходит ответ о том что пакет благополучно доставлен то посылается новый, и увеличивается время ожидания посланого пакета и так несколько раз или пока покет не прийдёт или сообщение о том что нет связи,это его плюс и одновремено минус потому что весь последующий промежуток времени обмен пакетов будет происходить с той же задержкой,таким образом получаем что в теории нет большой разницы стоят у тебя 7 свитчей подряд или 57,так как задержки в сотые сикунды будут проглатываться скорость обмена информации соотвесвенно снижается,но то же самое будет происходить если у тебя будут стоять роутеры задержки даже увеличаться из-за того что роутеры уже "понимают" протоколы высокого уровня ,то есть могут делить пакеты не только по мак и ip адресам но и по другим критериям,что в свою очередь требует значительной затраты процесорного времени,а следовательно и времени реального, если что не так поправьте как говорится я не волшебник я только учусь

Ты сам почти ответил. Подтверждение, о принятом пакете, может выдать только компьютер получатель или роутер, но никак не свитч! Имеем: время повторной отправки пакета (не дождавшись подтверждения), время задержки пакета при проходе свича, время прохождения сигнала в медном кабеле. Нетрудно подсчитать максимальное расстояние между отправителем и получателем. Если реальное расстояние больше, то необходим роутер. Все просто. Заявления о неограниченном количестве свичей в цепочке - только догадка некоторых "специалистов".

[Igoras]

Нет, оно скорее всего даже будет работать, т.к. как тут сказали - протокол TCP умеет подстраиваться под качество линии и менять скорость канала и к примеру размер окна, но вот будет ли оно работать на максимально возможной скорости? и как быть с протоколом UDP, который работает по датаграммному принципу, т.е. никаких подтверждений от получателя в самом протоколе не предусмотрено - тут уже стабильности никакой не будет, а ведь UDP - это тот самый протокол по которому работает большинство чатов и игрушек...

но то же самое будет происходить если у тебя будут стоять роутеры задержки даже увеличаться из-за того что роутеры уже "понимают" протоколы высокого уровня

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

[Гость]

Ты сам почти ответил. Подтверждение, о принятом пакете, может выдать только компьютер получатель или роутер, но никак не свитч! Имеем: время повторной отправки пакета (не дождавшись подтверждения), время задержки пакета при проходе свича, время прохождения сигнала в медном кабеле. Нетрудно подсчитать максимальное расстояние между отправителем и получателем. Если реальное расстояние больше, то необходим роутер. Все просто. Заявления о неограниченном количестве свичей в цепочке - только догадка некоторых "специалистов".

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

Похоже, что мы с Вами по разным учебникам учились - я с Вас просто удивляюсь...

Во превых - Рутеры это устройства Сетевого уровня - протокол IP это протокол сетевого уровня. Протокол без установления соединения, первичный транспортный протокол в стеке TCP/IP. В задачи IP входит:
1 Адресация - 32 разрядное адресное пространство...

2 Упаковка - IP предоставляет пакет, если не ошибаюсь, в официальной терминологии называемый датаграммой. Формат пакета (по памяти - некоторые поля не на своем месте)
14 полей
*Версия
*Длина всей датаграммы
*Тип сервиса
*Длина поля данных
*ID датаграмы
*Биты фрагментации
*Смещение фрагмента
*CRC заголовка датаграмы без учета данных
*TTL
*Протокол данные которого переносятся
*IP получателя
*IP отправителя
*Опции
*Данные

3 Фрагментация

4 Маршрутизация

В задачи IP не входит не подтверждение получения не ввообще какие-нибудь подтверждения. Кстати всеми любимый протокол ICMP разработан как раз еще и для того чтобы информировать системы о ошибках на сетевом уровне т.к. IP такой функции не выполняет - ему пофиг с какими данными он работает - у него 4 задачи - все остальное задачи других протоколов в стеке.

На транспортном уровне работают два протокола - TCP и UDP. Вообще же в задачм протоколов данного уровня входит:
1 Идентификация процессов через номера портов 0-65535 (оба)
2 Контроль ощибок CRC (оба)
3 Сегментация и востановление данных (только TCP)
4 Управление потоком (только TCP)
5 Подтверждение прибытия и организация повторной передачи. (только TCP)

Заголовки TCP и UDP я помню - 12 и 4 поля соответственно - но приводить их мне лень - RFC есть кому интересно.

TCP протокол с установление соединения, UDP без. Какой из них использовать - выбирает Сетевой программист когда свою прогу кропит. Вот чтобы данный передавать нужно TCP использовать т.к. только с его помощью можно быть уверенным в доставке и качестве. А вот UDP например применяют когда не надо никаких гарантий - когда ответ является подтверждением - DNS транзакция request - reply, и еще при широковешинии...

Это все теория - делайте выводы. Если мне не верите - читайте RFC.

Исходя из этого то, что вы нвписали о том, что рутеры подтвержения шлют - это не правильно. И еще Вы рассматриваете время ожидания подтверждения как константу - будет задержка бодльше этого времени - все, хана сети. Эта величина НЕ КОНСТАНТА - она устанавливается в момент установки логического соединения, и если не ошибаюсь, в процессе соединения может пересогласовываться.

И еще. Ethernet - протокол Канального уровня без установления соединения. Он состоит из 3 частей - Кадр, Механизм доступа к среде, Набор нормативов физ. уроня.
Его задачи:
1 Адресация в пределах области широковещания по МАС адресам
2 контроль ошибок
3 идентификация протокола данные которого переносятся
3 Обеспечение доступа к среде

Формат пакета 802.3
*преамбула
*начальный разделитель
*адрес получателя
*адрес отправи теля
*длина
*LLC
*Данные
*CRC

это так, для кучи - мож интересно кому...

[Igoras]

Да, да, ошибся, действительно, теорию давно не читал, все в последнее время по практике, просто роутеры обычно выполняют функции брандБауэров ( ), которые работают уже на более высоком уровне, или шлюзов в инет с НАТом... ну тут уже ограничение на число хабов не возникает... скорее всего ограничение в 7 хабов - это рекомендация, просчитанная спецами из HP, чтобы сеть могла работать стабильно, а не тратить половину свего траффика канального уровня пересылкой пакетов, которые будут считаться потерянными, да и после установки соединения со стабильными параметрами это соединение не будет с максимально возможной скоростью, которую может обеспечить данный канал при его текущей загрузке

[Гость]

Давайте все таки обьявим переменные:

тема осуждения = "максимальное количество СВИТЧЕЙ";

свитч = "Он же коммутатор, устройство разделяущее сеть на несколько областей коллизий, но оставляющее в единой области широковещания - принцип работы: получил пакет, буферезовал пакет в память, сверился с адресной таблицей, передал через нужный порт. В случае нахождения ошибок - откинул пакет. В случае возникновения коллизии при передаче (если сеть полудуплексная) как и обычная система - повторить передачу";

максимальное количество хабов 2 уровня = 2;

должны ли хабы умереть = "должны. мы тут о свитчах говорим";

область коллизий = "физическая среда используемая многими системами для передачи своих данных. Среда узкополосная. При передаче данных оной из систем ни одна другая система не может передавать своих данных, а должна ждать пока среда не освободится от передаваемого пакета.";

Коллизия = "столкновение пакетов возникающее в узкополосной среде, работающей в полудуплексном режиме - при этом данные считаются потерянными и передающая система предпринимает новую попытку передачи данных";


А теперь после того как тема законкречена сново - переобоснуйте пожалуйста утверждение, что "Максимальное количество последовательно соединенных свитчей (устройств разделяющих сеть на несколько областей коллизий) ОГРАНИЧЕНО ОБЬЕКТИВНЫМИ ПРИЧИНАМИ или официальными руководствами". Приведите эти причины. Докажите используя теорию и, по возможности, приведите пример "из жизни" когда вам довелось столкнуться с данным ограничением.

Сразу приведем одно из объективных ограничений - максимально количество систем в области широковешания. Это понятно, что слишком много бродкастовых пакетов просто завалят системы вынужденные их обрабатывать. Для простоты давайте рассмотри следующую конфигурацию: два компьютера соединенные между собой с помошью 100 свитчей подключенных последовательно. Длина всех сегментов 100м. Длина всей сети 10100м.

Пожалуйста - задача поставлена.

[Igoras]

Для простоты давайте рассмотри следующую конфигурацию: два компьютера соединенные между собой с помошью 100 свитчей подключенных последовательно. Длина всех сегментов 100м. Длина всей сети 10100м.

А вот и ответ: viewtopic.php?t=89 По стандартам TCP/IP оно может и будет работать, но любой сетевой программист указывает время таймаута, после которого будет считаться, что хост не отвечает, максимальное время, на прикладном уровне, TCP не будет его увеличивать

[Гость]

Если программист Сетевой, а не веб, то он то это должен учитывать и использовать в своих программах то, что предоставляет стандартный ТСР/IP стек. Иначе Весь интернет бы уже давно загнулся. Ведь при связи через Инет не редко, когда задежки исчисляются совсем не в 10, а то и 100 или 1000 мил.сек.

- меня аргумент не убедил.

[Igoras]

скорее всего ограничение в 7 хабов - это рекомендация, просчитанная спецами из HP, чтобы сеть могла работать стабильно, а не тратить половину свего траффика канального уровня пересылкой пакетов, которые будут считаться потерянными, да и после установки соединения со стабильными параметрами это соединение не будет с максимально возможной скоростью, которую может обеспечить данный канал при его текущей загрузке

больше вряд ли что смогу предложить

з.ы. зарегистрировался бы хоть что ли...

[Andragen]

Насчёт протокола Utp да он действительно не проверяет доставку пакета, но внём нет ограничений на задержку,и следовательно для сети состоящей из n-го количества свитчей он будет работать также как в сети стоящей из 1 свитча с той лишь разницей что будет задержка а на скорость это повлиять не должно(если идёт поток даных только в одну сторону )
Насчёт работоспособности сети состоящей из n свичей, мне кажется количество свитчей не ограничено,ограничено количество пользователей сидящих на этих свичах(это из-за обьёма памяти свитчей на мак адреса,когда память переполняется свитч работает по принципу свитчей то есть расылает пакеты во все порты акромя того с которого пакет пришёл)можно даже посчитать приблизительное количество пользователей на примере распостранёных китайских хабов, у которых обьям памяти на мак адреса составляет 2 килобайта.
2кб=2048 байт
1 mac адрес занимает 6 байт,я осмеюсь предположить что тратится ёщё один байт на то чтобы узнать к какому порту свитча принадлежит этот mac адрес , и того на одного клиента получаем 7 байт памяти
2048/7= 292 пользоателя, что довольно много ну подсчёт довольно грубый так как я не знаю внутренего строения свитчей и скока точно занимает один мак адрес в памяти свитча.
У кого какие идеи ещё есть.
Так как правило в 7 свитчей, в нашей сети уже нарушено у нас их 16 кажется и ничо вроде работает ,я даже на hub.ru читал что в москве в одном сегменте находится 56 свитчей,не знаю правда неправда , но я склонен верить.

[Igoras]

Эх, жалко я не работаю в каком-нибудь ниппоне - взял бы 100 свитчей, 101 патч-корд и посмотрел, как эти 2 компа будут пинговаться через эти 100 свитчей