v_r

Активный участник
  • Публикаций

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

  • Посещение

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

  • Звание
    Студент
  • День рождения
  1. 49е очень шустро работают и при 30к в FIB + 300к в RIB. Подводный камень как и для всех бордеров - настраивайте CoPP.
  2. Bear_UA Я имел ввиду что само по себе принудительное фрагментирование снижает производительность Микротика, насколько помню скорость уменьшалась в 2-3 раза на синтетических тестах.
  3. nkusnetsov Я когда-то специально настраивал MTU 1400 на EoIP туннеле чтобы большие пакеты принудительно фрагментировались, преимущества - такая схема будет работать даже с IPSEC шифрованием, недостаток - CPU Микротика нагружается. Жалоб от абонента не было.
  4. Говорят с веб-интерфейса настройки изменяются в один заход.
  5. no hw-module module 1 logging onboard no hw-module module 2 logging onboard no hw-module module 3 logging onboard
  6. При включенном flow control наблюдал ошибки на прием на свитче (тип ошибок не помню, может и CRC), на ответной стороне (сервер с сетевой Intel) были output discards, такое было периодически в моменты большой загрузки CPU сервера, частично полечилось выключением flow control на сетевой сервера.
  7. Tftpsher За сколько времени набежало 12525 CRC ошибок? Вы счетчики на интерфейсах сбрасывали? В системе статистики/мониторинга график ошибок рисуется?
  8. CRC ошибки связанные с физикой растут пропорционально трафику, то есть если при 8G 3kpps ошибок то при 4G должно быть 1.5kpps. В случае роста ошибок с нуля до 3kpps начиная с какого-то уровня трафика то скорее всего это не CRC а input drops, то есть у Huawei вероятно не хватает буферов (или шины, я с Huawei не сталкивался). Проверьте выключен ли flow control control с обоих сторон на линке, перенести линк в другую карту или перегрузить ту в приходит которую линк. Но главное тут понять растут ли ошибки пропорционально трафику.
  9. STP dispute насколько помню возникает если один свитч принимает BPDU от второго свитча в сегменте, но второй свитч не воспринимает BPDU первого. Такое может быть из-за разных native виланов на портах, отсутствии связанности в native вилане или фильтрации BPDU.
  10. Скорее всего нигде не появятся, за исключением случаев большого трафика не порту. Насчет зеркала трафика то сомневаюсь что причина дропов в нем, на Cisco.com про 45е каталисты пишут:
  11. Потери могут быть из-за flow control, я обязательно выключаю его с обоих сторон.
  12. Они умеют балансировать трафик только равномерно по линкам. Непропорционально могут BGP и EIGRP (и RSVP но это другой уровень). Это для исходящего трафика, его у ТС скорее всего не много и он сам по себе отлично балансируется. А как же BGP AIGP metric? А банальный +/- MED?
  13. Теоретически можно, а на практике придется подбирать параметры настроек очередей на разнородном оборудовании, и если там нет статистики по очередям то останется только догадываться насколько эффективны настройки QoS и не слишком ли много трафика дропается. Аналогичную задачу решал путем настроек шейпов для торретнтов (или трафика из 3й и 4й очередей в вашем примере) на НАСе для абонентов постоянно загружающих каналы, абоненты выбирались по данным биллинга или по графикам.