Усилване на сигнала?!?

Интересува ме как може да се усили сигнала след седмия switch? Знам за варианта с поставяне на линукски рутер, но се чудя няма ли по-удобен начин?
Всеки съвет ще е от полза!
10кс

По-добре безделник отколкото без празник!:))

А какъв е проблемът след седмия комутатор? Защо не със 8-и такъв?

Съществува така наречената "дълбочина на мрежата", т.е. след 7-мия switch се наблюдава известна нестабилност! Загуба на пакети, закъснения etc.

По-добре безделник отколкото без празник!:))

Каква ти е топологията на мрежата, нещо сбъркана ми се струва... Да не искаш да кажеш, че си навързал 7 суича в "Daisy-chain"? То си има физически ограничения, по-добре се държи "йерархична звезда".

Бе като правиш мрежа с такива размери, вземи турни един поне router де.
И я прави йерархична.
Има и по-добри решения за router от РС пригодено за целта.

Кратка сентенция...

E kak stawa taia rabota. Nali wseki switch regenerira signala, t.e. ne e kato HUB i bi triabwalo da ne stawa takuw problem totchno puk sus signala.

Той сигналът не затихва - и switch-ът и hub-ът са една купчина мрежови карти с процесор и малко памет и ретрансмитват, а не просто насочват на аналогов принцип.
В голяма мрежа проблемът при hub-овете е че губиш bandwith-а, понеже всеки hub умножава всеки пакет по много, а при siwtch-овете - че се объркват, понеже те се опитват да се държат като router-и, но не могат да се настройват, а се самообучават. Познай какво става, когато IP-тата и MAC адресите не са внимателно и прилежно подредени и сортирани по switch-ове и, не дай боже, когато започнат да се сменят :) На switch-а паметта въобще не е достатъчна, че да ги помни кой къде е. А като не знае кой къде е, или трябва да broadcast-ва и да се прави на hub, което никой switch не прави, или трябва да остави пакетите в опашката, докато намери целта на кой интерфейс му е, да обаче, ако целта е през 4 switch-а от там и поне единият от тях също не знае къде е, сети се колко време трябва да чака, а същевременно (нали не забравяме, че сме на голяма мрежа? С много трафик?) буферът за опашката на итерфейса е малък и се препълва. От тук нататък възниква единствено въпросът дали switch-ът да продължи търсенето на въпросната цел след като й е дропил пакетите, или изцяло да я зареже и да пожелае на изпращача повече късмет следващия път, което си е implementation specific.

Кратка сентенция...

Освен по този начин(с комп.) и истински router, друг начин знаеш ли?

бил много умен бе! почти като bridge, та даже и като рутер! и от ip-та разбира и от кво ли не! откъде го измисли бе, пич?

Абе защо само усложнявате нещата? Просто, казано по-балъшки, мрежата трябва да има дървовидна, а не верижна структура.

Проблемът идва от натрупването на закъснение.

Единствения компетентен коментар!!!

По-добре безделник отколкото без празник!:))

Е и?
Търся решение на проблема,не диагностициране!

По-добре безделник отколкото без празник!:))

Дай e-mail да ти пратя топогафията!!!!!!!

По-добре безделник отколкото без празник!:))

А що реши, че не съм сложил рутер?
И на всеки седми switch ли да слагам рутер? А?

По-добре безделник отколкото без празник!:))

Сигурен ли си?
Това е проблем при hub. Switch-а регенерира напално ethernet frames и не би триабвало да има подобен проблем...

Има съществена разлика м/у hub и switch. Докато hub-ът е Layer 1 устроиство и просто регенерира синала, то switch-ът е Layer 2 устройство, което не само регенрира електрически сигнала, но и регенерира ethernet frames - проверява им checksums etc. Типично е switches да приемат целия ethernet frame да проверят checksum, изходящ интерфейс и едва тогава да го препратят (store-and-forward). Със всеки що годе читав switch не би трябвало да има проблем с паметта в която съхранява научените mac addresses, тъй като е типично тази памет да е достатъчна за 4k mac addresses. Е, в интерес на истина не знаем в случая човека колко машини има, но се съмнявам да са хиляди...
Аз продължавам да не разбирам какъв е проблемът. Имам чувството, че става дума за някаква urban legend . А проблема може би е съвсем друг и няма нищо общо с броя на switches.

по-добре да си смениш заниманието или най-малкото да вземеш да попрочетеш малко. Не ми се обяснява в подробности, защото това го пише във всяко малко по-подробно въведение в ethernet, но разликата м/у hub и switch се свежда най-вече до начина на възникване и разпознаване на колиизите (в гугала пишеш collision domain и четеш). Почти всички лимити при ethernet мрежите се налагат именно от възможността да се разпознават колизиите. Ако използваш N-WAY/full duplex switch (който наистина практически има поведението на bridge) остава единствено ограничението за максимална дължина на един сегмент, както и (разбира се) теоретичното ограничение от 1024 сегмента в мрежата. Няма никакво значение колко точно switch-a ще наредиш и как - дори да са просто навързани един след друг структурата пак е дървовидна с един клон. Така че, ако имаш проблеми след седмия (или който и да е друг switch) - хващай клещите и търси проблема, а недей да търсиш "усилватели" на сигнала и други безумия.

10x
Хващам клещите!:))

По-добре безделник отколкото без празник!:))

1. Не съм виждал switch, който да не може да запомни поне 250 MAC адреса. Простио няма такъв. А ако имаш мрежа с повече от 200 машини в един brodcast сегмент, значи имаш проблем много по-сериозен от този как да си увеличиш броя на суичовете.

2. Всеки switch автоматично си трие таблицата на всеки 15-тина секунди. Ако междувременно пристигне пакет, за който не знае нищо, той се broadcast-ва. Пакети в switchовете не се дропват при препълване на mac таблицата, а само при изчерпване на bandwidth (буфер) на някой порт. Не бъркай паметта за mac адреси с тази за буферите.

Проблемът с многото стъпки е съвсем другаде. Има два начина, по които switch-овете препредават пакетите.

А: изпращането на пакета започва още с приемането му. Т.е. приел си един байт, изпратил си един байт, без да чакаш края на пакета за да провериш чексумите.

Б: изчакваш да получиш целия пакет, проверяваш го и после го изпращаш (store-and-forward).

Вариант А има недостатъкът, че препредава и колизиите. Затова в тези суичове има предвиден алгоритъм, който ги превключва автоматично в режим Б, когато броят на грешките надмине някаква граница. Както може да се очаква, това означава сложен процесор, повече памет и в крайна сметка - висока цена.

Та всички малки суичове, които се използват наоколо, са store-and-forward. При тях дефектът е в това, че изпращането на пакета започва след пълното му приемане. Ако имаш голяма верига от n суича, пакет с дължина X ще пристигне за време nX. Има някакви стандарти за това време и точно те се нарушават при твърде много стъпки. Но ако не ти пука особено за стандартите, може да си работиш и така. Третото ниво (ако е IP) ще се оправи с времезакъсненията.

Митко