lejek

Допускаю, что у мобильных операторов будущее уже наступило. Я не в курсе текущего развития DPI. Скажите есть готовые решения DPI с полноценным Subscriber Management для ШПД? Если есть, то это уже не плохо. Я о другом. Получается при сравнении схем с использованием браса и без него, предлагается взять его функции (не все конечно), перенести на другую железку и сказать, что он не нужен (анохронизм). Так можно пойти другим путем, взять функционал DPI перенести его на брас и сказать, что DPI не нужен. Не собираюсь спорить кто из них ближе к цели. Суть от этого не меняется, трафик абонента должен пройти через ОДНУ железку, на которой будет обработан в соответствии с правилами указанными биллингом. Но эта схема не очень укладывается со схемой названной ранее L3 ipoe, т.к. L3 это маршрутизация, там вполне допустимо, что разный трафик одного клиента будет проходить через разные DPI и как в этом случае будет работать шейпинг на каждом DPI мне не ведомо. Могу ошибаться, поправьте меня.

Да ладно, Вы не воспринимайте это так близко к сердцу. Я Вас прекрасно понял, просто Вы говорите о будущем, а я о настоящем. Когда Вы прилепите к dpi механизмы управления и учета пользователей из биллинга, то Ваш dpi станет вполне неплохим брасом (если хотите ipoe брасом), даже может быть первым брасом отлично работающим на 7 уровне. Ах да, еще потом понадобится добавить к нему маршрутизацию и наступит будущее, которое я представляю, когда на время становлюсь теоретиком :)

:)Маркетологи сами не умееют схемы рисовать, для них это делают инженеры. И этот маркетинговый булшит у нас >1M сессий онлайн переваривает, причем с точки зрения управления клиентами, нет разницы 5К сессий на брасе или 75К. То что люди не видели брасов это не порок, не могут же они пойти и просто купить. Поэтому иногда считают, что без брасов можно легко жить, ну или наоборот, считают что брас решит все проблемы.

Одна из основных задач современных брасов это размыть разницу между типами доступа. Т.е. сделать так чтобы Вам было пофигу, что хочет использовать клиент или вы готовы ему предложить: PPPoE, PPTP, DHCP или IPoE без DHCP. Чтобы для Вас они выглядили по максимуму одинаково и чтобы управляли Вы всеми этими сабскрайберами с помощью одних и тех же механизмов и легко могли заменить одно на другое. Многие вендоры уже близки к этому, например ALu, хуавей судя по моим тестам тоже близок к такому раскладу, juniper подтягивается но с оговорками, циски я давно не держал в руках, но судя по докладам с экспо они тоже в этом тренде (не люблю это манагерское слово).

Вы хотите принять трафик в 4 влане, накинуть на него 888 и отправить соседу? Если да, то Вы не правильно поняли принцип. Верхний тег накидывается на ingress порту и уходит в транк с этом влане. И наоборот, прилетает с двумя тегами и на egress снимает верхний тег. Т.е. на железке с куинку Вы не увидите внутренние теги.

Брас это не просто шейпер. Это централизованная сервисная модель. Он представляет возможность наиболее удобно управлять подписчиками услуг. Авторизация, аккаунтинг, изменение/добавление услуг налету (без разрывов и смены адресов), ну и шейпинг в том числе. Я не спорю что без него можно обойтись, но с ним ох как удобнее. Я полагаю, что при объемах в 15-20К сессий это уже ясно как белый день, когда цифра достигает 70К это даже не обсуждается.

:) Я, конечно, понимаю что это Ваше субъективное мнение, но ведь кто-то может поверить на слово. Нет однозначно правильных или неправильных решений. У всех разные топологии, разное оборудование и разный уровень админов и наконец могут быть разные задачи. В каждом конкретном случае будет свое наиболее оптимальное для обслуживания решение, а вот найти эту золотую середину это главная почти недостижимая задача.

В этих 5 минутах и проблема. Даже какие то 17К клиентов подключенных равномерно будут генерировать 60 запросов в сек. Некоторые безумные брасы (не буду показывать пальцем) вместо просто обновления аренды, формируют запрос авторизации. Но даже без запросов авторизации это повышенная нагрузка на DHCP сервер. Поэтому нужно искать золотую середину между DHCP нагрузкой и временем потери сервиса при аварии. Можно воспользоваться вендор-специфик механизмами основанными на VRRP с синхронизацией состояния сессий. В зависимости от реализации вполне удобная штука. Переключение проходит за считанные секунды. Такое резервирование (на мой взгляд) оптимальнее, чем мультишасси. Мультишасси это как раз взрослое решение для тех, кто на время перестал считать деньги или же для тех кто умеет обосновывать затраты с учетом потенциальных потерь при аварии.

2й брас в параллели с опущенным интерфейсом, как вариант. дауж, получается pppoe не так уж и плох Да можно и не с опущенным интерфейсом, в этом нет проблем, проблема только в контроле состояния сессии. PPPoE хорош именно этим. А в чем по вашему заключается трудность резервирования L2 по сравнению с резервированием L3?

А как? Я думал там все AAA завязано на DHCP. Автоинтерфейсы без этого конечно создаются, но разве в радиус что-то упадет без dhcp? У них это называется static-subscribers. http://www.juniper.net/techpubs/en_US/junos13.2/topics/concept/static-subscribers-overview.html Как-раз без автоинтерфейсов и по мне это огромный минус, т.к. вызывает дополнительную ручную работу, поэтому может рассматриваться исключительно для упертых юриков при их небольшой массовости.

Как бы traffic_segmentation не был хорош, все-таки ему далеко до vlan-per-user. По той причине, что он не избавляется от большого бродкаст домена и изолирует только трафик вверх. А вот бродкаст вниз не изолирутся, поэтому шторм зачастую может накрыть бродкастом большой участок сети. Различные фильтры и красивые примочки на доступе являются хорошими помощниками в относительно не больших сетях без зоопарков. Но когда сеть развивается несколько лет и по планам будет развиваться еще несколько лет, то без зоопарка (ну или домашнего живого уголка) не обойтись, а тогда возникнет явная проблема когда один коммутатор может одно, а другой коммутатор может другое, так теряется единый подход к настройке сети - в больших масштабах это критично. 17К клиентов это сеть уже близкая к средней и стоит задумываться о том, что она может стать большой. Насколько я понимаю поэтому и возникла тема. Кстати, Juniper MX умеет non-DHCP, правда не так красиво как это можно сделать на ALU 7750-SR (он мне вообще очень нравится) или хуавее, но для юриков (а как правило этого хотят юрики) реализуется вполне рабочая схема с авторизацией, созданием сессии и управлением через CoA.

Если исходить строго из желаний топикстартера, то соглашусь с вариантом Juniper MX в качестве браса. Все вышеописанные хотелки он может. Адреса по DHCP выдаст, маска сети может быть любая, всеравно роуты /32 инсталирует. Если клиенту противен DHCP и он хочет адрес руками прописать, то так тоже можно (авторизация по поднятию интерфейса будет). CLI у него вообще сказка. По надежности MX вселяет уверенность, хотя резервирование должно быть «де факто».

Я советую для каждого изолированного физического сегмента делать отдельный влан управления. Чтобы проблемы в одной части сети не прилетели в другую часть сети. Объединять можно уже на L3 уровне. Я не понял по поводу географического центра и про транзитные волокна. Все организуется по той же физике, по которой полетят данные клиентов и управление прилетает пачкой виланов в тот же центр где агрегируются клиенты. Оговорюсь. Речь идет о более менее крупной сети, в небольших сетях можно незаморачиваться.

По моему вы слабо представляете себе проблему. Зависит от модели коммутатора. длинк например на модели 1228me 3028 или 3200-28 ловит первую коллизию уже при 450 маках, на 1000 маках уже 10 коллизий, а при упомянутых вами 5000 маков коллизии приближаются к тысяче. По поводу 50 маков на доступе. Это почти идеалистическая ситуация на той топологии которая описана изначально. Если вы уверены, что за каждым портом всегда будет максимум 2 мака и сеть не будет расти, то можете пока не волноваться.

Зависит от планируемых объемов строительства сети. Планируемая Вами топология вполне жизнеспособна особенно на первых этапах эксплуатации. Причем если подключать один коммутатор двумя линками, то конечно используйте lag. Проблемы начнутся по мере роста сети. Во первых рост коммутаторов доступа потребует рост портов агрегации, а порты агрегации (в зависимости от оборудования) могут быть дороже коммутаторов доступа. Если быть уж совсем точным то самым дорогим окажутся волокна до каждого коммутатора. Рано или поздно Вы придете к схеме из цепочки доступа или к колечкам, возможно и к бардаку в виде того и другого. За этим последуют все минусы одного влана. Вы упоминали длинк. А эти коммутатроы (и многие другие) имеют известную проблемы с хешами. Чем больше будет маков тем больше у Вас будет вероятность получить из свитча хаб. Тогда будете переделывать на схему влан на свитч или влан на порт. Один влан управления на всю сеть, тоже плохая практика. Если в этом вилане произойдет "ой" или небольшой шторм или еще что-то, то потеряете всю сеть. Сегментация не всегда спасет, а иногда даже помешает. Найти источник проблемы окажется очень не просто, особенно когда коммутаторы недоступны (или постоянно теряются) по управлению. Просто поверьте мне на слово. Моя личная рекомендация (не претендую на истину) сегментировать L2 по максимуму. Вы заранее защитите себя от массы потенциальных проблем в будущем.

Согласитесь, это романтические мечты и маркетосы этого не допустят. Никогда не решится проблема совместимости со старым или специфическим оборудованием. Так же как сейчас не все даже новые SOHO железки умеют поднимать PPPoE. И с точки зрения бизнеса будет неуместно доказывать клиенту, что его субъективное мнение о PPPoE не имеет доказательной базы. Поэтому вместо того, чтобы спорить какой метод приземления абонента лучше, надо реализовать все и предоставлять выбор клиенту. Нужен не переход с PPPoE на IPoE, а просто (иногда это очень не просто) надо переделать доступ и аггрегацию на возможность максимальной изоляции клиентов с уникальной идентификацией. С брасами в этом плане проще и многие вендоры уже реализовали IPoE с радиус авторизацией, когда для биллинга IPoE почти не отличимы от PPPoE, та же radius авторизация, с выдачей сервисов, так же собирается radius accounting, тот же CoA (по крайней мере на ALU и Jun мы это сейчас тестируем).

Ну возможно у нас и оочень специфический баг, но и не все сервисы после switchover поднимаются. А по ресурсам - первое, что у нас заканчивается это очереди. P.S. Хотя общее впечатление от девайса на ШПД больше положительное, чем отрицательное.

Цели стать начальником нет и не было (возможно, потом появится). Более того изначально отказался, после повторных предложений договорились, что начну исполнять обязанности начальника и постараюсь оценить хочу ли я этого и справлюсь ли. Была цель изменить/улучшить текущее положение. Да, monofone прав, одно из наиболее логичных направлений развития это интеграторы в столицах. Можно собрать вещички и катить в резиновую столицу. Конечно, с распростертыми руками там никто не ждет, но за мечту можно побороться. Не простое решение, если учесть семью. Опять же вопрос не в одном конкретном админе. Таких админов по всей провинции сотни и ситуации у всех схожие, все не станут интеграторами. Может быть стоит послушать Voicemaster сжать зубы и выдержать более продолжительную паузу, отвлечся на семью, свалить в отпуск. Я об этом серьезно задумался. Проблема, действительно в отсутсвии четко сформулированной цели, но это жизнь, я не хочу нарисовать на бумаге план своей жизни и стремиться к цели, перешагивая головы и отказавшись от своих принципов. Проблема выбора. На что я согласен? Комфортное место с нищенской з.п. или некомфортное место с такой-же нищенской з.п. но в другом, возможно, более перспективном направлении и с попыткой полюбить ее, когда поймешь (чему-то научишься). Одна из целей поста узнать опыт других. Как и куда люди двигались дальше. Как справлялись со "стрессом адаптации". Интересно, если бы меня устраивала зарплата, пришел бы я к такой теме?

Этапы развития админа (которые, с небольшими отклонениями, прошли очень многие из здесь присутствующих). 1. Ты учишься в ВУЗе. Знаний 0+. Читаешь книжки, форумы, задаешь глупые вопросы "старшим" товарищам. Копаешь свой комп с виндой, линуксом, юниксом и т.д. Начинаешь помогать друзьям, родственникам, друзьям родственников и т.д. 2. Устраиваешься на первую работу админить небольшой офис. Прокладываешь провода, обжимаешь патчкорды, ругаешься на винду. Пытаешься сделать как лучше, но тебя ограничивают средствами, да и з.п. маловата. 3. Меняешь работу, даже не одну. Останавливаешься на более менее серьезной конторе (корпорация). Берешься за любой внутренний проект, потом еще за один, потом еще. Админишь распределенную сеть, общаешся с провайдером (иногда ругаешься с ним). Брендовое железо, брендовые серверы. Становишся ведущим админом или типа этого (с повышением з.п). Все знаешь, все умеешь. Но хочется чего то более глобального. Да и з.п. не хватает. 4. Предлагают работу у провайдера. Соглашаешься. Много нового, все интересно. Профессиональный рост как на дрожжах. Разобравшись во всем зоопарке, начинаешь чувствовать себе чуть ближе к богу, чем другие. Оптимизируешь, предлагаешь новые более красивые идеи/решения. 5. Уже ведущий админ у провайдера (не мелкого). Все работает, все контролируется. Рисуешь схемы по модернизации сети, предлагаешь замену оборудования. Тебя слушают, соглашаются. К тебе приходят за советом младшие менеджеры, старшие менеджеры и иногда даже топ менеджеры. Тебя все ценят, уважают и может быть даже любят. Обвешан грамотами за компетентность, профессионализм и т.п. Никто не понимает, почему ты не любишь китайцев и что значит когда ты "трахаешся с кошками", "куришь можжевельник" и сравниваешь "красножопых" с "алкоголем", но в эти моменты тебя не трогают. 6. Ты не доволен своей зарплатой, она смешная. Шантажировать руководство увольнением не в твоих правилах. Тебе уже 30. Жена. Ребенок. Но ты все еще остаешься АДМИНОМ. Что дальше? Задаешься вопросом хочешь ли ты до пенсии быть админом? Ответа нет. Руководство тоже чувствует твой кризис. Предлагают стать Начальником отдела. 7. Ты думаешь, что ты все еще админ, просто вот пару бумажек подпишешь. Ой бумажек не две... Черт их не согласовывают... *** совещание ... разговор ни о чем с неадекватными людьми. Отчеты, накладные, счета, акты, служебки. Что-то неуспел сделать ... ах да обещал скрипт написать, завтра сделаю. Завтра. Завал. Ты все это не тянешь. В подчинении админы - перекладываешь на них технические вопросы - ставишь задачи, сроки. Опять бумажки, обложился ими. Опа - твои бойцы сроки не выдерживают и смотрят на тебя как птенцы, которых выкидывают из гнезда, чтобы они полетели. Ладно ночью сам сделаю. Опять завтра. Без сна не привыкать. Опять подписать, согласовать, отправить, поставить задачу, проконтролировать ... пришлось дать звездюлей. Неделя. 8. Немного привык. Все вроде устаканилось, бумаги разложил по стопкам, бойцов проверил, отчеты отправил. Но что-то не так. Что? Мозг перестал участвовать в работе. Вообще не задействован. Вот проснулся сегодня и думаю - оно мне надо? Не нравится мне эта работа. Не к душе. На работу иду без желания. Еще пол года назад летал на крыльях. Было много планов по модернизации сети, ждал новое оборудование, аж слюни текли. В командировку железку тестировать, поезд через два часа, поедешь? Не вопрос. Что сейчас? Ничего нет - одни бумажки. Белый воротничек, начищенные ботинки. Где моя двухнедельная щетина? Наверно, не ту ветку развития выбрал. Это тупик? Где я прокололся? Как же другие прошли эту стадию? Пойду обновлю ios на каталистах во всем городе, давно уже хотел.

маленькая коробочка netping. 8 выносных датчиков. температуру можно снимать по snmp. http://www.netping.ru/product_item.aspx?id...ing_bases_TS-v2

1. Если Вы выстроите гирлянду таких свитчей (с изолированными портами) в дерево, то пользователи никак друг с другом общаться не будут.2. Или просто не выдавайте роуты по dhcp и Ваши пользователи остануться в в той-же л2 с 15 человеками. Хотят нормальные роуты - поднимают pptp или pppoe. Но лучше смотрите п.1 Сеть на неуправляемых свитчах страшное дело, но если очень надо и очень подумать, то будет работать.

В Вашем случае не будет разницы, терминируете Вы на серверах PPPoE или PPTP. Чтобы получить плюсы pppoe Вам необходимо исключить даже небольшие общие l2 сегменты. Иначе поимеете проблемы с ложными pppoe серверами и т.п проблемами. Вилан на юзера и PPPoE не выдержит критики. Поэтому чаще всего для экономии используют сегментацию портов. Многие коммутаторы-мыльницы легко перепаиваются или перенастраиваются собственными утилитами. Можно и купить уже готовые неуправляемые с изолированными портами.

Спасибо. Похоже скоро получится данный девайс потрогать. При реальной настройке, конечно, возникнет масса конкретных вопросов. Советы знающих людей никогда не помешают.