greyshadow

2. Разность базу и доступ на разные машины? Был пс, стало два, отличная получается отказоустойчивость. А если у ТС сервер с базой за 50 км. от него, и некому больше переключить? Если нет возможности спрятать кабель от наводок, то лучший вариант это оптика к базе, ну а для сервера выпрямитель какой нибудь. Все оперативные данные, требующие синхронизации, именно БД; все остальное решается конфигами, хранить и синхронизировать которые гораздо проще.

Т.к. самый класный вопрос - резервирование именно "остальной всей лабуды" вкуче с базой данных, то: 1. Вынос базы данных на нормальный сервак с заземлением/питанием. 2. машинка, которая собственно занимается разруливанием трафика и наиболее подвержена воздействию гроз резервируется на уровне vrrp. 3. непонятно накой сие (т.е. автоматическое резервирование) городить, т.к. при грозе потребуется ручное переключение, иначе вторая работающая машина с вероятностью близкой к единице так же вылетит во время грозы одновременно с первой... при ручном переключении достаточно хранить конфиги+ зе

Мало данных... Как вариант - 2 сервака, ваш шлюз/биллинг и т.д. в виртуалку, виртуалку синхронить на второй сервак. Резервирование практически на "хардварном" уровне. Ну или излагайте поподробнее.

RIP? IS-IS? OSPF? BGP? VRF? IPv6? IGMP v?? количество мультикаст групп? количество маршрутов?

Регитесь на сайте алькателя-люцента, и вопрошаете ТП на предмет "а чо за хрень?" и "дайте мануал"... Учитывая, что железка у вас на руках а у них там без серийника кроме даташита ничего не посмотришь - вам туда и идтить.

Не знаю как сейчас, но когда в продаже массово появились "мыльницы" поцене менее 50$ изучал подобную проблемку. Выяснилась до банальности простая вещь, в спецификации практически всех чипов, на базе которых были собраны такие мыльницы, значилось. Коммутация кадров со скоростью 144000 кадров/сек ЕСЛИ ВСЕ АКТИВНЫЕ ПОРТЫ В РЕЖИМЕ 100ФУЛ ДУПЛЕКС, если хотя бы ОДИН порт в длугом режиме (100ХАЛФ, 10h или 10f) то скорость коммутации кадров 14400 кадров/сек. т.е. если хотя бы один порт в 10-ке - финишь, весь всич считай на 10-ке работает Может конечно с тех пор что-то поменялось... а может и н

Алькатель вроде знает только о таких... I240W-S_EN_DataSheet.pdf ISAM_O-240G-S_EN_DataSheet.pdf

Ну еще можно что-то вроде cisco WAAS сгородить... но в 999 случаях на 1000 - таки расшириться проще

1. max value 100000000000 не равно (2^64-1) 2. Сталкивался с таким на некоторых прошивках некоторых железок, 2.1 Иногда "вдруг" железяка вместо нужного значения счетчика отдава 0(нуль), вылечилось проеданием плеши саппорту и новой прошивкой железки. 2.2 вместо беззнакового целого в 64 бита в железке использовалось знаковое, т.е. счетчик обнуляллся не при достижении значения 2^64-1, а 2^63-1, (один бит под знак + или -). 3. слишком "узкие" границы в rrd - допустим в параметрах rrd указано, что допустимое отклонени +-30 секунд, но за счет разных моментов попытка записи в rrd базу предпринима

А что тут разбираться - пускаете закачку и изучаете логи/top-ы/дропы, смотреть что за шейпилка шейпит/режет и т.д.

Го ту длинк для начала... Если это дорого - БУ смотреть...

WiFi для безопасности в том числе здоровья имеет весьма небольшую мощность, если сигнал бомба - скорее всего мощность завышена, а это между прочим частотный диапазон микроволновой печки.... кроме того как вы думаете, почему у СОХО железок такой небольшой уровень сигнала? WiFi уже довольно сильно распространен, и передатчики с большей мощностью будут глушить соседние - например в соседней 9-ти этажке на 144 квартиры мой ноут обнаруживает примерно 35-40 wifi сетей Надеюсь для вас не секрет, что в одной зоне покрытия более-менее нормаль могут работать 3 точки доступа в 2.4Г диапазоне, как

И о чем это говорит? О том, что они непрерывно задалбывают сервак запросами на подключение, т.е. пара десятков тенд у юзеров с отрицательным балансом задосят ваш радиус никому не нужными запросами.

А это вопрос к разрабам... Кстати вполне может оказаться, что виновен с сем не столько зюх, сколько свич за ним, т.к. насколько вижу главные обрывы при росте out трафика.

Нету такой таблицы.... может и на 200 хватит, а может 30 уложат в полку... Смотря насколько народ "голодный" и т.д.

или на русском Функция управления потоком (Flow Control) используется для регулирования передачи сигналов в зависимости от пропускной способности принимающего порта. Дело втом, что концентрация трафика на порту вызывает падение пропускной способности и перегружает буферную память, из-за чего происходит отбрасывание пакетов и потеря кадров. Ethernet-коммутатор использует управление потоком по стандарту IEEE802.3x в дуплексном режиме (full duplex) и управление потоком методом обратного давления (противодавления) в полудуплексном режиме (half duplex). Управление потоком по стандарту IEEE802.3x в

Погано що vpn пропадало пару раз на годину до вимкнення flow-control. Погано що свіч тепер на 80-96% зайнятий після вимкнення flow-control. Хотілось би якось до нормального режиму роботи повернутись. Ethernet flow control is a mechanism for temporarily stopping the transmission of data on Ethernet family computer networks. For example, a flow can come into a switch on a higher speed link than the one it goes out, or several flows can come in over two or more links that total more than an output link's bandwidth. These will eventually exhaust any amount of buffering in the switch. H

как вариант - ваш NAS дует в порт трафик, который длинку не нравиться, например в ВЛАН, который на этом порту запрещен.

Если денег не жалко - начните с посещения соотв. курсов - например цисковских CCNA/CCDA... Книги вам похоже не слишком помогут.

Что ж вы не посчитали на 500 абонов свои формулы. На 500 абонов ПОН 500*80 + 1300 *2(ОЛТ) = 42600 ФТТН 500*40 + 400 *22(свича) = 28800 По активке ФТТН еще пока существенно дешевле. ПОН может быть выгоднее на затратах на кабель в конечном итоге. Думаю, что на текущий момент нельзя говорить, что ПОН однозначно выгодней. Скорее всего они равнозначны по затратам. Как Вы правильно заметили, что у каждой технологии есть свои плюсы и минусы. Именно оценка вот этих нюансов будет определяющей при выборе технологии. Я пока считаю, что наиболее выгодным - будет смесь этих технол

И еще - счетчики пакетов считываете? если да - покажите.

1. похожая проблема обсуждалась http://local.com.ua/forum/topic/43780-странное-поведение-в-сети-петля/unread/ 2. у zyxel gs4012F весьма специфическое поведение, при переходе из up в down порта по snmp начинают отдаваться 0 по всем счетчикам порта, а при обратном переходе из down в up возвращаются старые значения, т.е. мониторилка получила например значение 300, потом порт ушел в down, и мониторилка получила 0, прикинула, что наверное счетчик переполнился и благополучно нарисовала соотв. "писюн" на графике. 3. Какие вы считываете счетчики? 32 бита или 64??? если 32 - то это 4Г максимум, т.к.

Там рядом вроде высотка(НИИ ,был когда-то, гора антенн на крыше), на ней вагона эдак 3 провайдеров, начиная с дориса и кончаа вегой....

Идти тут желательно от теории к практике, а не наоборот. Существенные минусы - pppoe с обратной связью, dhcp - нет. т.е. при pppoe вы знаете когда кто подключился/отключился, с dhcp вы знаете только когда кто включился, а вот текущее состояние неизвестно, есть еще пара-тройка моментов, но для них опять-же сначала желательно теорию...

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