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

maxkst

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

  • Публикации

    674

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

  • Посещение

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

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

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

    В 16.12.2021 в 10:52, RN3DCX сказал:

    Делать список на разрешенные хосты? - не это не вариант!

    почему? делать то не в ручную, а сам роутер будет это делать автоматически. ну и таймаут можно сделать не очень долгим

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

    В 16.12.2021 в 10:38, RN3DCX сказал:

    Где-то вычитал, что пакеты сгенерированные маршрутизатором не дропаются!?

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

     

    В 16.12.2021 в 10:38, RN3DCX сказал:

    Ранее где-то вычитал, что пакеты сгенерированные маршрутизатором не дропаются!?

    тут сама формулировка неверная. Пакеты сгеренированые маршрутизаторами попадают в Output. А ответы уже дропаются либо не дропаются - на Input-е

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

    В 16.12.2021 в 10:18, RN3DCX сказал:

    Усё и всё сразу! При включённом правиле у самого маршрутизатора нет доступа в мир: ping, traceroute и т.д.

    ну добавьте для начала ICMP в исключения для этого правила: Protocol (!) 1 (ICMP)

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

    В 05.12.2021 в 16:16, SUrov_IBM сказал:

    Вероятнее всего, Redundancy on STP там не нужно, поскольку нет самого кольца.

    Если в сети нет колец, петель и прочих окружностей, то зачем там вообще что-то поверх чего-то? ))

     

    В 05.12.2021 в 16:16, SUrov_IBM сказал:

    Вероятнее всего, где-то прочитали и считают, что VPLS работает быстрей EoIP, ну или просто так, VPLS - "стильно, модно и молодёжно". ;)

    На практике и у EoIP и у VPLS есть свои проблемы.

     

     

  8. Опубликовано · Изменено пользователем maxkst · Жалоба на ответ

    В 29.11.2021 в 16:17, SUrov_IBM сказал:

    чтобы по нормально-маршрутизируемой IP сети

    Топикстартер говорит, что 

     

    В 22.10.2021 в 00:47, alexder сказал:

    Имеется локальная сеть (единый броадкастный домен, ВЛАН... не важно) из микротиков.

    Как единый ВЛАН может быть одновременно нормально маршрутизируемой IP сетью?

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

    В 22.10.2021 в 00:47, alexder сказал:

    Имеется локальная сеть (единый броадкастный домен, ВЛАН...

    А Redundancy на STP построено чтоли? Или резервных каналов вообще нету? (тогда зачем VPLS...)

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

    В 20.10.2021 в 02:07, VolanD666 сказал:

    Видимо, провайдер- рукожоп и это ему как-то мешает. Например, вирусы внутри сети  ТС долбят в т.ч. и ресурсы прова, это как версия :)))

    Это как же надо долбить, чтобы пров заметил? ))

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

    В 02.10.2021 в 05:57, nav2002 сказал:

    При настройке на микротике двух провайдеров обнаружил проблему  выхода серых адресов через WAN интерфейс в сторону провайдера.

    Подскажите как заблокировать серые адреса на WAN интерфейсе.

    А чем оно там помешало? 

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

    3 минуты назад, sdy_moscow сказал:

    А может чел решил поиграться в MITM ? На неуправляемой сети это не сложно.

    Тогда как он имеет доступ к логам ПППоЕ, это не вяжется с MITM, да и спамящий пароль - бесполезен как бы

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

    3 минуты назад, eoleg сказал:

    подключу на скорости 1к )

    Я бы мак фильтранул на ближайшем бридже. Скорее всего это какая-то ваша вайфайка, которой в WAN кабель воткнули. Но все таки правильнее найти и обезвредить. Даже если сеть вся на тупых свичах, ставите в разрыв умный железяка, и смотрите, откуда мак прилетает. Ну и по рукам надавать тому, кто че попало в сеть пихает

     

    1 минуту назад, sdy_moscow сказал:

    хотите пасворд украсть?

    который спамит в лог? ну тогда это украденная железка ))

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

    В 24.09.2020 в 03:44, eoleg сказал:

    По маку dlink, найти не могу.

    Может для начала вашу сеть на SOHO ТП-ЛИНКах разобрать, и переделать на управляемых свичах, которые мак адреса показывают?

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

    1 минуту назад, Saab95 сказал:

    То же самое работает и на CRS слабых

    я про crs ниче и не говорю, и дело тут не в CPU. Сам гигабитный чип на 2011 - гуано. Он аппаратно с вланами не справляется

     

    6 минут назад, Saab95 сказал:

    Данные туда - сюда ходят никаких проблем и потерь

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

     

    ни на каком другом МТ я такое не видел

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

    5 минут назад, Saab95 сказал:

    У нас вланы чисто принимаются и на нем терминируются, потерь нет.

    на сотке - поверю. На гигабитной половине - нет, вы просто невнимательно смотрели. Давайте сравним методики тестирования

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

    В 10.09.2020 в 07:59, Saab95 сказал:

    Про вланы я ничего не говорил. Но когда мы эти RB2011 использовали как терминаторы абонентских вланов перед поном, и на каждом было их штук по 100-150, то трафик 300-500 можно было увидеть, и процессор в полку не упирался (чистый роутинг).

    Вланы он делает с Hardware offload  на гигабитной половине с 0.3% потерь просто на ровном месте. То есть если к примеру IPTV идет с тегом - уже неприемлемо. А без HW offload это вообще трэш.

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

    В 06.09.2020 в 14:44, Saab95 сказал:

    Да, а чего тут может быть не так? Если ната нет чисто роутинг и L2 в бридже? Ясно дело там трафик не 64 байтными пакетами идет.

    Да он даже вланы нормально не умеет на гигабитной половине. Могу подтвердить свои слова результатами RFC тестов, если нужно.

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

    23 часа назад, morf сказал:

    Он хорош только для коммутации

    спорное утверждение. мы делали лабу из 5 шт CRS317 свичей последовательно - ни одного фрейма не пропало. Делали L2 тест для нескольких 1072 последовательно - разница заметна, теряются фреймы, на UDP мультикасте с видео - CC Errors. Теперь стараемся по возможности чтобы L2 трафик не шел через 1072. На TCP особо не влияет, дропы корректируются протоколом. Готов поспорить, что под нагрузкой 1072 не пройдет L2 RFC тест