Robot_NagNews Posted April 12, 2013 · Report post Материал: Проблема модернизации мультисервисных сетей и расширение возможностей работающего оборудования особенно актуальны на сегодняшний день. Следует отметить, что подобные вопросы не имеют типовых решений и должны рассматриваться специалистами отрасли в контексте поставленных задач. Описанию разработки одного из таких решений и посвящена эта статья. Полный текст Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
flamaster Posted April 12, 2013 · Report post ничего не рассказано в плане IPv6. интересно узнать масштабируемость выбранной топологий в случий IPv6. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ivb1232 Posted April 12, 2013 · Report post Вопрос мультикаста скупо освещен, P2MP MPVN ? Телефония, понимаю, L3VPN обычная. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dmvy Posted April 12, 2013 · Report post Зачем на Juniper MX делать NAT при наличии SE600? PE для больших клиентов (>1Гбит) я могу понять, но NAT совсем лишнее (Отдельную плату для этого нужно ведь). Поправьте картинку... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ivb1232 Posted April 12, 2013 · Report post BRAS/NAT SE600 на картинке есть. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Andrey Shepelev Posted April 12, 2013 · Report post НАТ на МХ нужен для обработки не ШПД абонентского трафика. В данном случае заказчик предполагает гонять через него LTE трафик в больших объемах. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted April 12, 2013 · Report post НАТ на МХ нужен для обработки не ШПД абонентского трафика. В данном случае заказчик предполагает гонять через него LTE трафик в больших объемах. И чем LTE отличается от 'ШПД'? Имеется ввиду Интернет через LTE или какой-то другой сервис? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Andrey Shepelev Posted April 12, 2013 · Report post Да конечно. некорректно выразился. Имелось ввиду что услуги LTE построены на базе отдельной сети, которая стыкуется с ядром и весь трафик натится именно на МХ в ядре. Это было пожелание заказчика которое мы реализовали установив специальный модуль MS-DPC. Имеется ввиду именно интернет для устройств с поддержкой LTE. Вопрос мультикаста возможно будет рассмотрен в других статьях ))) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
max1976 Posted April 12, 2013 · Report post При получении dhcp запроса, на оборудовании центрального узла автоматически создается l3 интерфейс с номером Vlan соответствующим Vlan приходящего пакета, и адресом, выбранным согласно технологии ip unnumbered. Осуществляется преобразование broadcast dhcp запроса в unicast dhcp запрос, и передача его на третьем уровне модели OSI до оборудования BRAS. На оборудовании BRAS осуществляется авторизация абонентов в системе биллинга по технологии CLIPS, и выдачи ему адреса и соответствующих атрибутов. Это каким образом? На один dhcp запрос будет выдано 2 адреса (один там где ip unnumbered, а другой на BRASe) ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Andrey Shepelev Posted April 12, 2013 · Report post почему же два? если внимательно прочитать текст то можно понять что на оборудовании узла создается влан и интерфейс, никакой выдачи адреса там нет как и каких то dhcp серверов. Вся авторизация через БРАС, с привязкой к оборудованию центрального узла через опцию шлюза по умолчанию. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
artmc Posted April 13, 2013 · Report post А какое оборудование было у оператора до модернизации? И схема то же интересна :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zoro Posted April 14, 2013 · Report post А на чем организованна борьба с трафиком с черной кармой? (реестр запрещенных сайтов) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Andrey Shepelev Posted April 15, 2013 · Report post Реестр черных сайтов не входил в поставленную задачу и реализуется заказчиком самостоятельно, через DNS фильтры. На данный момент его это устраивает. Если бы вопрос стоял как задача к проекту мы бы предложили решение на SCE либо на чем нибудь позабористее (благо возможности были) типа CheckPoint или Allot. Но все это вопрос всяких холиваров. По поводу вопроса до модернизации: на всей сети стоял Huawei 93 серии и NE40 серии. Приятного было мало особенно временно "подружить" вендоров оказалось не так то просто. Я думаю об этом еще будет рассказано ) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
depebo Posted April 15, 2013 · Report post А каким образом в этом проекте реализовывался сбор данных по трансляциям на NAT-ах? хорошо знаком с практикой силовиков запрашивать данные по доступу абонентов к каким-то ресурсам с определенных (транслированных) адресов в течение срока исковой давности, при этом порт на стороне провайдера они никогда не указывают - хранить приходится сессии Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted April 15, 2013 · Report post Приятного было мало особенно временно "подружить" вендоров оказалось не так то просто. Я думаю об этом еще будет рассказано ) Дружил 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. По другим протоколам никаких проблем не было Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Andrey Shepelev Posted April 16, 2013 · Report post А каким образом в этом проекте реализовывался сбор данных по трансляциям на NAT-ах? Все собирается с центрального x670 потому как весь трафик сети ходит через него, и проблем особенно нет в этом плане. Дружил S9300 и CX600(та же NE по сути) Да в принципе проблема именно в этом и возникала, потому как клиент в большом количестве использует данную технологию. В итоге пришлось в экстренном режиме переключать часть узлов на MX потому что несмотря на то что l2vpn работали, какие то сервисы таки работали с косяками. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sintech Posted April 16, 2013 · Report post Каким образом обеспечивается переключение трафика на резервный BRAS в случае отказа основного? Интересует как IPoE так и PPPoE тип доступа. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted April 16, 2013 · Report post Да в принципе проблема именно в этом и возникала, потому как клиент в большом количестве использует данную технологию. В итоге пришлось в экстренном режиме переключать часть узлов на MX потому что несмотря на то что l2vpn работали, какие то сервисы таки работали с косяками. Ага, потом оказывается, что "косяки" это ошибка конфигурации(ваша ошибка), а не потому что вендор XXX говно. "Приятного было мало" можно сказать про любого вендора, с котором мало опыта работы. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Andrey Shepelev Posted April 17, 2013 · Report post Каким образом обеспечивается переключение трафика на резервный BRAS в случае отказа основного? Интересует как IPoE так и PPPoE тип доступа. Все просто, в случае с PPPoE все абоненты тянутся туннелями до БРАС-ов, оба БРАСА отвечают на запросы PPPoE подключений, и абонент терминируется на том брасе который ответил первым, если один из БРАСов не отвечает то все соответственно терминируются на втором. Вопрос с IPoE с помощью функционала Server Group который поднимается на dhcp relay (mx80) который ракидывает клиентам по двум серверам, в случае недоступности одного из серверов все абоненты отправляются на второй. что "косяки" это ошибка конфигурации(ваша ошибка), Если бы если бы =) Настройки l2 туннеля не представляют из себя ничего замысловатого на обоих концах, что там Хуавей что там Jun. Туннели даже поднимаются но почему то все работает не гладко, хотя меняешь железку на какую нибудь другую копируешь настройки и все взлетает. Кросс-вендор имхо не всегда лучший выбор. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted April 17, 2013 · Report post Если бы если бы =) Настройки l2 туннеля не представляют из себя ничего замысловатого на обоих концах, что там Хуавей что там Jun. Туннели даже поднимаются но почему то все работает не гладко, хотя меняешь железку на какую нибудь другую копируешь настройки и все взлетает. Кросс-вендор имхо не всегда лучший выбор. Когда работаете с mpls псевдопроводами, то тут не только сигнализация важна, но и структура самого медиатрафика. Скорее всего, у вас с одной стороны был vlan tag в eth-заголовке в нагрузке, а с другой нет(или с одной стороны 2 тега, с другой один в нагрузку запихивалось). Такое бывает, да, и из конфигурации это не всегда очевидно. Просто так и напишите, "не хватило опыта скрестить вендора А с вендором Б", а не то, что "мало приятного" или чего-то ещё. Каким образом обеспечивается переключение трафика на резервный BRAS в случае отказа основного? Интересует как IPoE так и PPPoE тип доступа. Все просто, в случае с PPPoE все абоненты тянутся туннелями до БРАС-ов, оба БРАСА отвечают на запросы PPPoE подключений, и абонент терминируется на том брасе который ответил первым, если один из БРАСов не отвечает то все соответственно терминируются на втором. Вопрос с IPoE с помощью функционала Server Group который поднимается на dhcp relay (mx80) который ракидывает клиентам по двум серверам, в случае недоступности одного из серверов все абоненты отправляются на второй. Вас спросили о том как "обеспечивается переключение трафика", а вы про сигнальный трафик только написали. Проще говоря, требуется ли переподнятие сессии для хождения "полезного" трафика в случае выхода одного bras из строя? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Andrey Shepelev Posted April 18, 2013 · Report post Как прозвучал вопрос так и прозвучал ответ. Если бы вопрос был задан конкретно, так как сделали это Вы, то конечно же ответ прозвучал бы по другому. Да конечно вы правы абоненты не мигрируют с браса на брас в случае отказа одного из них. Согласен это не самая приятная ситуация, но другого выхода я не увидел. Поделитесь своими наработками в данной области буду благодарен. Все кто сидел на одном брасе будут просто переподключаться на другой брас. Т.е. абоненты конечно же пострадают, и им придется либо вручную либо по таймауту переключаться к сети. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
riddler63 Posted April 18, 2013 · Report post Если бы если бы =) Настройки l2 туннеля не представляют из себя ничего замысловатого на обоих концах, что там Хуавей что там Jun. Туннели даже поднимаются но почему то все работает не гладко, хотя меняешь железку на какую нибудь другую копируешь настройки и все взлетает. Кросс-вендор имхо не всегда лучший выбор. То есть вы свопнули сетку построенную чисто на Huawei на оборудование ТРЕХ вендоров, а потом в комментах заявляете что Кросс-вендор не лучший выбор? БРАВО! :) Уже лучше было тогда делать всё на Juniper, у них и BRAS есть и свичи и прочее. Да, присоединяюсь к вопросу: Какова схема резервирования BRAS в данном случае? Интересует поведение как абонентских сессий так и NAT сессий в случае выхода из строя на одном из BRAS: a) Интерфейса BRAS в сторону MAN сети. b) Линейной платы в сторону MAN сети. c) NAT платы d) Интерфейса в сторону Интернета Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ingress Posted April 18, 2013 · Report post Андрей, надеюсь ты понимаешь что это косоглазые вопросы ;) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted April 18, 2013 · Report post а конечно вы правы абоненты не мигрируют с браса на брас в случае отказа одного из них. Согласен это не самая приятная ситуация, но другого выхода я не увидел. Поделитесь своими наработками в данной области буду благодарен. поделюсь лишь очень занимательными ссылками 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) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tunny Posted April 19, 2013 · Report post НАТ на МХ нужен для обработки не ШПД абонентского трафика. В данном случае заказчик предполагает гонять через него LTE трафик в больших объемах. И чем LTE отличается от 'ШПД'? Имеется ввиду Интернет через LTE или какой-то другой сервис? видимо NAT без сабскрайберов имеется ввиду. плохо с ним у СЕ Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...