Современная Triple-Play сеть

[Robot_NagNews]

Материал:

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

 

Полный текст

[flamaster]

ничего не рассказано в плане IPv6. интересно узнать масштабируемость выбранной топологий в случий IPv6.

[ivb1232]

Вопрос мультикаста скупо освещен, P2MP MPVN ?

Телефония, понимаю, L3VPN обычная.

[dmvy]

Зачем на Juniper MX делать NAT при наличии SE600? PE для больших клиентов (>1Гбит) я могу понять, но NAT совсем лишнее (Отдельную плату для этого нужно ведь). Поправьте картинку...

[ivb1232]

BRAS/NAT SE600 на картинке есть.

[Andrey Shepelev]

НАТ на МХ нужен для обработки не ШПД абонентского трафика. В данном случае заказчик предполагает гонять через него LTE трафик в больших объемах.

[s.lobanov]

НАТ на МХ нужен для обработки не ШПД абонентского трафика. В данном случае заказчик предполагает гонять через него LTE трафик в больших объемах.

 

И чем LTE отличается от 'ШПД'? Имеется ввиду Интернет через LTE или какой-то другой сервис?

[Andrey Shepelev]

Да конечно. некорректно выразился. Имелось ввиду что услуги LTE построены на базе отдельной сети, которая стыкуется с ядром и весь трафик натится именно на МХ в ядре. Это было пожелание заказчика которое мы реализовали установив специальный модуль MS-DPC. Имеется ввиду именно интернет для устройств с поддержкой LTE.

 

Вопрос мультикаста возможно будет рассмотрен в других статьях )))

[max1976]

При получении dhcp запроса, на оборудовании центрального узла автоматически создается l3 интерфейс с номером Vlan соответствующим Vlan приходящего пакета, и адресом, выбранным согласно технологии ip unnumbered. Осуществляется преобразование broadcast dhcp запроса в unicast dhcp запрос, и передача его на третьем уровне модели OSI до оборудования BRAS. На оборудовании BRAS осуществляется авторизация абонентов в системе биллинга по технологии CLIPS, и выдачи ему адреса и соответствующих атрибутов.

Это каким образом? На один dhcp запрос будет выдано 2 адреса (один там где ip unnumbered, а другой на BRASe) ?

[Andrey Shepelev]

почему же два? если внимательно прочитать текст то можно понять что на оборудовании узла создается влан и интерфейс, никакой выдачи адреса там нет как и каких то dhcp серверов.

Вся авторизация через БРАС, с привязкой к оборудованию центрального узла через опцию шлюза по умолчанию.

[artmc]

А какое оборудование было у оператора до модернизации? И схема то же интересна :)

[zoro]

А на чем организованна борьба с трафиком с черной кармой? (реестр запрещенных сайтов)

[Andrey Shepelev]

Реестр черных сайтов не входил в поставленную задачу и реализуется заказчиком самостоятельно, через DNS фильтры. На данный момент его это устраивает. Если бы вопрос стоял как задача к проекту мы бы предложили решение на SCE либо на чем нибудь позабористее (благо возможности были) типа CheckPoint или Allot.

Но все это вопрос всяких холиваров.

 

По поводу вопроса до модернизации: на всей сети стоял Huawei 93 серии и NE40 серии. Приятного было мало особенно временно "подружить" вендоров оказалось не так то просто. Я думаю об этом еще будет рассказано )

[depebo]

А каким образом в этом проекте реализовывался сбор данных по трансляциям на NAT-ах?

хорошо знаком с практикой силовиков запрашивать данные по доступу абонентов к каким-то ресурсам с определенных (транслированных) адресов в течение срока исковой давности, при этом порт на стороне провайдера они никогда не указывают - хранить приходится сессии

[s.lobanov]

Приятного было мало особенно временно "подружить" вендоров оказалось не так то просто. Я думаю об этом еще будет рассказано )

 

Дружил 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.

 

По другим протоколам никаких проблем не было

[Andrey Shepelev]

А каким образом в этом проекте реализовывался сбор данных по трансляциям на NAT-ах?

 

Все собирается с центрального x670 потому как весь трафик сети ходит через него, и проблем особенно нет в этом плане.

 

Дружил S9300 и CX600(та же NE по сути)

 

Да в принципе проблема именно в этом и возникала, потому как клиент в большом количестве использует данную технологию. В итоге пришлось в экстренном режиме переключать часть узлов на MX потому что несмотря на то что l2vpn работали, какие то сервисы таки работали с косяками.

[sintech]

Каким образом обеспечивается переключение трафика на резервный BRAS в случае отказа основного?

Интересует как IPoE так и PPPoE тип доступа.

[s.lobanov]

Да в принципе проблема именно в этом и возникала, потому как клиент в большом количестве использует данную технологию. В итоге пришлось в экстренном режиме переключать часть узлов на MX потому что несмотря на то что l2vpn работали, какие то сервисы таки работали с косяками.

 

Ага, потом оказывается, что "косяки" это ошибка конфигурации(ваша ошибка), а не потому что вендор XXX говно. "Приятного было мало" можно сказать про любого вендора, с котором мало опыта работы.

[Andrey Shepelev]

Каким образом обеспечивается переключение трафика на резервный BRAS в случае отказа основного?

Интересует как IPoE так и PPPoE тип доступа.

 

Все просто, в случае с PPPoE все абоненты тянутся туннелями до БРАС-ов, оба БРАСА отвечают на запросы PPPoE подключений, и абонент терминируется на том брасе который ответил первым, если один из БРАСов не отвечает то все соответственно терминируются на втором.

 

Вопрос с IPoE с помощью функционала Server Group который поднимается на dhcp relay (mx80) который ракидывает клиентам по двум серверам, в случае недоступности одного из серверов все абоненты отправляются на второй.

 

 

что "косяки" это ошибка конфигурации(ваша ошибка),

 

Если бы если бы =) Настройки l2 туннеля не представляют из себя ничего замысловатого на обоих концах, что там Хуавей что там Jun. Туннели даже поднимаются но почему то все работает не гладко, хотя меняешь железку на какую нибудь другую копируешь настройки и все взлетает. Кросс-вендор имхо не всегда лучший выбор.

[s.lobanov]

Если бы если бы =) Настройки l2 туннеля не представляют из себя ничего замысловатого на обоих концах, что там Хуавей что там Jun. Туннели даже поднимаются но почему то все работает не гладко, хотя меняешь железку на какую нибудь другую копируешь настройки и все взлетает. Кросс-вендор имхо не всегда лучший выбор.

 

Когда работаете с mpls псевдопроводами, то тут не только сигнализация важна, но и структура самого медиатрафика. Скорее всего, у вас с одной стороны был vlan tag в eth-заголовке в нагрузке, а с другой нет(или с одной стороны 2 тега, с другой один в нагрузку запихивалось). Такое бывает, да, и из конфигурации это не всегда очевидно.

 

Просто так и напишите, "не хватило опыта скрестить вендора А с вендором Б", а не то, что "мало приятного" или чего-то ещё.

 

Каким образом обеспечивается переключение трафика на резервный BRAS в случае отказа основного?

Интересует как IPoE так и PPPoE тип доступа.

 

Все просто, в случае с PPPoE все абоненты тянутся туннелями до БРАС-ов, оба БРАСА отвечают на запросы PPPoE подключений, и абонент терминируется на том брасе который ответил первым, если один из БРАСов не отвечает то все соответственно терминируются на втором.

 

Вопрос с IPoE с помощью функционала Server Group который поднимается на dhcp relay (mx80) который ракидывает клиентам по двум серверам, в случае недоступности одного из серверов все абоненты отправляются на второй.

 

 

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

[Andrey Shepelev]

Как прозвучал вопрос так и прозвучал ответ. Если бы вопрос был задан конкретно, так как сделали это Вы, то конечно же ответ прозвучал бы по другому.

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

[riddler63]

Если бы если бы =) Настройки l2 туннеля не представляют из себя ничего замысловатого на обоих концах, что там Хуавей что там Jun. Туннели даже поднимаются но почему то все работает не гладко, хотя меняешь железку на какую нибудь другую копируешь настройки и все взлетает. Кросс-вендор имхо не всегда лучший выбор.

То есть вы свопнули сетку построенную чисто на Huawei на оборудование ТРЕХ вендоров, а потом в комментах заявляете что Кросс-вендор не лучший выбор? БРАВО! :)

 

Уже лучше было тогда делать всё на Juniper, у них и BRAS есть и свичи и прочее.

 

Да, присоединяюсь к вопросу:

 

Какова схема резервирования BRAS в данном случае?

Интересует поведение как абонентских сессий так и NAT сессий в случае выхода из строя на одном из BRAS:

a) Интерфейса BRAS в сторону MAN сети.

b) Линейной платы в сторону MAN сети.

c) NAT платы

d) Интерфейса в сторону Интернета

[ingress]

Андрей, надеюсь ты понимаешь что это косоглазые вопросы ;)

[s.lobanov]

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

 

поделюсь лишь очень занимательными ссылками

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)

[tunny]

НАТ на МХ нужен для обработки не ШПД абонентского трафика. В данном случае заказчик предполагает гонять через него LTE трафик в больших объемах.

 

И чем LTE отличается от 'ШПД'? Имеется ввиду Интернет через LTE или какой-то другой сервис?

видимо NAT без сабскрайберов имеется ввиду. плохо с ним у СЕ