Robot_NagNews Опубликовано 12 апреля, 2013 · Жалоба Материал: Проблема модернизации мультисервисных сетей и расширение возможностей работающего оборудования особенно актуальны на сегодняшний день. Следует отметить, что подобные вопросы не имеют типовых решений и должны рассматриваться специалистами отрасли в контексте поставленных задач. Описанию разработки одного из таких решений и посвящена эта статья. Полный текст Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flamaster Опубликовано 12 апреля, 2013 · Жалоба ничего не рассказано в плане IPv6. интересно узнать масштабируемость выбранной топологий в случий IPv6. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ivb1232 Опубликовано 12 апреля, 2013 · Жалоба Вопрос мультикаста скупо освещен, P2MP MPVN ? Телефония, понимаю, L3VPN обычная. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 12 апреля, 2013 · Жалоба Зачем на Juniper MX делать NAT при наличии SE600? PE для больших клиентов (>1Гбит) я могу понять, но NAT совсем лишнее (Отдельную плату для этого нужно ведь). Поправьте картинку... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ivb1232 Опубликовано 12 апреля, 2013 · Жалоба BRAS/NAT SE600 на картинке есть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey Shepelev Опубликовано 12 апреля, 2013 · Жалоба НАТ на МХ нужен для обработки не ШПД абонентского трафика. В данном случае заказчик предполагает гонять через него LTE трафик в больших объемах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 12 апреля, 2013 · Жалоба НАТ на МХ нужен для обработки не ШПД абонентского трафика. В данном случае заказчик предполагает гонять через него LTE трафик в больших объемах. И чем LTE отличается от 'ШПД'? Имеется ввиду Интернет через LTE или какой-то другой сервис? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey Shepelev Опубликовано 12 апреля, 2013 · Жалоба Да конечно. некорректно выразился. Имелось ввиду что услуги LTE построены на базе отдельной сети, которая стыкуется с ядром и весь трафик натится именно на МХ в ядре. Это было пожелание заказчика которое мы реализовали установив специальный модуль MS-DPC. Имеется ввиду именно интернет для устройств с поддержкой LTE. Вопрос мультикаста возможно будет рассмотрен в других статьях ))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
max1976 Опубликовано 12 апреля, 2013 · Жалоба При получении dhcp запроса, на оборудовании центрального узла автоматически создается l3 интерфейс с номером Vlan соответствующим Vlan приходящего пакета, и адресом, выбранным согласно технологии ip unnumbered. Осуществляется преобразование broadcast dhcp запроса в unicast dhcp запрос, и передача его на третьем уровне модели OSI до оборудования BRAS. На оборудовании BRAS осуществляется авторизация абонентов в системе биллинга по технологии CLIPS, и выдачи ему адреса и соответствующих атрибутов. Это каким образом? На один dhcp запрос будет выдано 2 адреса (один там где ip unnumbered, а другой на BRASe) ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey Shepelev Опубликовано 12 апреля, 2013 · Жалоба почему же два? если внимательно прочитать текст то можно понять что на оборудовании узла создается влан и интерфейс, никакой выдачи адреса там нет как и каких то dhcp серверов. Вся авторизация через БРАС, с привязкой к оборудованию центрального узла через опцию шлюза по умолчанию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artmc Опубликовано 13 апреля, 2013 · Жалоба А какое оборудование было у оператора до модернизации? И схема то же интересна :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zoro Опубликовано 14 апреля, 2013 · Жалоба А на чем организованна борьба с трафиком с черной кармой? (реестр запрещенных сайтов) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey Shepelev Опубликовано 15 апреля, 2013 · Жалоба Реестр черных сайтов не входил в поставленную задачу и реализуется заказчиком самостоятельно, через DNS фильтры. На данный момент его это устраивает. Если бы вопрос стоял как задача к проекту мы бы предложили решение на SCE либо на чем нибудь позабористее (благо возможности были) типа CheckPoint или Allot. Но все это вопрос всяких холиваров. По поводу вопроса до модернизации: на всей сети стоял Huawei 93 серии и NE40 серии. Приятного было мало особенно временно "подружить" вендоров оказалось не так то просто. Я думаю об этом еще будет рассказано ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
depebo Опубликовано 15 апреля, 2013 · Жалоба А каким образом в этом проекте реализовывался сбор данных по трансляциям на NAT-ах? хорошо знаком с практикой силовиков запрашивать данные по доступу абонентов к каким-то ресурсам с определенных (транслированных) адресов в течение срока исковой давности, при этом порт на стороне провайдера они никогда не указывают - хранить приходится сессии Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 15 апреля, 2013 · Жалоба Приятного было мало особенно временно "подружить" вендоров оказалось не так то просто. Я думаю об этом еще будет рассказано ) Дружил S9300 и CX600(та же NE по сути) с Juniper MX. Единственное на что потратил время(пару часов, плюс-минус), это L2VPN Kompella и то сам виноват, что вместо того чтобы лезть в документацию в раздел VPLS Troubleshooting, стал трейсить сигнализацию на обеих железках. Хотя в документации на huawei есть целый минираздел "A Huawei Device Cannot Establish a PW with Another Vendor's Device on a Kompella VPLS Network" в котором написано: This fault is commonly caused by one of the following:The vpls bgp encapsulation { ethernet | vlan } command is not configured in the view. The ignore-mtu-match command is not configured in the VSI view. The default offset of another vendor's device is 1 and cannot be modified. When a Huawei device communicates with the device, the default offset of the Huawei device should be set to 1 and the site ID should not be set to 0. По другим протоколам никаких проблем не было Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey Shepelev Опубликовано 16 апреля, 2013 · Жалоба А каким образом в этом проекте реализовывался сбор данных по трансляциям на NAT-ах? Все собирается с центрального x670 потому как весь трафик сети ходит через него, и проблем особенно нет в этом плане. Дружил S9300 и CX600(та же NE по сути) Да в принципе проблема именно в этом и возникала, потому как клиент в большом количестве использует данную технологию. В итоге пришлось в экстренном режиме переключать часть узлов на MX потому что несмотря на то что l2vpn работали, какие то сервисы таки работали с косяками. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sintech Опубликовано 16 апреля, 2013 · Жалоба Каким образом обеспечивается переключение трафика на резервный BRAS в случае отказа основного? Интересует как IPoE так и PPPoE тип доступа. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 16 апреля, 2013 · Жалоба Да в принципе проблема именно в этом и возникала, потому как клиент в большом количестве использует данную технологию. В итоге пришлось в экстренном режиме переключать часть узлов на MX потому что несмотря на то что l2vpn работали, какие то сервисы таки работали с косяками. Ага, потом оказывается, что "косяки" это ошибка конфигурации(ваша ошибка), а не потому что вендор XXX говно. "Приятного было мало" можно сказать про любого вендора, с котором мало опыта работы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey Shepelev Опубликовано 17 апреля, 2013 · Жалоба Каким образом обеспечивается переключение трафика на резервный BRAS в случае отказа основного? Интересует как IPoE так и PPPoE тип доступа. Все просто, в случае с PPPoE все абоненты тянутся туннелями до БРАС-ов, оба БРАСА отвечают на запросы PPPoE подключений, и абонент терминируется на том брасе который ответил первым, если один из БРАСов не отвечает то все соответственно терминируются на втором. Вопрос с IPoE с помощью функционала Server Group который поднимается на dhcp relay (mx80) который ракидывает клиентам по двум серверам, в случае недоступности одного из серверов все абоненты отправляются на второй. что "косяки" это ошибка конфигурации(ваша ошибка), Если бы если бы =) Настройки l2 туннеля не представляют из себя ничего замысловатого на обоих концах, что там Хуавей что там Jun. Туннели даже поднимаются но почему то все работает не гладко, хотя меняешь железку на какую нибудь другую копируешь настройки и все взлетает. Кросс-вендор имхо не всегда лучший выбор. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 17 апреля, 2013 · Жалоба Если бы если бы =) Настройки l2 туннеля не представляют из себя ничего замысловатого на обоих концах, что там Хуавей что там Jun. Туннели даже поднимаются но почему то все работает не гладко, хотя меняешь железку на какую нибудь другую копируешь настройки и все взлетает. Кросс-вендор имхо не всегда лучший выбор. Когда работаете с mpls псевдопроводами, то тут не только сигнализация важна, но и структура самого медиатрафика. Скорее всего, у вас с одной стороны был vlan tag в eth-заголовке в нагрузке, а с другой нет(или с одной стороны 2 тега, с другой один в нагрузку запихивалось). Такое бывает, да, и из конфигурации это не всегда очевидно. Просто так и напишите, "не хватило опыта скрестить вендора А с вендором Б", а не то, что "мало приятного" или чего-то ещё. Каким образом обеспечивается переключение трафика на резервный BRAS в случае отказа основного? Интересует как IPoE так и PPPoE тип доступа. Все просто, в случае с PPPoE все абоненты тянутся туннелями до БРАС-ов, оба БРАСА отвечают на запросы PPPoE подключений, и абонент терминируется на том брасе который ответил первым, если один из БРАСов не отвечает то все соответственно терминируются на втором. Вопрос с IPoE с помощью функционала Server Group который поднимается на dhcp relay (mx80) который ракидывает клиентам по двум серверам, в случае недоступности одного из серверов все абоненты отправляются на второй. Вас спросили о том как "обеспечивается переключение трафика", а вы про сигнальный трафик только написали. Проще говоря, требуется ли переподнятие сессии для хождения "полезного" трафика в случае выхода одного bras из строя? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey Shepelev Опубликовано 18 апреля, 2013 · Жалоба Как прозвучал вопрос так и прозвучал ответ. Если бы вопрос был задан конкретно, так как сделали это Вы, то конечно же ответ прозвучал бы по другому. Да конечно вы правы абоненты не мигрируют с браса на брас в случае отказа одного из них. Согласен это не самая приятная ситуация, но другого выхода я не увидел. Поделитесь своими наработками в данной области буду благодарен. Все кто сидел на одном брасе будут просто переподключаться на другой брас. Т.е. абоненты конечно же пострадают, и им придется либо вручную либо по таймауту переключаться к сети. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
riddler63 Опубликовано 18 апреля, 2013 · Жалоба Если бы если бы =) Настройки l2 туннеля не представляют из себя ничего замысловатого на обоих концах, что там Хуавей что там Jun. Туннели даже поднимаются но почему то все работает не гладко, хотя меняешь железку на какую нибудь другую копируешь настройки и все взлетает. Кросс-вендор имхо не всегда лучший выбор. То есть вы свопнули сетку построенную чисто на Huawei на оборудование ТРЕХ вендоров, а потом в комментах заявляете что Кросс-вендор не лучший выбор? БРАВО! :) Уже лучше было тогда делать всё на Juniper, у них и BRAS есть и свичи и прочее. Да, присоединяюсь к вопросу: Какова схема резервирования BRAS в данном случае? Интересует поведение как абонентских сессий так и NAT сессий в случае выхода из строя на одном из BRAS: a) Интерфейса BRAS в сторону MAN сети. b) Линейной платы в сторону MAN сети. c) NAT платы d) Интерфейса в сторону Интернета Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 18 апреля, 2013 · Жалоба Андрей, надеюсь ты понимаешь что это косоглазые вопросы ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 18 апреля, 2013 · Жалоба а конечно вы правы абоненты не мигрируют с браса на брас в случае отказа одного из них. Согласен это не самая приятная ситуация, но другого выхода я не увидел. Поделитесь своими наработками в данной области буду благодарен. поделюсь лишь очень занимательными ссылками http://support.huawei.com/support/pages/kbcenter/view/product.do?actionFlag=searchManualContents&web_doc_id=SE0000634810&material_type=ProductManual&part_no=10132#dc_ne_cfg_010405 У juniper несколько более общий подход к проблеме копирования состояний динамический сущностей http://www.juniper.net/us/en/local/pdf/whitepapers/2000391-en.pdf (стр. 7) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tunny Опубликовано 19 апреля, 2013 · Жалоба НАТ на МХ нужен для обработки не ШПД абонентского трафика. В данном случае заказчик предполагает гонять через него LTE трафик в больших объемах. И чем LTE отличается от 'ШПД'? Имеется ввиду Интернет через LTE или какой-то другой сервис? видимо NAT без сабскрайберов имеется ввиду. плохо с ним у СЕ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...