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

random7

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

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

  • Посещение

Все публикации пользователя random7


  1. а если с другой стороны конвертор?
  2. Извиняюсь за возможно обидное предположение, но согласование дуплекса проверили?
  3. для l2+l3 это не играет роли. До L3 балансер не доходит, так как он внутри pppoe
  4. Может половину всего трафика получает какой-то один MAC (и соотв. это всё попадает только на один из интерфейсов)? Вообще можно посмотреть дампы трафика на интерфейсах и сравнить на предмет каких-то особенностей.
  5. HTB шейпит трафик, то есть задерживает пакеты, то есть откладывает посылку пакетов на будущее, то есть ждёт события от таймера
  6. переполнения dst cache не было, но в этом кеше держались ссылки на нейборов (которые не показывались по ip ls neigh) - в общем когда я разбирался с этой проблемой, не нашёл ничего лучше как увеличить таблицу нейборов до нескольких десятков тысяч, а в более новых ядрах проблема исчезла
  7. В старых ядрах если я правильно помню была проблема, что neighbor-записи держались в dst cache. Ну я просто побольше ставил эти gc_thresh.
  8. Может просто на свитче буферной памяти мало вот и дропаются пакеты. Тестирование скорости с одного компьютера может дать другие результаты - так как другой характер трафика.
  9. Что-то у вас action нет в куче правил, это точно полный вывод? А, ещё может быть, что соединение старое, а правила были добавлены/убраны позже - одно из соединений отнатилось по старым правилам.
  10. Купите SFP с поддержкой DDM и смотрите затухание. Или же отправить двоих инженеров дежурить и ждать падения, как упадёт - пусть измерят рефлектометром трассу и проверят затухание. Может кровать стоит на кабеле чья-нибудь :)
  11. Ну покажите что ли /ip firewall export в микротике
  12. Может, что-то поменялось за последние годы, но когда я пробовал, программа iperf -u не подходила для тестирования каналов. Там проблема, что посылаются пакеты большими бёрстами, и они дропаются уже в ядре, не доходя до сетевого интерфейса. То есть показывает например 50% дропов, но это дропы не в канале.
  13. у меня все заводились (покупались где попало)
  14. NAT на линуксе и на микротике (что одно и то же по сути) каких-то особых проблем давно не видел (ну надо connlimit сделать чтоб один абон не переполнил таблицу)
  15. проворачивал такой маневр с 2950 и 3526 - как-то вообще пофиг ;) Значит мы выявили важнейший признак коммутатора: выдерживает удар кирпича
  16. Если вы сбросите дефолтную конфиуграцию просто на ноль, то ничего некуда пропускаться не будет. А если положить на пол и сверху кирпичом ударить посильнее, то вообще не включится. И что?
  17. арендодатели

    Почему авария произойдёт именно на вводе в БЦ, других независимых слабых мест намного больше. Про другие места тут совершенно правильно говорят, что можно и кольцо построить, и активку продублировать. Воздушки как-то не любят солидные заказчики.
  18. арендодатели

    серьезным арендаторам надо как минимум два провайдера с независимыми трассами независимые трассы - это какой-то миф в БЦ будет один кабельный ввод, дальше всего одна кабельная канализация в ближайших нескольких сотнях метров это если канализация вообще есть, а то я видел случаи что прям под асфальтом участок проложен :) (для весьма серьёзной организации) соответственно один бульдозер рвёт все кабели сразу поэтому серьёзная организация поступает проще - у них независимый резервный офис (связь есть, компы стоят, столы-стулья, сотрудников нет)
  19. L2 туннель через белый адрес Yota?

    У меня работает ovpn-client - именно L2 именно с Йотой белый адрес не нужен
  20. Mikrotik Routerboard: пропуск трафика между портами включен по умолчанию. Как и у других SOHO-маршрутизаторов.
  21. Мне звонили. Ничего страшного. Спрашивали, в курсе ли я, что можно получить последний /22. Я сказал что да но не знаю смогу ли обосновать и т.п. Они уговорили меня таки взять :) Несколько аудитов проходил, никогда ничего подобного не спрашивали. Может Вы путаете с процедурой получения PI? Там да, спрашивали всякое. А по поводу PA их интересовало только состояние базы, то есть зарегистрированные объекты inetnum - могут выбрать какой-нибудь и спросить данные, на основании которых был назначен блок адресов.
  22. ещё вариант: "Вы не должны этого хотеть" (с) в смысле, откуда вообще такая необходимость? если у сервера не хватает производительности, то этого не должно быть: линукс на не очень древнем железе всяко быстрее 7206 если клиенты не хотят видеть лишний хоп в трейсе, то можно отредактировать ttl вопрос устойчивости к отказу сервера тоже вроде бы решён
  23. В 3750 вроде должен быть VRF - не поможет?
  24. Может быть, довести прямой влан от нужных портов в локалке до 7206?
  25. > Они бы всё равно не купили. В несколько раз больше бы купили, ходить смотреть в другой корпус за чужим ноутом не все хотят.