Перейти к содержимому
Калькуляторы

random7

Активный участник
 Просмотреть профиль  Активность

  • Публикации

    122

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

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем random7

  4. Опубликовано · Жалоба на ответ

    Может половину всего трафика получает какой-то один MAC (и соотв. это всё попадает только на один из интерфейсов)?

    Вообще можно посмотреть дампы трафика на интерфейсах и сравнить на предмет каких-то особенностей.

  5. Опубликовано · Жалоба на ответ

    Странно, по идее HZ указывает на частоту переключения между потоками планировщиком, а прерывания они независимо от этого должны отрабатывать, если не используется поллинг сетевух.

     

    HTB шейпит трафик, то есть задерживает пакеты, то есть откладывает посылку пакетов на будущее, то есть ждёт события от таймера

  6. Опубликовано · Жалоба на ответ

    переполнения dst cache не было, но в этом кеше держались ссылки на нейборов (которые не показывались по ip ls neigh) - в общем когда я разбирался с этой проблемой, не нашёл ничего лучше как увеличить таблицу нейборов до нескольких десятков тысяч, а в более новых ядрах проблема исчезла

  8. Опубликовано · Жалоба на ответ

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

  9. Опубликовано · Жалоба на ответ

    Что-то у вас action нет в куче правил, это точно полный вывод?

     

    А, ещё может быть, что соединение старое, а правила были добавлены/убраны позже - одно из соединений отнатилось по старым правилам.

  10. Опубликовано · Жалоба на ответ

    Купите SFP с поддержкой DDM и смотрите затухание.

    Или же отправить двоих инженеров дежурить и ждать падения, как упадёт - пусть измерят рефлектометром трассу и проверят затухание.

     

    Может кровать стоит на кабеле чья-нибудь :)

  12. Опубликовано · Жалоба на ответ

    Может, что-то поменялось за последние годы, но когда я пробовал, программа iperf -u не подходила для тестирования каналов.

    Там проблема, что посылаются пакеты большими бёрстами, и они дропаются уже в ядре, не доходя до сетевого интерфейса. То есть показывает например 50% дропов, но это дропы не в канале.

  15. Опубликовано · Жалоба на ответ

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

    проворачивал такой маневр с 2950 и 3526 - как-то вообще пофиг ;)

     

    Значит мы выявили важнейший признак коммутатора: выдерживает удар кирпича

  16. Опубликовано · Жалоба на ответ

    Mikrotik Routerboard: пропуск трафика между портами включен по умолчанию. Как и у других SOHO-маршрутизаторов.

    Если вы сбросите дефолтную конфиуграцию просто на ноль, то ничего некуда пропускаться не будет.

     

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

  17. Опубликовано · Жалоба на ответ

    независимые трассы - это какой-то миф

    Почему авария произойдёт именно на вводе в БЦ, других независимых слабых мест намного

    больше.

    Про другие места тут совершенно правильно говорят, что можно и кольцо построить, и активку продублировать.

    Воздушки как-то не любят солидные заказчики.

  18. Опубликовано · Жалоба на ответ

    есть только один оператор! других арендаторам не надо

    серьезным арендаторам надо как минимум два провайдера с независимыми трассами

    независимые трассы - это какой-то миф

    в БЦ будет один кабельный ввод, дальше всего одна кабельная канализация в ближайших нескольких сотнях метров

    это если канализация вообще есть, а то я видел случаи что прям под асфальтом участок проложен :) (для весьма серьёзной организации)

    соответственно один бульдозер рвёт все кабели сразу

     

    поэтому серьёзная организация поступает проще - у них независимый резервный офис (связь есть, компы стоят, столы-стулья, сотрудников нет)

  20. Опубликовано · Жалоба на ответ

    Основной критерий, вероятно, такой.

    У коммутатора есть принадлежность портов к вланам, для пропуска влана между портами А и Б нужно просто добавить их во влан.

    У маршрутизатора это побочная функция, делается костылями типа отдельно прописываемого моста.

     

    BGP же может быть у коммутатора, а может и не быть вовсе - у SOHO маршрутизатора.

     

    Mikrotik Routerboard: пропуск трафика между портами включен по умолчанию. Как и у других SOHO-маршрутизаторов.

  21. Опубликовано · Жалоба на ответ

    Мне звонили. Ничего страшного. Спрашивали, в курсе ли я, что можно получить последний /22. Я сказал что да но не знаю смогу ли обосновать и т.п. Они уговорили меня таки взять :)

     

    Может. Для доказательства использования, вам необходимо прописать все сетки на каком-нить серваке. А так же настроить мониторинг чтоб график писал кол-во активных сессий - использованных ip (множитель подобрать чтоб экстремум был овер 2000). Эти графики необходимо будет предоставить, либо дать доступ, чтобы сами могли его смотреть.

    Несколько аудитов проходил, никогда ничего подобного не спрашивали. Может Вы путаете с процедурой получения PI? Там да, спрашивали всякое. А по поводу PA их интересовало только состояние базы, то есть зарегистрированные объекты inetnum - могут выбрать какой-нибудь и спросить данные, на основании которых был назначен блок адресов.

  22. Опубликовано · Жалоба на ответ

    ещё вариант: "Вы не должны этого хотеть" (с)

     

    в смысле, откуда вообще такая необходимость?

    если у сервера не хватает производительности, то этого не должно быть: линукс на не очень древнем железе всяко быстрее 7206

    если клиенты не хотят видеть лишний хоп в трейсе, то можно отредактировать ttl

    вопрос устойчивости к отказу сервера тоже вроде бы решён