pingz Опубликовано 16 марта, 2017 · Жалоба Sm на аср имеет кучи примеров. Уже чуть ли не видеоуроки есть по настройке :) а у джуна? да все есть, вон качайте с сайта day one , и настраивайте :) А вообще с таким настроением нужно микротик ставить, если не можете найти документацию и разобраться в ней Вы забыли уточнить, что документацией очень много это как пазетивный момент так и отрицательный. Связанных примеров очень мало т.к. комюнити маленькое по джуну. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
furai Опубликовано 16 марта, 2017 · Жалоба Знаю, что РТК переехал почти полностью на BRAS Juniper MX. РТК почти полностью переехал на Huawei ME60 с джунов. Нет. Сидеть на одном вендоре имея миллион и больше абонентов - не самое разумное решение... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 17 марта, 2017 · Жалоба Нет. Сидеть на одном вендоре имея миллион и больше абонентов - не самое разумное решение... Почему ? Нужно держать 2-3 или даже 4ре вендора и постоянно допиливать биллинг под этих всех вендоров ? Другой вопрос что ввиду некоторых условий , может быть более одного вендора , и обычно обусловлено разделением сети на регионы, филиалы (или еще как-нибудь). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 17 марта, 2017 · Жалоба Резервирование от уязвимостей не рассматривали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 17 марта, 2017 · Жалоба Ну это уже паранойя , от багов еще ладно, но уязвимости ... нужно будет все рано доберутся. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
buckethead Опубликовано 17 марта, 2017 · Жалоба Нет. Сидеть на одном вендоре имея миллион и больше абонентов - не самое разумное решение... Я уже выше по этому поводу написал :) Почему ? Нужно держать 2-3 или даже 4ре вендора и постоянно допиливать биллинг под этих всех вендоров ? Вот, кстати, EDSG очень сильно похож на ISG, там допиливать не так много. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 17 марта, 2017 · Жалоба Ну это уже паранойя , от багов еще ладно, но уязвимости ... нужно будет все рано доберутся. Я знаю пару провайдеров у которых все на Juniper MX, но в стойки рядом стоят на холодную ASR. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
furai Опубликовано 17 марта, 2017 (изменено) · Жалоба Вендоры имеют свойство делать меньшие скидки и/или оказывать поддержку спустя рукава, когда у заказчика слишком много оборудования, чтобы иметь возможность быстро сделать swap железа на другое и нет опыта работы с железками других вендоров. :) Изменено 17 марта, 2017 пользователем furai Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
furai Опубликовано 17 марта, 2017 (изменено) · Жалоба Проблему постоянного допиливания можно победить использованием на разном железе одной унифицированной сервисной модели, т.е. для биллинга брасы разных вендоров должны отличаться только названиями атрибутов или их числом, но не механизмами обработки, плюс надо осторожно использовать всякие вендорспецифичные фишки вроде цискиного prepaid. Если некуда деваться, кмк можно вынести параметры политик на отдельный policy server и пилить уже его своими силами. Изменено 17 марта, 2017 пользователем furai Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
buckethead Опубликовано 18 марта, 2017 · Жалоба Прикольно у вас там всё устроено) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 18 марта, 2017 · Жалоба Вендоры имеют свойство делать меньшие скидки и/или оказывать поддержку спустя рукава, когда у заказчика слишком много оборудования, чтобы иметь возможность быстро сделать swap железа на другое и нет опыта работы с железками других вендоров. :) Эммм , странная логика , не сталкивался с таким. Проблему постоянного допиливания можно победить использованием на разном железе одной унифицированной сервисной модели, т.е. для биллинга брасы разных вендоров должны отличаться только названиями атрибутов или их числом, но не механизмами обработки, плюс надо осторожно использовать всякие вендорспецифичные фишки вроде цискиного prepaid. Если некуда деваться, кмк можно вынести параметры политик на отдельный policy server и пилить уже его своими силами. У разных вендоров , может быть разная реализация тех или иных нужных фич. И при многовендорности , все равно придется допиливтать. Полиси сервер конечно облечит задачу в этом случае , но не избавит от этого полностью , и нужно не забывать что полиси сервер тоже стоит денег и часто не маленьких Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
furai Опубликовано 21 марта, 2017 (изменено) · Жалоба Если будет необходимость в допиливании, допиливать все равно меньше, чем в общем случае. И policy server - необязательно какой-нибудь juniper SRC PE; я писал про, к примеру, freeradius c набором скриптов. Изменено 21 марта, 2017 пользователем furai Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...