1. Как правило, все делают взаимодействие с NTP-сервером, а также сборником SNMP-пробов и Syslog-сообщений. Иногда — с почтовым сервером для рассылки информационных писем о состоянии комплекса.
2. Если требуется интеграция с биллингом, то, очевидно, необходимо осуществлять взаимодействие с существующей OSS/BSS системой оператора. Интерфейсы могут быть самые разные — RADIUS, DHCP, SOAP, JSON, Gx, Gy и другие.
3. Если необходимо обеспечить видимость BGP AS Path, то нужно делать BGP-стык с операторским ASBR.
4. Если необходимо сливать статистику во внешнее хранилище, то требуется связка с внешним хранилищем.
С точки зрения окружающих DPI устройств, он работает в прозрачном режиме, с точки зрения L2 DPI невидим. Есть несколько кейсов, когда коробка начинает интерактивно общаться с пользователем, но это частные случаи.
Если вопрос был про инкапсуляцию, с которой умеет работать DPI, то, как правило, это могут быть как голый Ethernet, так и dot1q, Q-in-Q, MPLS, GRE, PPPoE, 6in4, причём с разными уровнями вложенности.
Что понимается под «колбасить трафик»? Если вы корректно зададите вопрос, я смогу на него ответить:)
Хороший вопрос. DPI — функционал полностью софтовый, никаких ASIC, работающих с тем или иным приложением, разумеется, нет. Так что в описанной задаче не вижу ничего экстраординарного. Очевидно, немного вырастет нагрузка на процессоры, т.к. код сигнатуры будет более хитрым, но не более того.
Как правило, физически DPI размещается либо на границе сети оператора (перед или после ASBR), либо сразу после коробки, выполняющей роль BRAS.
Вопрос про логику немного не понял, что имелось в виду?
Всё так, таковы требования рынка и тенденции его развития, DPI же воплощает эти идеи в жизнь. Есть довольно много аналитики на эту тему, многие склоняются к тому, что продажа трубы — это тупиковая ветвь развития.
Технически устроить асимметрию возможно, после чего у DPI поедет голова, всё верно. У циски не совсем поедет, т.к. она умеет работать с половинчатыми частями соединений.
Есть масса промежуточных устройств, которые от такого количества соединений упадут куда раньше, чем DPI, не стоит об этом забывать.
Если опустить предыдущее предложение, то DPI, конечно же, не упадёт. Просто при достижении определённого значения активных соединений коробка перестанет обрабатывать новые. Т.е., к примеру, есть коробка, рассчитанная на 60M соединений. Активно в какую-то единицу времени 59.5M соединений. Натравливаем вышеупомянутый скрипт, генерируем новые сесии, наблюдаем. Видим, что после достижения 60M соединений коробка перестаёт создавать новые сессии. А вот что произойдёт дальше, зависит от реализации того или иного вендора. Может быть следующее поведение:
— Новые сессии просто дропаются и не пропускаются через DPI.
— Новые сессии шунтируются и пропускаются через DPI без анализа.
Вообще, всегда есть крутилка, позволяющая ограничить количество соединений, которые могут быть активны на одном сетевом хосте. Также есть крутилка, регулирующая рейт новых CPS (connections per second) — всё, что будет выше этого рейта, будет дропаться.
Так что DPI довольно элегантно можно использоваться для защиты от простейших DDoS атак.
почему не стоит покупать 4-ехпортовую 10G-плату, а лучше купить восьми и выключить 4 из них
Да, Janus он такой, нехороший. Superman, Tycho, меня сейчас на слезу пробьёт))
1) Вы видели хотя бы раз SUP32 в 7600, купленном в последние несколько лет?
2) cisco.com.
3) Ок, засчитано.
4) 40Gbps с фабрикой умеют только слоты с 9 по 13. Соответственно, при необходимости иметь полнодуплексные 40Gbps на лайнкарте, её надобно пихать только в упомянутые слоты. Есть карты, требующие 40Gbps до фабрики, такие просто не заработают в других слотах.
5) cisco.com.
Сейчас используется два основных типа этих плат: Supervisor 720 и Supervisor 32. Первый Cisco рекомендует использовать в ядре сети, второй же на пограничных узлах.
Не, я, конечно всё понимаю, но…
Какого года статья?
Где SUP 2T (применительно к 6500)?
Где можно увидеть разницу между CFC и DFC?
Где нюанс 7613, связанный с ёмкостью бэкплэйна в разных слотах при использовании SUP720/RSP720?
Перед обновлением рекомендую проверять все ли драйвера имеются по Win8. Я столкнулся с очень неприятной ситуацией — отсутствие поддержки GMA3650, который несёт на борту мой неттопчик. Универсальный драйвер навевает тоску, т.к. я не могу выставить нормальное разрешение и имею тормоза при просмотре видео.
На форуме Intel официальный представитель заявил, что планов по выпуску драйверов на GMA3600/3650 под восьмёрку у них нет. Если это возможно, хотелось бы услышать мнение компании Microsoft по данному вопросу. Если ответ будет отрицательным, я бы хотел инициировать процедуру cashback за апгрейд своей лицензии до восьмёрки. При проверке системы на совместимость с Win8, инсталлятор сказал, что проблем не будет.
А гугл плей нормально работает с телефона? Я спокойно могу ходить по магазину, изучать контент. Но как только я нажимаю на «скачать» или «обновить», ничего не происходит, закачка не стартует. Вырубаешь на роутере шестёрку — всё начинает качаться.
В итоге мы пришли к тому, с его начали — с аналога 82-й опции:) Иных способов явной авторизации сабскрайбера в модели IPoE я не вижу.
Или вы предлагаете назначать шестой адрес, основываясь на маке, который увидел гейтвей при назначении v4 посредством 82-й опции? В принципе, возможно, но слегка монструозно выглядит. С другой стороны, свитчи не надо переучивать, что хорошо. Надо подумать на досуге.
Что касается экспериментов с шестёркой дома, то я теста ради поднял на роутере 6in4 до tunnelbroker, поигрался минут 15 и выключил. Всё работает тормознуто, ибо крюк через Амстердам даёт о себе знать. Картинки с фэйсбука грузились только после принудительного рефреша страницы. Google Play на телефоне работал, но не позволял скачивать контент. В общем, увы, даже такие монстры, указанные мной выше, пока ещё не готовы к IPv6-only работе, что говорить о более мелких игроках.
При модели C-VLAN для каждого VLAN периодически (таймеры крутятся) будет генериться свой уникальный RA (с уникальным префиксом), сигнализирующий живучесть роутера. Т.е. при наличии 1000 VLAN гейтвей должен будет периодически генерить 1000 RA-пакетов. В случае использования одного большого VLAN для всех абонентов периодический анонс RA будет заключаться в анонсе лишь одного пакета. Стало быть, экономим на контрол плэйне.
Спорное утверждение, это зависит от архитектуры сети. Поясню.
В мире IPv6, как известно, есть несколько моделей назначения IPv6-адресов, делятся они на два типа — stateless и stateful.
В первом случае хост совершает автоконфигурацию, проверяет адрес на уникальность посредством механизма DAD, и затем начинается полноценная работа в сети.
Во втором случае хост запрашивает у DHCPv6-сервера адрес по аналогии с обычным DHCP, автоконфигурация не используется. В RFC 3315 описан Interface-Id Option, т.е. в DHCPv6 есть косвенный аналог option 82, который требуется для авторизации абонента по порту.
Теперь к вопросу о необходимости авторизации. В том случае, если используется stateless-модель, то единственный способ понять, за каким префиксом скрывается юзер Вася, это использовать модель C-VLAN, когда за каждым пользователем закрепляется конкретный префикс, и у оператора есть соответствующая таблица соответствия. Если юзеру Васе нужно выключить интернет, то просто отключаем анонс RA в конкретном VLAN и он не сможет выйти в сеть. В случае использования stateful-модели, когда все пользователи (как правило) живут в одном VLAN, единственным способом идентификации Васи является использование указанной мной выше опции. Если Васе надо отключить интернет, то DHCPv6-сервер просто не выдаст ему IPv6-адрес на основании ответа из биллинга. Проще говоря — необходимость в опции целиком и полностью зависит от используемой оператором архитектуры. На операторском уровне я целиком и полностью за stateful-модель, т.к. в случае использования stateless в паре с C-VLAN, гейтвей должен будет периодически генерить херову кучу RA-пакетов, что в конечном итоге может негативно сказаться на его control plane. Использование stateful-модели позволяет сократить количество периодически отправляемых RA-пакетов до одной штуки (отправку RA, которая триггерится по иным событиям, я не учитываю).
1. Как правило, все делают взаимодействие с NTP-сервером, а также сборником SNMP-пробов и Syslog-сообщений. Иногда — с почтовым сервером для рассылки информационных писем о состоянии комплекса.
2. Если требуется интеграция с биллингом, то, очевидно, необходимо осуществлять взаимодействие с существующей OSS/BSS системой оператора. Интерфейсы могут быть самые разные — RADIUS, DHCP, SOAP, JSON, Gx, Gy и другие.
3. Если необходимо обеспечить видимость BGP AS Path, то нужно делать BGP-стык с операторским ASBR.
4. Если необходимо сливать статистику во внешнее хранилище, то требуется связка с внешним хранилищем.
Если вопрос был про инкапсуляцию, с которой умеет работать DPI, то, как правило, это могут быть как голый Ethernet, так и dot1q, Q-in-Q, MPLS, GRE, PPPoE, 6in4, причём с разными уровнями вложенности.
Что понимается под «колбасить трафик»? Если вы корректно зададите вопрос, я смогу на него ответить:)
Вопрос про логику немного не понял, что имелось в виду?
Если опустить предыдущее предложение, то DPI, конечно же, не упадёт. Просто при достижении определённого значения активных соединений коробка перестанет обрабатывать новые. Т.е., к примеру, есть коробка, рассчитанная на 60M соединений. Активно в какую-то единицу времени 59.5M соединений. Натравливаем вышеупомянутый скрипт, генерируем новые сесии, наблюдаем. Видим, что после достижения 60M соединений коробка перестаёт создавать новые сессии. А вот что произойдёт дальше, зависит от реализации того или иного вендора. Может быть следующее поведение:
— Новые сессии просто дропаются и не пропускаются через DPI.
— Новые сессии шунтируются и пропускаются через DPI без анализа.
Вообще, всегда есть крутилка, позволяющая ограничить количество соединений, которые могут быть активны на одном сетевом хосте. Также есть крутилка, регулирующая рейт новых CPS (connections per second) — всё, что будет выше этого рейта, будет дропаться.
Так что DPI довольно элегантно можно использоваться для защиты от простейших DDoS атак.
Да, Janus он такой, нехороший. Superman, Tycho, меня сейчас на слезу пробьёт))
Задам наводящий вопрос — есть 7600, надо сделать VPLS в сторону клиента, какую карту надо купить?
2) cisco.com.
3) Ок, засчитано.
4) 40Gbps с фабрикой умеют только слоты с 9 по 13. Соответственно, при необходимости иметь полнодуплексные 40Gbps на лайнкарте, её надобно пихать только в упомянутые слоты. Есть карты, требующие 40Gbps до фабрики, такие просто не заработают в других слотах.
5) cisco.com.
SIP-карты — карты с кучей разных интерфейсов.
Для вас реально эти карты характеризуются только этим или вы над нами тонко прикалываетесь?
Не, я, конечно всё понимаю, но…
Какого года статья?
Где SUP 2T (применительно к 6500)?
Где можно увидеть разницу между CFC и DFC?
Где нюанс 7613, связанный с ёмкостью бэкплэйна в разных слотах при использовании SUP720/RSP720?
бывает 7603, 7606, 7609, 7613.
Ещё 7604 есть.
На форуме Intel официальный представитель заявил, что планов по выпуску драйверов на GMA3600/3650 под восьмёрку у них нет. Если это возможно, хотелось бы услышать мнение компании Microsoft по данному вопросу. Если ответ будет отрицательным, я бы хотел инициировать процедуру cashback за апгрейд своей лицензии до восьмёрки. При проверке системы на совместимость с Win8, инсталлятор сказал, что проблем не будет.
Или вы предлагаете назначать шестой адрес, основываясь на маке, который увидел гейтвей при назначении v4 посредством 82-й опции? В принципе, возможно, но слегка монструозно выглядит. С другой стороны, свитчи не надо переучивать, что хорошо. Надо подумать на досуге.
Что касается экспериментов с шестёркой дома, то я теста ради поднял на роутере 6in4 до tunnelbroker, поигрался минут 15 и выключил. Всё работает тормознуто, ибо крюк через Амстердам даёт о себе знать. Картинки с фэйсбука грузились только после принудительного рефреша страницы. Google Play на телефоне работал, но не позволял скачивать контент. В общем, увы, даже такие монстры, указанные мной выше, пока ещё не готовы к IPv6-only работе, что говорить о более мелких игроках.
В мире IPv6, как известно, есть несколько моделей назначения IPv6-адресов, делятся они на два типа — stateless и stateful.
В первом случае хост совершает автоконфигурацию, проверяет адрес на уникальность посредством механизма DAD, и затем начинается полноценная работа в сети.
Во втором случае хост запрашивает у DHCPv6-сервера адрес по аналогии с обычным DHCP, автоконфигурация не используется. В RFC 3315 описан Interface-Id Option, т.е. в DHCPv6 есть косвенный аналог option 82, который требуется для авторизации абонента по порту.
Теперь к вопросу о необходимости авторизации. В том случае, если используется stateless-модель, то единственный способ понять, за каким префиксом скрывается юзер Вася, это использовать модель C-VLAN, когда за каждым пользователем закрепляется конкретный префикс, и у оператора есть соответствующая таблица соответствия. Если юзеру Васе нужно выключить интернет, то просто отключаем анонс RA в конкретном VLAN и он не сможет выйти в сеть. В случае использования stateful-модели, когда все пользователи (как правило) живут в одном VLAN, единственным способом идентификации Васи является использование указанной мной выше опции. Если Васе надо отключить интернет, то DHCPv6-сервер просто не выдаст ему IPv6-адрес на основании ответа из биллинга. Проще говоря — необходимость в опции целиком и полностью зависит от используемой оператором архитектуры. На операторском уровне я целиком и полностью за stateful-модель, т.к. в случае использования stateless в паре с C-VLAN, гейтвей должен будет периодически генерить херову кучу RA-пакетов, что в конечном итоге может негативно сказаться на его control plane. Использование stateful-модели позволяет сократить количество периодически отправляемых RA-пакетов до одной штуки (отправку RA, которая триггерится по иным событиям, я не учитываю).
В общем, не надо таких ультимативных заявлений.