Jugernault

Опа! 8-0 А говорите что топик себя исчерпал, а тут такие перлы... :)Пожалуйста приведите мне ссылочку на любую документацию где сказано что в эзернетской витой паре (не будем уточнять способ ее "шилдения") повив проводников в одной паре различен для разных пар. Т.е. две из четырех пар повиты с шагом 2.5 витка на дюйм, а остальные с другим шагом. Как по мне так имхо это бред...

IMHO это не повод для прокладки экранированного кабеля. Он вообще то для других целей экранирован.То что вы нарушили требования по укладке кабеля связи это понятно - но я не думаю что 15 метров однофазной силовой проводки в непосредственно близости с кабелем связи могли оказать значительное влияние на последний. Ну а если у Вас под фальшпотолком еще и трехфазник лежит - тады Ой... ;) Вот тут пожалуйста подробней - как был обжат кабель? По цветам с двух сторон пожалуйста. И как и главное куда он был заземлен. То то и оно, что когда кабель смотан в бухту линку должно быть хуже - индуктивное сопротивление кабеля сказываться начинает. А у Вас как то все наоборот - странно это... В любом порядке можно обжимать на любых дистанциях - единственное условие что бы при кросовом кабеле пара 1-2 оканчивалась на 3-6, а пара 3-6 на 1-2, 4-5 на 4-5 и 7-8 на 7-8. Как Вы это сделаете по цветам это только Вам решать - придерживаться стандартов (правил хорошего тона) или нет. Лично мне кажется что у вас была допущена "распаровка" и даже при минимальных наводках от силового кабеля результат не замедлил сказать. А когда вы его сматывали - наводки пропадали, и коммутаторы работали не смотря на "распаровку" - дистаниция 30 метров даже на распарованом кабеле пробивается нормально если неt внешних факторов. p.s. Дабыхм запомнили на всю жизнь - вот Вам талмудка:

Ну и?

Да вполне реально...Попытаться вышемить таковых индивидуумов может помоч arpwatch

Чудак человек... :)Мне было бы интересно взглянуть как Вы ан однм тазике скрестите бридж и маршрутизатор. У вВас мимум интерфейсы должны быть тогда из одной подсети, да и сеть должны быть одна. А это их бин нонсенс... Так что верно говорят - выделенные сервера и раскрутка их адресов на местном портале...

Хм... Т.е. Вы хотите коллизионный домен эзернета порвать на куски маршрутизаторами, при этом сохранить ту же саму адресацию на уровне IP и при этом хотите, что бы броадкасты из конца в конец этой сети летали? В данном случае нужно смотреть в стороноу софтовых бриджей, но как по мне то Ваше желание странное... Вы же сами рвете коллизионный домен, а потом его же клеить пытаетесь...

Лично мне подобная схема не удалась. Правда я пробовал тестовую реализацию делать на 841 Зикселях + пара HP2626.

v-m-k Ну уж поверь, в данному случаю маркировка абсолютно не причем... Пока клиент не выдаст на гора результаты вывода тех комманд что я перечислил, ничего понять нельзя будет. Слишком сумбурно изложены условия. Вот здается мне что правило ip rule add from EXT_IP table T1 в данном случае лишнее. Но опять же не берусь судить пока не увижу полной картины.

Действительно...Потому что хоть кол на голове теши, а у тебя канал как был асинхроннмм, так и остался в словосточетаниях... АССИМЕТРИЧНЫЙ ОН, А НЕ АСИНХРОННЫЙ!!! ;) Т.е. понимания не прибавилось...

v-m-k Не заработало потому что кэш не сбросили... ip route flush table cache

хинт: канал надо делать 4вх/1исх , т.е. 128/32 или 256/64. А почему не 1 к 1-му? ;)

Оносительно правильности я бы очень очень усомнился... Но сомнения мои были бы не технической стороной вопроса, а маркетинговой. Насколько я понял из Ваших писем, Вы предлагаете продавать клиенту канал шириной 128К/с суммарно, т.е. сумма полосы входа + полосу изхода = 128К/с. При этом что бы реально пропускная способность канала могла перекоситься и в ту и в другую сторону полностью автоматически, но при этом сумма все равно оставалась бы 128К/с. Т.е. назвать это можно ассиметричным дуплексным каналом с динамическим шейпингом по направлениям и суммарной пропускной способностью в 128К. - вот это бы было честно. А то что вы называете каналом в 128К у нас зовется симметричным каналом в 64К. При этом Вы кривите душой называя то, что продаете, каналом в 128К - пользователь из него никогда не получит 16кб/с при закачке по фтп. Я не берусь обсуждать текущую ситуацию на Вашем рынке и конкурентоспособность этой услуги. Но для нашего региона такая услуга не пошла бы - не привык народ к таким махинациям. Пару лет назад у нас вовсю практиковались ассиметричные каналы, типа 128К на 32К и т.д. Сейчас это кануло в лету. А почему? - Да потому что если магистральщик продавал ассиметрично, то и вторичные и третичные провайдеры тоже следовали этому принципу. Сейчас у нас магистральщики даже по траффику не очень то продают. Только симметричные полосы. Ну и остальные так же себя ведут - никакой ассиметрии. Это конечно похвально... Но что ни говори - Вы хотите странного... Продать 64К симметрии под видом 128К. Возможно именно по этому не смогли найти нормального решения под Линукс. Впредь я бы попросил Вас излагать свою мысль менее сумбурно - не торопитесь ответить, времени у нас много... В сказаном Вами я увидил, что Вы самостоятельно дошли до истины, что мегабит + мегабит не равно два... :) А всего лиш полтора, а то и меньше... :) В этом я Вас разубеждать пожалуй не буду. Все зависит от конкретной ситуации. У меня есть ряд клиентов которые "выедают" свою полосу с коэффициентом среднемесячной загрузки на 85-90%. Но ведь такие не все и по этому 1+1 не равно 2. Ну конечно же Linux Advanced Routing & Traffic Control HOWTO. Ну и пример в решебнике про противодействие синфлуду. В нем как раз видно как ограничить трафик на входящем интерфейсе со стороные клиента. HTB позволяет подходить к распределению траффика динамически. Но при помощи HTB Вы не сможете связать 2 разных класса (не одноподчиненных) что бы один работал на вход, а другой на изход. Да клиент то заплатил, но вот только, что Вы ему предлагаете за это... Уважаемые господа v-m-k и Nallien ну перестаньте же наконец путать грешное с праведным. Или завязываейте применть поняти синхронный и асинхронный. Забудьте про них... В данном вопросе важна дуплексность и симплексность, а так же симметричность и ассимметричность. Я уже дал примерное название тому что мы обсуждаем, см. выше...

Я конечно извеняюсь, но если я правильно понял, то Благородный Дон хочет странного... У меня создается впечателение, что Благородный Дон не видит разницы между синхорнным и ассиметричным каналом. Ну тоесть получается, что Благородный Дон предлагает влупить клиенту под видом дуплексного симментрочного канала в 128К нечто отдаленно его напоминающее? То, что будет изображать из себя деские качели и показывать то 64 на 64, то 100 на 28, то 8 на 120 - но при этом суммарная полоса будет 128К? Мне бы на месте Ваших пользователей то же бы неприятно было. Какнал болтается как сопля из стороны в сторону - он ни симметричный ни несемметричный, а какой то странный получается. Поэтому хотелось бы знать в каких местах еще практикуют подобные тарифы? Потому как для нашим мест (Украина, Донбасс) - сие нонсенс. Но это было лирическое отступление, а если по теме, то если лепить на интерфейсе направленном в сторону клиента HTB и ограничивать траффик идущий к киенту. И на том же интерфейсе применять ingress, то можно ограничивать траффик идущий и от клиента.

TSM Ну минимум не хватет ip route flush table cache после выполнения ip rule add from EXT_IP table T1 ip rule add from 192.168.3.0/24 table T1 ну и опять же - представь в студию результаты вывода комманд: ip r l t main ip r l t local ip r l t t1 ip ru li ip r g 193.193.193.3 from 192.168.2.XX iif pppXX - 192.168.2.XX и pppXX поставиш тот который сейчас активен. ip r g 193.193.193.3 from 192.168.3.XX iif pppXX - 192.168.2.XX и pppXX поставиш тот который сейчас активен. iptables-save затем выполни tcpdump -i eth0 -n net 192.168.0.0/16 И сесли ты что нибудь там увидиш, то с натом у тебя плохо...

Есть у меня в "корпоративном секторе" AT второго уровня с жбиками... - по сравнению с HP жалкая поделка... HP вообзе как дешевый Каталист выглядит. Хм... Так ведь в том то и дело что похоже что нельзя... ;) И компромис ли это? - тебе не кажется, что то что ты назваеш компромиссом есть небольшой блок большой сети? Ты забыл еще сказать - не дорого... ;)

Тю блин... Ты об этом... - Это все понятно... Я уж грешным делом подумал что ты про multi-vlan вспомнил. Потому как фраза "что бы сервер был во всех вланах одновременно" именно это напоминает.

Вы вообще форум читаете? В http://forum.nag.ru/viewtopic.php?t=17119 практически Ваша ситуация описана. Решения тоже пожожи...

Ну тогда хотелось бы узнать, что собственно вы хотите гонять между клиентами? Ведь нутром чую, что два Васи из Ваших клиентов в Контру или еще что то подобное поиграть друг с другом захотели, а вы теперь напрягаетесь как перепахать дизайн сети - я прав? Стоп, ничего не понял, а как его надо уметь использовать? - Броадкасты есть и не могут не есть. ;) Ну и честно говоря, Вы бы более детально описали свою сеть и задачи которые пытаетесь решить - а то что то странное получается: если у вас 40% броадкастный траффик, то это значит, что либо уникастного траффика просто почти нет (т.е. клиенты работают очень мало), либо вашу сеть штормит. Хотелось бы услышать об этом чуде.

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

И вот тут как раз и есть твоя проблема, ты ее сам и описал - у тебя каждый порт это сеть. А маршрутизация в пределах одной логической сети это нонсенс. Т.е. физически ты сеть расскек, а логически оставил объедененной. Подобные решения хороши если ты хочеш изолировать клиентов друг от друга, и похоже что твоя сеть с этого и начиналась. А теперь возник вопрос о том что бы определенно части клиентов обеспечить доступ друг к другу. Я верно ситуацию понимаю? Варианты есть, но они несколько извращенные. Рассмотрим один из них. К рассмотрению примем один портбэйзед свич с изолированами портами и одним аплинком подключенным к порту управляемого коммутатора поддерживающего 802.1q, порт управляемого ввича находится в нетегированном режиме. Для того что бы ты смог осуществлять маршрутизацию между клиентами тебе необходимо разбить свою сеть на подсети /30. Т.е. на каждого клиента своя подсеть из 4-х IP. Первый - адрес сети, последний - адрес броадкаста сети, а второй и третий - это непосредственно адрес клиента и адрес на интерфейсе твоего маршрутизатора терминирующего тегированые вланы. Клиенту настраивается gw на третий адрес в сети. Всем остальным клиентам выдаются другие подсети /30 и настраиваются они аналогичным образом. Т.е. на интерфейсе твоего маршрутизатора терминирующего данный тегированый влан будет 64 алиаса для сети класса C. Теперь для любого из клиентов адрес другого клиента в вашей сети не будет локальным и клиентский стэк TCP/IP будет отправлять все пакеты на gw. А уже на нем будет иметься таблица маршрутизации и правила файрвола (от кого к кому можно, а от кого к кому нет). Решение это рабочее, но оно деградатское по своей сути. Производительность канала между одинм и другим пользователем при самом прохом розкладе может быть равна 100/(<Кол-во свичей>*15)MBit/s. Если конечно управляемый свич подключен не Гигабитом. Т.е. при 3-х портбэйзед свичах и 45 клиентах на одного из них прийтется в худшем случае 2.2 мегабитав секунду. Если же подключить маршрутизатор на гигабит, то получится 22 мегабита. Но честно говоря я думаю что ваш маршрутизатор перестанет справляться с нагрузкой - потому что маршрутизация будет производиться через тот же самый физический интерфейс через который пакет пришел. А роутер Ваш ASICами не снабжен. Так что это дело очень быстро загнется - 100% загрузка CPU и полная деградация всех сервисов. Вы этого хотели? Как уже высказывался snark если маршрутизатор заменить на L3 коммутатор, то данная схема выдержит большую нагрузку - у данного коммутатора ASICи конечно есть. Но честно говоря для Вас это скорее всего не выход. Стоимость L3 коммутатора достаточно высока. И при всем при этом в сетевом окружении клиенты друг друга по SMB не увидят. Т.е. так или иначе прийдется городить самбу и ее реализацию wins. Ну и на последок хотелось бы сказать следующее - мне кажется что Вам нужно определиться изолировать клиентов сети друг от друга или нет. Тут варианта три - да, нет и да но не всех. И вот третий вариант влечет за собой замену портбэйзет влановых свичей на свичи поддерживающие 802.1q. Только в этом случае будет Вам счастье.

alex_001 Если не затруднит, то развей мысль плиз... Чесчтно говоря не понял в чем "аппаратность" интеловского деления на vlan-ы? Ну не отбразывает карточка большие фреймы - так многие делают. А все остальное дело дров. Т.е. тегированый будет все же оставаться на eth0.11 и т.д.? Тогда кто нибудь обясните мне почему при создании vlan интерфейса не нем нет совершенно никакого qdisc-а?

Добрый день уважаемые господа и дамы. Помогите кто чем может в прояснении следующей ситуации. Предполагается сделать следующий дизайн сети: Имеется хост на Fedora Core 4. На нем есть два эзернета на базе Realtec 8139. Одним из них он будет опирается на аплинка - от которого собственно и будет поступать интернет ресурс, а вторым он будт включен в Cisco Catlist 2924XL. Порт на Каталисте будет находится в режиме транка. Все остальные порты Каталиста будут в "аксесс моде" (т.е. в нетегированном режиме), каждый в своем влане, и к ним будут подключены клиенты. Т.е. ситуация с типичным "разветвителем" из связки коммутатор+маршрутизатор - каждый клиет в отдельном vlan-е и имеет доступ только к маршрутизотору который являеется шлюзом по умолчанию. У каждого клиента собственная подсеть - т.е. режим полной изоляции друг от друга. С реализацией это схемы вопрсов нет. Вопросы начинают возникать когда я начинаю планировать как будет осуществляться Traffic control (я использую htb) на данном програмном маршрутизаторе. Дело в том, что при Traffic control на Linux, корневой класс создается на qdisc-е прикрепленном к конкретному интерфейсу. В моем же случае у меня в системе будет несколько десятков vlan интерфейсов типа eth0.11, eth0.12, eth0.13 ... Если я для каждого интерфейса создам свой qdisc и свой корневой класс, то ограницение максимальной скорости пропускания по каждому из интерфейсов сделать очень просто. Но беда в том , что мне хочется странного: хочу что бы у меня на этих vlan интерфейсах можно было не только rate задать, но и ceil. А так как ceil задается в пределах одного класса, то у меня возникла мысль относительно того, что корневой класс нужно создавать не на vlan-интерфейсе, а на физическом интерфейсе eth0, на котором создаются логические vlan интерфейсы. На эту мысль меня натолкнуло то, что когда в системе есть vlan интерфейсы, то на физическом интерфейсе qdisc fifofast есть, а вот на логических vlan интерфейсах qdisc-а нет вообще. Т.е. я на физическом интерфейсе прицепляю qdisk htb, к нему креплю корневой класс, и на базе этого класса создаю подклассы для каждого vlan интерфейса. А потом фильтрами направляю траффик в эти классы. Изходя из всего вышесказанного хотелось бы услышать ваше менение по поводу моего предположения. Будет ли работать схема описанная моной? Если нет, то что можно предолжить альтернативное?