moonfire Опубликовано 16 января, 2017 · Жалоба Вот тут совсем запутался... 1. Если значения явным образом не указаны, есть ли формула по которой оборудование рассчитывает Burst Commit и Burst Exceed. 2. police 64000 4000 4000 Формула одна, Bc = Tc * CIR. Просто у каждой железки свои дефолтовые Tc. Циски например у старых моедлей Tc = 25ms. Новые - 10ms. Суть этого параметра такова, что чем больше Tc, тем больше возможный бёрст. Для обычного юзер-трафика хрен рассчитаешь оптимальное значение. Поэтому лучше оставить дефолт, и разбираться только если есть жалобы. Т.е. это постоянная выделенная полоса для правила? Или это выделенная полоса для взрывного трафика? Для любого трафика. Просто если трафик не превышает полосы, то и полиси срабатывать не будет. Поэтому разговор как правило идёт о взрывном трафике. Типа tcp slow-start Полосу для DNS смысла резать немного, там трафик мизерный. Даже 128KBpS на клиента - c головой хватит. Рейт надо резать Возник вопрос, как это сделать? Т.к. если через policy-map, то ограничение будет не на пользователя а на интерфейс? И получается, что если 100 пользователей выйдет через данный интерфейс, получается 100/128=0,8KBpS. Что весьма печальная картина.... Вариантов полно. Посадить каждого юзера за отдельный интерфейс, например. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andryas Опубликовано 16 января, 2017 · Жалоба Возник вопрос, как это сделать? Т.к. если через policy-map, то ограничение будет не на пользователя а на интерфейс? И получается, что если 100 пользователей выйдет через данный интерфейс, получается 100/128=0,8KBpS. Что весьма печальная картина.... Для этого (централизованная нарезка трафика по IP) нужна железка с поддержкой microflow (User-Based Rate Limiting). Естественно, на тазиках это делается элементарно, но тазик не всегда уместен. На железках попроще, при архитектуре vlan per user, можно пробовать резать на vlan'ах. То же самое можно делать на физических интерфейсах, в случае использования достаточно умных свитчей доступа. Всё зависит от того, какое у Вас железо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vipro Опубликовано 16 января, 2017 · Жалоба Так где все-таки лучше это делать, на доступе? Можете дать пример, скажем, для cisco 2960? Как там зарезать dns-запросы из интернета к клиенту? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 17 января, 2017 · Жалоба Вам РКН сказано блочить вот те сайты/ип. вот и блочим. Почему бы блокировку по домену или маске домена не делать средствами днс? У РКН претензий нет. я в который раз повторю: покупаем vps за копейки, поднимаем там unbound и на тарифной скорости начинаем слать туда рекурсивные запросы. т.к. запросы рекурсивные, то попадая на ваш днс вы получите ещё 3-4 запроса сверху. отключить такого вы не можете, признать это DoS тоже не можете(второй конец принадлежит абону), а за вмешательство в трафик абон ещё и в РКН может написать жалобу. Блокированные сайты очень часто меняют ip. Намного чаще, чем ркн их правит в выгрузке. Самостоятельный резолв несколько улучшает положение, но не более и что будет, если владелец домена из реестра пропишет A-запись 3 раза свой ресурс и 1 раз какой-нибудь популярный игровой сервер? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myth Опубликовано 17 января, 2017 · Жалоба Такие случаи уже были, с самим сайтом ркн отключить такого вы не можете, признать это DoS тоже не можете(второй конец принадлежит абону), а за вмешательство в трафик абон ещё и в РКН может написать жалобу. Что мешает? Скорость порезать тоже можно. Пусть этот геморрой конкуренты расхлебывают Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmp.user Опубликовано 17 января, 2017 · Жалоба законопроект направлен на унификацию, определение единых требований для всех операторов связи к способам ограничения доступа к информационным ресурсам Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jora_Cornev Опубликовано 20 января, 2017 · Жалоба Извиняюсь за возможный оффтоп. Куда лучше эти правила повесить? ACL-ем на UPlink интерфейс или ip prefix-list'ом в BGP ? Если есть bgp с несколькими пирами, то это стандартно для bgp. Если только дефолт - то и на uplink повесить на out. Если нету bgp - то на out во внешний мир. Ну не должны серые сети вылезать внаружу. Подскажите, нужно ли в BGP prefix-list'е в конце ставить 0.0.0.0/0 seq 10 permit 10.0.0.0 0.255.255.255 seq 20 permit 127.0.0.0 0.255.255.255 seq 30 permit 169.254.0.0 0.0.255.255 seq 40 permit 172.16.0.0 0.15.255.255 seq 50 permit 192.168.0.0 0.0.255.255 seq 60 permit 224.0.0.0 15.255.255.255 seq 70 permit 240.0.0.0 15.255.255.255 seq 80 deny 0.0.0.0/0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
feeman Опубликовано 22 января, 2017 · Жалоба Подскажите, нужно ли в BGP prefix-list'е в конце ставить 0.0.0.0/0 Тоже интересен ответ на данный вопрос. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
infery Опубликовано 23 января, 2017 · Жалоба Нет, т.к. там implicit drop в конце Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...