andryas

VIP
  • Публикаций

    5 310
  • Зарегистрирован

  • Посещение

Информация о andryas

  • Звание
    Скрипач
  • День рождения

Контакты

  • ICQ
    0

Информация

  • Пол
    Мужчина
  • Интересы
    IT

Город

  • Город
    Хануд

Посетители профиля

3 195 просмотров профиля
  1. Уже посоветовали: отключить с обеих сторон. У меня, например, вот так: interface TenGigabitEthernet1/50 flowcontrol receive off flowcontrol send off Port Send FlowControl Receive FlowControl RxPause TxPause admin oper admin oper --------- -------- -------- -------- -------- ------- ------- Te1/50 off off off off 0 0 О гигабитном интерфейсе, если дропы на таковом сильно беспокоят. Если там сотые доли %, то понять и простить
  2. flow-control с обеих сторон отключён? Загрузка портов какова? Какой характер трафика? Раскраска трафика присутствует в сети? Вообще-то дропы - это норма, в данной ситуации, вопрос в их %% количестве. На 3560 их будет много, на 4948E - в несколько раз меньше, но будут. Даже все 16 Мегабайт буфера последнего комутатора, это всего лишь немногим более 100 мс перегрузки по гигабитному порту (и 10 мс по 10-ке). Рассчитайте статистику и оцените допустимость полученных потерь для Вашей ситуации. Хотя, скорей всего, это обычные бёрсты. Я где-то читал, что "удачно" оправленные даже 4 мегабита с двух десяток в один гигабитный порт вполне способны произвести перегрузку последнего.
  3. Да. Если в ядре, с этим проблем не возникает, то уровень распределения страдает уже сильно. Ну и, естественно, проблема усугубляется на доступе. Возкникла идея подкрасить трафик до распределения, и решить сразу 2 проблемы: нехватку буферов на агрегации и улучшить жизнь геймерам. В качестве иллюстрации приведу вот эту ветку: http://forum.dlink.ru/viewtopic.php?f=2&t=173610
  4. С TCP трафиком так можно. Механизмы регулирования скорости в нём работают очень хорошо, и внесённая задержка, в целом, будет даже полезной. Но есть ли смысл отправлять в длинный путь UDP, который, потеряв актуальность, будет либо отброшен (рилтайм типа скайпа, игрушек) либо переотправлен (торренты и прочее видео), бесполезно расходуя очереди портов? Собственно, и возникла идея, отправить его в короткую очередь с крошечным буфером. А если сделать так: Возьмём, к примеру, 4 очереди. В первую - голос, управление, критически важные службы Во вторую - известные службы и сервисы В третью - прочий UDP В четвёртую - прочий TCP
  5. Навеяно ноем геймеров-качальщиков и прочих, юзающих, например, VoIP, на дешёвых (без какой-либо приоритезации) тарифах, в случае полной утилизации порта. Вопрос, собственно, в том, что может получиться из затеи раскраски этого их UDP с последующей отправкой его в отдельные (приоритетные, но очень короткие) очереди, минимизируя его буферизацию на исходящих портах?
  6. Борьба мощностей окончена, проиграли все. Ситуацию с убитым эфиром могло бы решить ограничение мощности роутеров у пользователей многоэтажек, в паре с поиском наиболее удачного места их расположения. Но нет, ве хотят "мощный" роутер с большими антеннами, да побольше. Результат налицо. На очереди 5-ка. И там тоже будет подобное, это только вопрос времени.
  7. Просто 200 юзеров не проблема даже для Mikrotik RB750Gr3. Но если на всё это хозяйство надо настроить QOS, фаервол со списками и т.д, то, думаю, лучше всего присмотреться к решению на PC.
  8. Есть подобный функционал на цисках, начиная от 2960/3560. Но QOS на свитче вещь зубодробильная, тот же микротик куда более юзерфрендли. Если пакетная нагрузка небольшая, микротик вполне оправдан. Но при многих десятках-сотнях тыс. пакетов в секунду решения на микротике стают неоправданно дорогими.
  9. RB2011UAS-2HnD тоже дешёвый роутер? Или, может быть, его надо как-то правильно настроить?
  10. Если в 4948E програмно всё устраивает, то есть 2 родственных варианта, сравнительно дешёвый и подороже: 4900M и 4500-X сответственно. Но в первый необходимы модули (конверторы x2) для подключения SFP+. Зато есть Если "десяток" необходимо больше 8, то выйдет на одно и тоже, и тогда я отдал бы предпочтение второму. (всё бу, естественно) Да, ещё одно - не забывать о переподписке у 4900M
  11. Проверил скорость ещё на нескольких девайсах (на все залил 6.40.4) RB2011UAS-2HnD (AR9344) - проблема есть (!) RB751U-2HnD (AR9283) - никаких проблем, всё идеально RB411GL + R52Hn (AR9220) - никаких проблем, всё идеально. У микротика кривые дрова для новых радиокарт?