greyshadow

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

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

Мало данных... Как вариант - 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 базу предпринимается в уже недопустимое время - смотреть параметры rrd-ки.

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

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

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

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

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

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

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

Погано що 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. However, blocking the sending link will cause all flows over that link to be delayed, even those that are not causing any congestion. This situation is a case of head-of-line blocking, and can happen more often in core network switches due to the large numbers of flows generally being aggregated. И на что жалуемся??? сами включили..

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

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

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

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

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Г максимум, т.к. mrtg обычно считывает с периодом в 5 минут - то 4Г*8/300 примерно 110М, т.е если у вас скорости более 110М, то 32б счетчики не дадут сколь-нибудь нормального представления о реальных показателях...

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

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

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