bay

Хех... Еще один :) Я с этим боролся год назад. В гугле решения так и не нашел. Патчить dhcpd как-то не очень интересно, тем более при каждом обновлении. Но недавно, вернувшись из интереса к этому вопросу, решил глянуть на omshell (программа из комплекта dhcpd). Пришел к решению слежения за логом в поисках DHCPACK и отправки набора команд в omshell: server $SERVER port $PORT key $KEYNAME $KEY connect new lease set ip-address = $IP open set state = 00:00:00:01 update close Таким образом, в логе пролетает: dhcpd: DHCPACK on 1.2.3.4 to 00:11:22:33:44:55 (comp) via 1.2.3.1 dhcpd: lease 1.2.3.4 state changed from active to free Ну и в лиз-файле оно тоже на free меняется. Пару недель на другой сети работает, вроде не мешает. Может ли народ налету переключать железо - не знаю, но пока не звонят. PS. На другой сети потому, что у нас выдается по 4 адреса на порт и такая проблема еще не возникала.

Эээ... Стесняюсь спросить... В чем вопрос-то? PS. Тему "ниасилил многа букаф", но сам уже с пол-года раздаю инет с использованием opt82. Для подключения нескольких компов не обязательно ставить роутера, копеечного свитча будет достаточно. Белые адреса даются натом наружу/внутрь (думали тоже в dhcp воткнуть, но так проще оказалось). Проблем не наблюдается :)

А вот мало ли что там напридумают. Нам про них рассказывали в комплекте с DIR-100F. Мол, вот сюда втыкаем 100 мбит SFP, а с той стороны втыкаем DIR. За ненадобностью мы аппараты не брали, потому работуспособность без DIR не проверяли.

Для этого количества абонов хватит того же PC с *BSD/Linux на борту. Умеет много чего, в том числе и шейпер "как угодно" с маскарадом "как захочется" и bgp "на дофига маршрутов", что не помешает ему попутно иметь на борту web-, почтовый сервер, биллинг/счетчик и управление всем сетевым железом. При этом потянет и большее количество абонов. Главное воткнуть в него сетевые карты, дороже $5 "за пучок" :) Ну это смотря, как делать. Мы грозу пережили с минимальными потерями портов, хотя "соседи" на том же участке и плюс еще в его округе выхватили по самое не балуйся. Но магистрали, конечно же, только оптика. Даже без вариантов. Самое интересное в твоем случае - это что будет использоваться на доступе и чем собирать оптику без конвертеров. От первого сильно зависит сам процесс подключения к инету (авторизация или просто воткнул что угодно и работаешь). А второе просто интересно :) PS. А вообще правильно тут было сказано - почитай соседние обсуждения. Почерпнешь много нового и может быть полезного. Я благодаря этому от "vlan на пользователя" отказался, хотя до сих пор считаю этот вариант идеальным. Но оказалось, что можно сделать проще с тем же функционалом. PS2. Кстати, а 3200-28F разве не только с DIR-100F умеет дружить?

Ну NiTr0 за меня уже ответил :) Как-то сложно у вас с этим. В Украине таких требований не предъявляют и вряд ли в ближайшее время будут предъявлять. Мы разве что пару раз по официальным письмам из органов давали инфу кто из абонов ходил на указанные адреса в указанный промежуток времени.

Мы пользуем серию DES-3200. Нареканий нет. Восьмой месяц полет нормальный. Если собираетесь ставить что-то умное, обратите внимание на эту серию. И пусть ваши экономисты на розничную цену особо внимания не обращают. Для прова "под проект" длинк дает хорошую скидку :) PS. Народ тут жаловался на горящие порты. Мол, весь сервис уже завален аппаратами после грозы. Как показал недавний опыт, порты выгорели тольку у свичей, которые находились в квартале, на который пришелся удар. Да и то <10% Там у народа еще холодильники и прочее электрическое оборудование погорело. Подстанция у электриков на пол-дня отвалилась. Так что два десятка портов в таком раскладе - это вполне нормально. А вот у конкурентов пол-города "ушло с концами". Но они тупым железом пользовались.

Нее. Есть ядро 2.6.0. А в сертификате указано 2.6. Видишь лишние ".0"? :) Ну и ставить на серв 2.6.0 - это самоубийство.

MySQL 5.0 еще найти можно. А где взять ядро линуха 2.6 ? Особенно "умные" проверяющие могут и потребовать :) Ну это всё лирика.

Не так то, что если у вас хоть одно конечное оборудование тупое, то всё конечное умное оборудование может работать, как: 1. умное, но это начнется зоопарк в плане управляющего ПО. Оно того не стоит 2. тупое для однообразия управления В данном случае из умного можно взять изоляцию портов. Как в ваших конвертерах. "Нет ничего более постоянного, чем временное". Проверено неоднократно :)

Фактически, эти свитчи будут использоваться с функционалом конвертеров. Так ли оно нужно? Ну и 100 мбит на 4 свитча - это явно мало. Лучше бы вы про это подумали.

Ну поскольку любая АСР работает в пределах операционной системы, то и инфу для работы она получает непосредственно от ОС. Соответственно, источником является ОС, а не, скажем, сертифицированная кошка. Вопрос - насколько можно доверять сертифицированной АСР на не сертифицированном источнике? :) Вероятно, ОС должна быть сертифицирована для тех же целей, что и АСР. Какое оборудование - такая и сеть :)

Считается iptables-ом. Для отчетности - сбор инфы в flow-tools. Если операционка сертифицирована, то и вот. Если нет, то информация сертифицированных программ не может считаться достоверной - в любой момент можно сказать, что ОС предоставляет программе недостоверную информацию :) Я бы вообще с этим не заморачивался. Как показала практика, особого смысла это не имеет. Проблема ip+mac не в этом. При условии одного тарифа и физическом отключении кабеля от сети почти всё сказанное можно отсеять - смысл подключаться через соседа, если у тебя и так есть то же самое, что и у него? И раздаваться можно было бы через DHCP. Конвертеры сегментируют, агрегация реже то, что не получено через DHCP. Но проблема ip+mac в том, что абонент может поставить себе свитч и на каждый комп завести по N мбит, получив в результате X*N мбит, вместо оплаченных 1*N мбит. Если же вводить привязку к макам, то возвращаемся к тем же проблемам подмены оного. Благо, узнать маки соседей не сложно - просто послушать броадкасты.

Так откуда счетчики, если тарифы безлимитные? В этом случае биллингом может быть тот же MS Excel :)

А вот например как работают кабельщики? Их реалии - это просто начисления раз в месяц без учета, смотрит народ телевизор или нет. Неужели для этого им тоже нужно нечто сертифицированное?

Ну это можно делать и без биллинга с авторизацией. У нас самописная система на базе web и крона. Масштабируемость в какую хочешь сторону и на сколько фантазии и знаний хватит. Нагрузка на ОС только ночью, когда по всем абонплата снимается, да и то не заметна. Если считалка "на лету" для пакетов с потрафиковой отплатой не нужна, то можно и самим написать. Если нужна - тоже можно написать, но лениво :) PS. А самое главное - отчеты для бухов формируются за любой период и в том виде, в котором его хотят видеть бухи, а не в том, в котором видели разработчики :)

Тарифы будут разными? Траф будешь считать или все безлимы?

Видимо, торжественный распил состоялся :) Ну к чему ты пришел за эти два дня?

УПС, пардон, 160G6 - что конечно в корне меняет дело. не в те листы закупов посмотрел.. За <$2k берется xeon с винтами 2x250+2x1Тб, 4-мя гигами памяти, дополнительной двухголовой сетевой и всё это в стоечном 1RU корпусе :)

С сервером - да, это они погорячились :) Видел такой в инете за $11к. Сразу подумалось про гигабитного кошака, не брендовый серв на xeon-е и кучку умного железа на доступ с гигабитными магистралями вместо того, что есть сейчас.

Мы и на умном железе не режем. Скорость порта режет весь траф - и локальный и инет. Абоны не поймут 5 мбит локалки из 100 возможных :) Обходимся приоритезацией трафа. Межабонентский траф имеет минимальный приоритет. В вашем случае такого на доступе не сделаешь. И за сколько взяли сие чудо враждебной техники, если не секрет? Поддержка чего имеется? Я имел ввиду поддержку многопроцессорности в сетевых картах и поддержку в ядре работы с такими сетевыми картами в многопроцессорном режиме. Обычно набортные чипы в серверных матерях такого не умеют.

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

Если гнать весь траф через серв, то на него нужно ставить не самое дешевое железо. В частности, сетевые карты от $100-$200 штука. И должна быть соответствующая поддержка в ядре ОС. Иначе проц задохнется от обилия пакетов. Так что это палка о двух концах :) Это не совсем тот траф, о котором я говорил. Имелся ввиду траф между абонами. Тот же торрент-трекер может дать ощутимую нагрузку межабонентским трафиком, причем не объемом, а количеством пакетов (PPS). У вас домовое оборудование вланов не умеет. Смысла загонять их в вланы на агрегации и терминировать через пол-метра меди на сервере я не вижу. Разве только в варианте прогона всего трафа через серв - и межабонентского и внешнего. Будете менять железо - будете придумывать новую архитектуру под это железо. Сейчас заморачиваться бессмысленно.

Маршрутизации он не умеет. Соответственно, абоны смогут видеть друг друга только через серв, который всем этим будет управлять. Ну или особо не контроллировать траф на агрегации. Отсечь лишнее, типа win-сети. DHCP-релей отфутболит пролетающие запросы на серв, подцепив к ним номер порта агрегации (opt82). Снупинг привяжет ip-mac-port. Мы не заморачивались с названием вланов. Оно и не нужно. Пронумеровали все места установки свитчей по порядку и отметили эти номера на карте. В нашем случае свитчи готовятся заранее, монтажники берут нужные и ставят на соответствующий свитчу адрес. На агрегации для соответствующих портов назначаются вланы, которые они обслуживают. В биллинге каждому свитчу можно задать влан, ip и адрес, где он находится. В вашем случае можно обойтись без вланов, если нет желания гонять весь локальный траф через серв.

Потому и спросил :) Только агрегация (в данном случае DAS-4G24F) должна быть достаточно умной, чтобы уметь вланы, маршрутизацию, приоритезацию по ip и acl. В принципе, можно было бы баловаться и с dhcp - в случае чего ложник будет работать в пределах одного тупого свитча, не далее. При этом агрегация должна уметь dhcp-снупинг, dhcp-релей и opt82.

А что в данном случае означает "Port based VLAN"? Вроде шелезяка не конфигурируемая.