Дмитрий, добрый день! Спасибо за статью!
Я правильно понял, что бы сделать такой LB кластер как минимум «внешние» интерфейсы должны быть в одной сети? Есть ли возможность собрать кластер когда ноды находятся в разных датацентрах, с разными IP адресами?
+ как быть в случае NAT, когда внешний интерфейс ASA спрятан за другим файрволлом, например? Что указывать в качестве VIP адреса? Публичнный или внутренний?
Спасибо!
Отличная интересная статья. Спасибо за перевод!
Единственное что термин «следующий участок сети» слегка режет слух сетевику. Полагаю, в оригинале было «next hop»? Вряд ли это можно нормально перевести, но в данном конексте звучало бы лучше если бы использовалось просто понятие маршрута. Сравните:
«Перехэширование случается, когда изменяется информация о следующих участках сети… Указывая в таблице маршрутизации статичные следующие участки сети, мы можем заставить коммутатор...»
и
«Перехэширование случается, когда изменяется информация о маршрутах… Указывая в таблице маршрутизации статические маршруты, мы можем заставить коммутатор...»
Спасибо за ответ в частности, и за статью в принципе!
То есть в итоге, есть некоторый коэффициент, ну допустим «K» (который в начале равен именно 10 в нашем случае), и растёт именно этот «K», пока произведение K*MSS (читай cwnd) не достигнет awnd? Именно этот «K» и определяет «количество отправляемых сегментов без ACK». И например при MSS = 1460 байт, «K» достигнет максимума при значении 64000/1460≈43
Это означает, что данный ПК может отправить сразу 10 пакетов, не дожидаясь получения подтверждения на них в виде ACK.
и подумал, что cwnd — это всегда количество пакетов, которые можно отправить без ACK. Возможно что подумал неверно, отсюда и вопрос.
Я в данной теории слаб, поэтому и хочу потдверждения\опровежения, что в рамках tcp сессии существует возможность отправить 64 000 сегмента не получая ACK от получателя
Сергей, добрый день. Не могу понять одной вещи.
Вот есть у нас параметр cwnd, о нём пишется:
По умолчанию значение окна перегрузки (congestion window — cwnd) для TCP-сессии в Windows 10 равно 10. Это означает, что данный ПК может отправить сразу 10 пакетов, не дожидаясь получения подтверждения на них в виде ACK.
То есть параметр cwnd вроде как отвечает за количество отправляемых пакетов (полагаю, правильно тут — сегментов, но не суть)
Далее есть параметры ssthresh и awnd:
В качестве начального значения порога прекращения работы алгоритма slow-start (ssthresh) и перехода в режим избегания перегрузки (congestion avoidence) берётся значение максимального окна, которое предоставил получатель (advertised window — awnd). В нашем случае ssthresh=awnd=64K
То есть, «в нашем случае awnd=64 000», и речь уже об объёме данных.
Итого cwnd показывает количество сегментов, awnd — объём данных.
Я не могу понять, как в таком случае сопоставляются данные параметры во фразе
Размер окна cwnd достигает максимального значения и становится равным awnd, а значит, cwnd = ssthersh.
Неужели в нашем случае количество отправляемых пакетов может достигнуть числа 64000?
Administrators are advised to allow only trusted users to have SNMP access
и
The attacker must know the community strings to successfully launch an attack against an affected device.
ACL + крепкий community стринг должен спасти, ага.
Я полагаю (ну а скорее мечтаю, зная реалии) что люди, которые испольщуют Cisco ASA, должны следовать данным правилам по дефолту
А вы сравнивали цены на годовую подписку на блейды CP и лицензию на FP?
На сколько я знаю выигрыш там приличный. Именно поэтому мы сейчас вовсю тестируем FP с целью переноса на платформу функций URL\Application фильтрации с CheckPoint-а
Да вот в том то и дело, что нужен контроль… Сервера, хоть и не имеют GUI, обращаются к огромному количеству веб-ресурсов (git, maven, репозитории, etc) к которым доступ по IP предоставить сложно, ввиду огромного количества оных и тут нужна фильтрация именно по URL-ам.
Сейчас это делается либо открытием доступа по src IP, либо с помощью костылей типа «искуственных» AD Query и опять же выдёргиванием привязки юзер\IP из AD Security логов.
А хотелось бы чего-то более интеллектуального…
Да, теперь понятно, сначала это обычный 802.1x и в качестве radius-клиента у нас коммутатор\wlc.
Тогда такой практический вопрос. Понятно что для тех же linux worksation или Mac-OS мы можем использовать Cisco AnyConnect. Но как быть в случае если у нас нет GUI? То есть нужно что-то вроде консольного супликанта.
Борис, добрый день.
Спасибо за статью.
Правильно ли я понял, что в данном раскладе мы опять таки возвращаемся к активной аутентификации? То есть каждому пользователю с каждого его устройства нужно вводить логин\пароль через Cisco AnyConnect.
И что произойдёт если мы изменили политику доступа? Нужно ли будет пользователю «перелогиниться» чтобы политики применились к нему?
Сергей, добрый день.
Я правильно из всего этого понял, что по факту роутинг во всех Cisco роутерах до ISR 4300 (то есть вся линейка ISR G2) осуществлялся «софтварно»?
У TMG была очень полезная приблуда — TMG-клиент. Эдакий проксификатор, который прозрачно для пользователя пропускал через прокси не только http\https трафик.
Есть что то подобное в комплекте данного софта?
Попробую вопрос по существу.
Можно ли сделать учётку в своём домене сделать администратором этого же домена?
Сейчас в качестве администратора можно подключить только ящик в mail\list\bk\inbox. Грустно.
Тем временем реальность - https://razrabs.ru/post/0e4e0a21-7fab-4f7f-a5f8-250b460e4d21
Привет! У VK, полагаю, тоже самое. Но суть статьи это не меняет. Теперь просто работаете по BYOL концепции.
Я правильно понял, что бы сделать такой LB кластер как минимум «внешние» интерфейсы должны быть в одной сети? Есть ли возможность собрать кластер когда ноды находятся в разных датацентрах, с разными IP адресами?
+ как быть в случае NAT, когда внешний интерфейс ASA спрятан за другим файрволлом, например? Что указывать в качестве VIP адреса? Публичнный или внутренний?
Спасибо!
Я не до конца понял, почему Вы разделили EVPN и MP-BGP EVPN. Бывает EVPN без BGP?
Единственное что термин «следующий участок сети» слегка режет слух сетевику. Полагаю, в оригинале было «next hop»? Вряд ли это можно нормально перевести, но в данном конексте звучало бы лучше если бы использовалось просто понятие маршрута. Сравните:
«Перехэширование случается, когда изменяется информация о следующих участках сети… Указывая в таблице маршрутизации статичные следующие участки сети, мы можем заставить коммутатор...»
и
«Перехэширование случается, когда изменяется информация о маршрутах… Указывая в таблице маршрутизации статические маршруты, мы можем заставить коммутатор...»
То есть в итоге, есть некоторый коэффициент, ну допустим «K» (который в начале равен именно 10 в нашем случае), и растёт именно этот «K», пока произведение K*MSS (читай cwnd) не достигнет awnd? Именно этот «K» и определяет «количество отправляемых сегментов без ACK». И например при MSS = 1460 байт, «K» достигнет максимума при значении 64000/1460≈43
и подумал, что cwnd — это всегда количество пакетов, которые можно отправить без ACK. Возможно что подумал неверно, отсюда и вопрос.
Я в данной теории слаб, поэтому и хочу потдверждения\опровежения, что в рамках tcp сессии существует возможность отправить 64 000 сегмента не получая ACK от получателя
Вот есть у нас параметр cwnd, о нём пишется:
То есть параметр cwnd вроде как отвечает за количество отправляемых пакетов (полагаю, правильно тут — сегментов, но не суть)
Далее есть параметры ssthresh и awnd:
То есть, «в нашем случае awnd=64 000», и речь уже об объёме данных.
Итого cwnd показывает количество сегментов, awnd — объём данных.
Я не могу понять, как в таком случае сопоставляются данные параметры во фразе
Неужели в нашем случае количество отправляемых пакетов может достигнуть числа 64000?
Но всё равно, спасибо!
и
ACL + крепкий community стринг должен спасти, ага.
Я полагаю (ну а скорее мечтаю, зная реалии) что люди, которые испольщуют Cisco ASA, должны следовать данным правилам по дефолту
На сколько я знаю выигрыш там приличный. Именно поэтому мы сейчас вовсю тестируем FP с целью переноса на платформу функций URL\Application фильтрации с CheckPoint-а
Сейчас это делается либо открытием доступа по src IP, либо с помощью костылей типа «искуственных» AD Query и опять же выдёргиванием привязки юзер\IP из AD Security логов.
А хотелось бы чего-то более интеллектуального…
Тогда такой практический вопрос. Понятно что для тех же linux worksation или Mac-OS мы можем использовать Cisco AnyConnect. Но как быть в случае если у нас нет GUI? То есть нужно что-то вроде консольного супликанта.
В данном стенде, получает, вовсю используется trustsec? Иначе не понятно где конкретно мы проходим аутентификацию
Спасибо за статью.
Правильно ли я понял, что в данном раскладе мы опять таки возвращаемся к активной аутентификации? То есть каждому пользователю с каждого его устройства нужно вводить логин\пароль через Cisco AnyConnect.
И что произойдёт если мы изменили политику доступа? Нужно ли будет пользователю «перелогиниться» чтобы политики применились к нему?
Я правильно из всего этого понял, что по факту роутинг во всех Cisco роутерах до ISR 4300 (то есть вся линейка ISR G2) осуществлялся «софтварно»?
Есть что то подобное в комплекте данного софта?
Можно ли сделать учётку в своём домене сделать администратором этого же домена?
Сейчас в качестве администратора можно подключить только ящик в mail\list\bk\inbox. Грустно.