Jump to content

lejek

Пользователи
  • Posts

    51
  • Joined

  • Last visited

About lejek

  • Rank
    Абитуриент
    Абитуриент

Контакты

  • ICQ
    Array

Recent Profile Visitors

972 profile views
  1. Конечно опишу, но только не в открытом общении.

  2. Добрый день, мне нужна консультация по выбору модели Micritik под конкретные задачи. Вы можете мне помочь?

  3. Допускаю, что у мобильных операторов будущее уже наступило. Я не в курсе текущего развития DPI. Скажите есть готовые решения DPI с полноценным Subscriber Management для ШПД? Если есть, то это уже не плохо. Я о другом. Получается при сравнении схем с использованием браса и без него, предлагается взять его функции (не все конечно), перенести на другую железку и сказать, что он не нужен (анохронизм). Так можно пойти другим путем, взять функционал DPI перенести его на брас и сказать, что DPI не нужен. Не собираюсь спорить кто из них ближе к цели. Суть от этого не меняется, трафик абонента должен пройти через ОДНУ железку, на которой будет обработан в соответствии с правилами указанными биллингом. Но эта схема не очень укладывается со схемой названной ранее L3 ipoe, т.к. L3 это маршрутизация, там вполне допустимо, что разный трафик одного клиента будет проходить через разные DPI и как в этом случае будет работать шейпинг на каждом DPI мне не ведомо. Могу ошибаться, поправьте меня.
  4. Да ладно, Вы не воспринимайте это так близко к сердцу. Я Вас прекрасно понял, просто Вы говорите о будущем, а я о настоящем. Когда Вы прилепите к dpi механизмы управления и учета пользователей из биллинга, то Ваш dpi станет вполне неплохим брасом (если хотите ipoe брасом), даже может быть первым брасом отлично работающим на 7 уровне. Ах да, еще потом понадобится добавить к нему маршрутизацию и наступит будущее, которое я представляю, когда на время становлюсь теоретиком :)
  5. :)Маркетологи сами не умееют схемы рисовать, для них это делают инженеры. И этот маркетинговый булшит у нас >1M сессий онлайн переваривает, причем с точки зрения управления клиентами, нет разницы 5К сессий на брасе или 75К. То что люди не видели брасов это не порок, не могут же они пойти и просто купить. Поэтому иногда считают, что без брасов можно легко жить, ну или наоборот, считают что брас решит все проблемы.
  6. Одна из основных задач современных брасов это размыть разницу между типами доступа. Т.е. сделать так чтобы Вам было пофигу, что хочет использовать клиент или вы готовы ему предложить: PPPoE, PPTP, DHCP или IPoE без DHCP. Чтобы для Вас они выглядили по максимуму одинаково и чтобы управляли Вы всеми этими сабскрайберами с помощью одних и тех же механизмов и легко могли заменить одно на другое. Многие вендоры уже близки к этому, например ALu, хуавей судя по моим тестам тоже близок к такому раскладу, juniper подтягивается но с оговорками, циски я давно не держал в руках, но судя по докладам с экспо они тоже в этом тренде (не люблю это манагерское слово).
  7. Вы хотите принять трафик в 4 влане, накинуть на него 888 и отправить соседу? Если да, то Вы не правильно поняли принцип. Верхний тег накидывается на ingress порту и уходит в транк с этом влане. И наоборот, прилетает с двумя тегами и на egress снимает верхний тег. Т.е. на железке с куинку Вы не увидите внутренние теги.
  8. Брас это не просто шейпер. Это централизованная сервисная модель. Он представляет возможность наиболее удобно управлять подписчиками услуг. Авторизация, аккаунтинг, изменение/добавление услуг налету (без разрывов и смены адресов), ну и шейпинг в том числе. Я не спорю что без него можно обойтись, но с ним ох как удобнее. Я полагаю, что при объемах в 15-20К сессий это уже ясно как белый день, когда цифра достигает 70К это даже не обсуждается.
  9. :) Я, конечно, понимаю что это Ваше субъективное мнение, но ведь кто-то может поверить на слово. Нет однозначно правильных или неправильных решений. У всех разные топологии, разное оборудование и разный уровень админов и наконец могут быть разные задачи. В каждом конкретном случае будет свое наиболее оптимальное для обслуживания решение, а вот найти эту золотую середину это главная почти недостижимая задача.
  10. В этих 5 минутах и проблема. Даже какие то 17К клиентов подключенных равномерно будут генерировать 60 запросов в сек. Некоторые безумные брасы (не буду показывать пальцем) вместо просто обновления аренды, формируют запрос авторизации. Но даже без запросов авторизации это повышенная нагрузка на DHCP сервер. Поэтому нужно искать золотую середину между DHCP нагрузкой и временем потери сервиса при аварии. Можно воспользоваться вендор-специфик механизмами основанными на VRRP с синхронизацией состояния сессий. В зависимости от реализации вполне удобная штука. Переключение проходит за считанные секунды. Такое резервирование (на мой взгляд) оптимальнее, чем мультишасси. Мультишасси это как раз взрослое решение для тех, кто на время перестал считать деньги или же для тех кто умеет обосновывать затраты с учетом потенциальных потерь при аварии.
  11. 2й брас в параллели с опущенным интерфейсом, как вариант. дауж, получается pppoe не так уж и плох Да можно и не с опущенным интерфейсом, в этом нет проблем, проблема только в контроле состояния сессии. PPPoE хорош именно этим. А в чем по вашему заключается трудность резервирования L2 по сравнению с резервированием L3?
  12. А как? Я думал там все AAA завязано на DHCP. Автоинтерфейсы без этого конечно создаются, но разве в радиус что-то упадет без dhcp? У них это называется static-subscribers. http://www.juniper.net/techpubs/en_US/junos13.2/topics/concept/static-subscribers-overview.html Как-раз без автоинтерфейсов и по мне это огромный минус, т.к. вызывает дополнительную ручную работу, поэтому может рассматриваться исключительно для упертых юриков при их небольшой массовости.
  13. Как бы traffic_segmentation не был хорош, все-таки ему далеко до vlan-per-user. По той причине, что он не избавляется от большого бродкаст домена и изолирует только трафик вверх. А вот бродкаст вниз не изолирутся, поэтому шторм зачастую может накрыть бродкастом большой участок сети. Различные фильтры и красивые примочки на доступе являются хорошими помощниками в относительно не больших сетях без зоопарков. Но когда сеть развивается несколько лет и по планам будет развиваться еще несколько лет, то без зоопарка (ну или домашнего живого уголка) не обойтись, а тогда возникнет явная проблема когда один коммутатор может одно, а другой коммутатор может другое, так теряется единый подход к настройке сети - в больших масштабах это критично. 17К клиентов это сеть уже близкая к средней и стоит задумываться о том, что она может стать большой. Насколько я понимаю поэтому и возникла тема. Кстати, Juniper MX умеет non-DHCP, правда не так красиво как это можно сделать на ALU 7750-SR (он мне вообще очень нравится) или хуавее, но для юриков (а как правило этого хотят юрики) реализуется вполне рабочая схема с авторизацией, созданием сессии и управлением через CoA.
  14. Если исходить строго из желаний топикстартера, то соглашусь с вариантом Juniper MX в качестве браса. Все вышеописанные хотелки он может. Адреса по DHCP выдаст, маска сети может быть любая, всеравно роуты /32 инсталирует. Если клиенту противен DHCP и он хочет адрес руками прописать, то так тоже можно (авторизация по поднятию интерфейса будет). CLI у него вообще сказка. По надежности MX вселяет уверенность, хотя резервирование должно быть «де факто».
  15. Я советую для каждого изолированного физического сегмента делать отдельный влан управления. Чтобы проблемы в одной части сети не прилетели в другую часть сети. Объединять можно уже на L3 уровне. Я не понял по поводу географического центра и про транзитные волокна. Все организуется по той же физике, по которой полетят данные клиентов и управление прилетает пачкой виланов в тот же центр где агрегируются клиенты. Оговорюсь. Речь идет о более менее крупной сети, в небольших сетях можно незаморачиваться.