Технологии LRE и xDSL : Поддержка асимметричных цифровых абонентских линий (ADSL)

Базовая архитектура маршрутизованной мостовой инкапсуляции

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание

CPE

Введение

Данный документ описывает архитектуру сквозной Asymmetric Digital Subscriber Line (ADSL) , использующую возможность маршрутизованной мостовой инкапсуляции (RBE) для универсального концентратора доступа 6400 (UAC). RBE был разработан для устранения известных проблем с мостами (RFC1483), включая меры безопасности и широковещательные штормы. За исключением факта, что она работает исключительно через ATM, функция RBE функционирует идентично полу-мостовому соединению. Дополнительная масштабируемость, производительность и безопасность могут быть достигнуты благодаря использованию уникальных характеристик абонентов xDSL.

Предположение

Базовая архитектура разработана при помощи модели ADSL Forum Reference Architecture Model. Архитектура включает в себя различные службы поставщика доступа к сети (NAP) и различные сценарии переадресации трафика абонента поставщику услуг сети (NSP). В этой архитектуре RBE является принятым методом инкапсуляции, используемым Cisco 6400. Содержание этого документа основывается на существующих развертываниях, а также некоторых встроенных проверках, выполненных на архитектуре. Для расширенных характеристик и модификаций, обратитесь к Комментариям к выпуску для последнего выпуска Cisco программное обеспечение IOS�. В настоящее время RBE поддерживается на Cisco 6400, платформах Cisco 7200 и Cisco 7500. Этот документ ограничен обсуждениями Cisco 6400.

Технологическое Краткое описание

С точки зрения сети подключения ATM похожи на маршрутизируемое подключение. Трафик данных получен в виде пакетов RFC1483, но они являются кадрами RFC1483 Ethernet или IEEE 802.3. Вместо того, чтобы соединить Ethernet или кадр IEEE 802.3, как в случае обычного мостового соединения RFC1483, маршрутизатор направляет на заголовке Уровня 3. За исключением некоторых поверхностных проверок заголовок моста игнорируется. Это объяснено подробно в следующем разделе.

Эксплуатационное описание

/image/gif/paws/12917/routed_bridged_encap_1.gif

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

Для пакетов, исходящих из помещения заказчика, заголовок Ethernet пропускается и проверяется IP-адрес пункта назначения. Если IP-адрес назначения находится в кэше маршрутов, пакет быстро переключается на отправляющий интерфейс. Если IP-адрес назначения отсутствует в кэше маршрута, пакет становится в очередь для процессной коммутации. В режиме коммутации исходящий интерфейс, через который должен быть направлен пакет, можно найти в таблице маршрутизации. После определения исходящего интерфейса через него пересылается пакет. Это происходит без требования для группы моста или интерфейса BVI (Bridge Group Virtual Interface).

Для пакетов, предназначенных для абонентских оборудований, сперва рассматривают IP-адрес назначения пакета. Интерфейс назначения определен по таблице IP-маршрутизации. Затем, маршрутизатор проверяет таблицу протокола разрешения адресов (ARP), связанную с интерфейсом для MAC адреса назначения для расположения в разъеме Ethernet. Если ничего не найдено, маршрутизатор генерирует ARP-запрос об IP-адресе назначения. ARP-запрос перенаправляется только на интерфейс назначения. Это в отличие от мостового соединения, в котором запрос ARP передается всем интерфейсам в группе мостов.

Для сценария, использующего ненумерованные интерфейсы (где можно найти двух подписчиков в одной посети), маршрутизированный интерфейс моста использует прокси ARP. Например, 192.168.1.2 (хост A) хочет соединиться с 192.168.1.3 (хост B). Однако узел A и узел B находятся в одной подсети.

Узел A должен запомнить MAC адрес узла B, отправив ARP передачу узлу B. Когда маршрутизируемый интерфейс моста в устройстве агрегации получит это широковещание, это отошлет ответ прокси - протокола преобразования адресов с MAC-адресом 192.168.1.1, Хост A. Это возьмет тот MAC-адрес, разместит его в его Заголовок ethernet и передаст пакет. Когда маршрутизатор получает пакет, он сбрасывает коллектор и смотрит назначение IP-адреса, и затем направляет его на правильной интерфейс.

Преимущества RBE

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

  • Минимальная конфигурация для оборудования клиента.

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

  • Простой мигрировать от архитектур простого моста до RBE. Со стороны абонента не требуется никаких изменений.

  • Избегает Перехвата IP, и проблемы спуфинга ARP обратились в типичных архитектурах простого моста. Инкапсуляция RBE также предотвращает лавины широковещательных "пакетов" благодаря использованию соединений точка-точка. Безопасность является главным недостатком в архитектурах простого моста.

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

  • Поддерживает веб-выбор уровня 2 при использовании SSG.

Предложения по внедрению в эксплуатацию

Некоторые ключевые точки для рассмотрения прежде, чем внедрить эту архитектуру совпадают с упомянутый в газете Базовой архитектуры моста RFC1483.

RBE рекомендуется использовать в следующих случаях:

  • Сценарии аналогичны сценариям в существующих архитектурах мостовых подключений.

  • NAP стремится лишь минимально управлять CPEs. Понятие простого CPE требует минимальный или никакая конфигурация после того, как CPE будет развернут в местоположении абонента.

  • NAP не желает настраивать и обслуживать клиентов хоста, расположенных за CPE, соединенным мостом. Выполнение данных задач по установке и обслуживанию связано с повышением затрат на развертывание и обслуживание, включая затраты на обеспечение персонала справочной службы информацией о программном обеспечении и операционной системе клиента.

  • NAP хочет развернуть масштабируемую и защищенную сеть с мостовыми подключениями с помощью существующих CPE (который может только работать в режиме моста RFC1483), и хочет предложить возможности выбора служб поддержки.

Следующее обсуждение объясняет как адаптации архитектуры RBE и масштабы к другому бизнесу - моделям.

Архитектура сети

/image/gif/paws/12917/routed_bridged_encap_2.gif

Архитектура сети RBE подобна архитектуре с использованием мостов RFC1483. Как обозначено в этой архитектуре, агрегационное устройство может находиться в NAP, либо в NSP. Если используется архитектура сквозного постоянного виртуального канала (PVC), NSP отключает абонентов и настраивает RBE на устройстве агрегации. Если для NAP предпочтительнее обеспечение массового обслуживания и выбор услуг, связь с такими абонентами может быть прекращена, и будут получены IP-адреса с локального сервера DHCP. В случае крупномасштабных сервисов NAP может решить получить IP-адреса от NSP. Эти сценарии подробно описаны в разделе "IP-управление" данного документа.

Принципы проектирования архитектуры дистанционного пакетного ввода

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

В данном разделе объясняются некоторые ключевые моменты, которые нужно рассмотреть перед разработкой архитектуры RBE. С абонентской стороны принципы построения остаются теми же, что и в мостовой архитектуре RFC1483.

В RBE только один виртуальный канал выделяется для маршрута, наборов маршрутов или подсети CIDR. Таким образом надежная среда уменьшена до только одиночного абонентского оборудования, представленного или IP-адресами в наборе маршрутов или блоком CIDR. Поставщик услуг Интернет (ISP) также осуществляет назначение адресов пользователям. Это сделано конфигурированием подсети подинтерфейса этого пользователя. Поэтому, если пользователь неправильно конфигурирует оборудование с IP address outside выделенный диапазон адресов (возможно заставляющий пакеты ARP течь до маршрутизатора), маршрутизатор генерирует ошибку "неправильного кабеля" и отказывается вводить ошибочного IP в сопоставление MAC-адреса в его таблицу ARP.

RBE можно развернуть, используя только субинтерфейсы ATM "точка-точка". Это не может быть развернуто на многоточечных подчиненных интерфейс. Даже если на стороне подписчика есть мост, нет необходимости в определении групп моста или BVI интерфейсов, так как подинтерфейсы рассматриваются как протрассированные.

Подчиненные интерфейс типа точка-точка ATM могут быть нумерованными интерфейсами или ненумерованный к некоторым другим интерфейсам.

По определению, числовой интерфейс — это интерфейс, который имеет специфический IP-адрес с фиксированной маской подсети. Например: :

Interface atm0/0/0.132 point-to-point
ip address 192.168.1.1 255.255.255.252

Как показано в этом примере, при развертывании RBE с нумерованным интерфейсом должна быть отдельная подсеть для каждого абонента. Хост в сетевом окончании со стороны абонента должен быть настроен для 192.168.1.2. На стороне абонента есть только один узел. Если требуется поддержка нескольких узлов, выбранная маска подсети должна разместить больше узлов.

Нумерованные интерфейсы предоставляют поставщику услуг сетевого доступа контроль над хостами, с которыми абонент установил соединение за CPE. Как было показано выше, недостаточный контроль был главной проблемой в архитектуре с использованием мостов RFC1483.

Однако в этой методологии требуется слишком много IP-адресов. Потребуется выделить по одной подсети на абонента, используйте один IP-адрес для субинтерфейса ATM и оставьте неиспользованными широковещательный адрес и все нулевые адреса. Поэтому для того, чтобы установить один главный узел за CPE, необходимо, как минимум, задать маску подсети 255.255.255.252. Рассматривая дефицит IP-адресов, это может не быть подходящим параметром, пока NAP/NSP не использует частное пространство адресов и выполняет Технологию NAT для достижения внешнего мира.

Сохранить IP-адреса, алтернатива была бы использовать ненумерованные интерфейсы. По определению, ненумерованный интерфейс - это интерфейс, который использует IP-адрес другого интерфейса путем использование команды ip unnumbered. Например: :

!
interface loopback 0
ip address 192.168.1.1 255.255.255.0
!
interface atm0/0/0.132 point-to-point
ip unnumbered loopback 0
!
interface atm0/0/0.133 point-to-point
ip unnumbered loopback 0

Как показано в примере выше, IP-адрес и подсеть применяются только к интерфейсу обратной связи. Все подчиненные интерфейсы АТМ должны быть ненумерованными для данного интерфейса обратной связи. В этом сценарии все абоненты, завершаемые на подчиненных интерфейс ATM (ненумерованный к loopback 0), были бы в той же подсети как тот из loopback 0. Это подразумевает, что абоненты были бы в той же подсети, но будут входить через другие маршрутизируемые интерфейсы. В этой ситуации это становится проблемой для маршрутизатора для определения, какой абонент находится позади который подчиненный интерфейс ATM. Для Cisco IOS, 192.168.1.0 (в схеме IP - управления) напрямую подключается через обратную связь интерфейса 0, и это никогда не переходит, передают трафик, предназначенный к любому из адресов узла на той подсети через любой другой интерфейс. Для решения этого вопроса необходимо явно настроить статические маршруты хоста. Например: :

ip route 192.168.1.2 255.255.255.255 atm0/0/0.132
ip route 192.168.1.3 255.255.255.255 atm0/0/0.133

Как задано в данном примере, когда маршрутизатор должен будет сделать решение о маршрутизации и должен будет передать трафик, предназначенный для 192.168.1.2, это выберет ATM 0/0/0.132 в качестве исходящего интерфейса и т.д. Не задавая те статические маршруты хоста, маршрутизатор выбрал бы исходящий интерфейс в качестве loopback 0 и отбросил бы пакет.

Хотя ненумерованные интерфейсы сохранят IP-адреса, это потребует решения дополнительных задач по настройке статических маршрутов хоста в NRP для каждого абонента. Заметьте, что если подписчик содержит, например, 14 узлов в CPE, то ему не потребуются статические маршруты для каждого узла. Итоговый маршрут может быть задан для подчиненного интерфейса ATM.

До настоящего момента в нашем объяснении предполагалось, что хосты, находящиеся за CPE, будут сконфигурированы с учетом статических IP-адресов. Это допущение при проектировании в реальных условиях ложно. На практике NAP требует выполнить минимальную настройку и отладку для CPE и хостов, подключенных к нему. Для достижения этого хосты должны получить свои адреса динамично с помощью DHCP server.

Для получения их IP-адресов динамично, хосты должны быть настроены для получения IP-адресов от DHCP server. Когда хост загружается, он отсылает запросы DHCP. Данные запросы отправляются на соответствующий сервер DHCP, который присваивает хосту IP-адрес, начиная с единицы, в заранее определенном диапазоне.

Для передачи начальных запросов DHCP от хоста до соответствующего DHCP server необходимо применить команду ip helper-address к интерфейсу, который получает широковещательные сообщения. После того, как широковещательные сообщения получены, Cisco IOS посмотрела на конфигурацию ip helper-address для того интерфейса и передает те запросы в одноадресном пакете к соответствующему DHCP server, IP-адрес которого задан в ip helper-address. После того, как сервер DHCP отправит ответ с IP-адресом, он посылает ответ интерфейсу на том маршрутизаторе, который изначально перенаправил запрос. Он используется в качестве исходящего интерфейса для отправки ответа DHCP-сервера хосту, который первоначально запросил службу. Маршрутизатор также автоматически устанавливает маршрут хоста для данного адреса.

Если RBE включен на подинтерфейсе и является Bridged Protocol Data Unit (PDU) IEEE 802.3, Инкапсуляция Ethernet исследована после инкапсуляции моста ATM. Если это пакет IP/ARP, он обрабатывается как и любой другой пакет IP/ARP. Выполняется быстрая коммутация данного IP-пакета. Если произойдет сбой, он будет поставлен в очередь на коммутацию процессов.

Производительность для RBE является большой победой. Современный стандартный код моста отличается тем, что для принятия решения о переадресации ему необходимо предоставить две отдельные классификации для каждого пакета. Классификация представляет собой процесс изучения (для восходящих соединений) и изменения (для нисходящих соединений) информации пересылки в заголовках пакетов, что занимает достаточно много времени. Для того, чтобы определить, как поступить с пакетом – маршрутизовать или отправить по мостовому соединению – требуется провести просмотр на 2 уровне. Затем на 3 уровне нужно выполнить просмотр адресов и определить направление маршрутизации пакета. Эта классификация сделана в восходящем, а также нижележащих направлениях, который оказывает влияние на производительность.

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

Ключевые пункты RBE

CPE

Конфигурация CPE остается такой же, как и при стандартном мостовом соединении. Для развертывания RBE не требуется вносить никакие изменения в RBE.

Управление системами IP

routed_bridged_encap_3.gif

При развертывании нумерованных интерфейсов для RBE IP - адрес размещения к хосту позади абонентского оборудования CPE с мостовым подключением обычно обрабатывается через DHCP server. Как упоминалось ранее, сервер DHCP может находиться в NAP или NSP. Для любого случая пронумерованный подчиненный интерфейс ATM должен быть настроен с командой ip helper-address. Если сервер DHCP будет размещаться в NSP, для устройства агрегации NAP должен быть установлен маршрут для доступа к серверу. NAP использует свой собственный DHCP-сервер и диапазон IP-адресов, только если следует обеспечить возможность выбора служб абонентами, которые являются LAN, подключенные к NAP.

Если NAP намерен использовать IP-адрес NSP, один из IP-адресов для каждой подсети должен быть выделен подчиненному интерфейсу ATM. Кроме этого, NAP и NSP должны быть согласованны, тогда NAP настроит правильный адрес. Когда DHCP-сервер NSP назначает IP-адреса, это соглашение должно быть использовано, чтобы сервер передавал хосту сведения о правильном шлюзе по умолчанию. NAP может тогда или суммировать статический маршрут для всех тех адресов, назначенных на абонентов, или он может принять решение выполнить протокол маршрутизации с NSP для объявления тех маршрутов. В большинстве сценариев NAP и NSP настроены на приоритетное неиспользование протокола маршрутизации. Обеспечение статического маршрута является хорошей опцией.

Это - базовая конфигурация, требуемая на nrp для развертывания RBE с нумерованными интерфейсами:

!
interface ATM0/0/0.132 point-to-point
ip address 192.168.1.1 255.255.255.0
ip helper-address 192.168.3.1
no ip directed-broadcast
atm route-bridged ip
pvc 1/32
encapsulation aal5snap
!
interface ATM0/0/0.133 point-to-point
ip address 192.168.2.1 255.255.255.0
ip helper-address 192.168.3.1
no ip directed-broadcast
atm route-bridged ip
pvc 1/33
encapsulation aal5snap

Использование ненумерованных интерфейсов является лучшим способом сохранить IP-адреса. Как объяснено ранее, когда ненумерованные интерфейсы используются с DHCP, маршруты хоста динамично установлены. Возможно, это наилучший подход к развертыванию RBE. DHCP server может тогда быть расположен или в NAP или в NSP, что касается нумерованных интерфейсов.

Это - базовая конфигурация, требуемая на nrp для развертывания RBE с ненумерованными интерфейсами:

interface Loopback0
ip address 192.168.1.1 255.255.255.0
no ip directed-broadcast
!
interface ATM0/0/0.132 point-to-point
ip unnumbered Loopback0
no ip directed-broadcast
ATM route-bridged ip
pvc 1/32
encapsulation aal5snap
!
interface ATM0/0/0.133 point-to-point
ip unnumbered Loopback0
no ip directed-broadcast
ATM route-bridged ip
pvc 1/33
encapsulation aal5snap

Основные сведения о том, как достигается пункт назначения для предоставления обслуживания

До сих пор этот документ обсудил основную технологию доступа с помощью RBE в качестве метода инкапсуляции. Однако с помощью этой архитектуры, NAP/NSP может также предложить различные услуги и различные варианты для того, где NAP может передать трафик абонента NSP. Эти понятия объяснены в следующих разделах.

Обеспечение доступа в Internet

В данном сценарии основной функцией NSP является обеспечение высокоскоростного доступа в Интернет для оконечных абонентов. Поскольку NSP переходит, предоставляют заключительный сервис, управление IP-адресами становится ответственностью NSP. Он может назначить общедоступные IP-адреса своим абонентам с помощью сервера DHCP либо предоставить абонентам частные IP-адреса и затем выполнить преобразование NAT для получения доступа к внешней среде.

Услуги для оптовых клиентов

Если NAP желает предоставить ISP услуги оптовой продажи, он может это сделать. В этом сценарии NAP обычно не предпочитает обрабатывать IP-адреса для всех абонентов для других NSP. NAP назначает некоторую встречу с интернет-провайдером для обеспечения IP-адресов тем абонентам. Это может быть достигнуто NAP, передавая запросы DHCP, прибывающие от абонентов к Dhcp server в NSP. NAP должен настроить своих подчиненных интерфейс ATM с одним из IP-адресов из того диапазона, и это должно объявить те маршруты к NSP. Объявление маршрутов может быть в форме либо статического маршрута, либо в форме какого-либо протокола маршрутизации между NAP и NSP. Статический маршрут является предпочтительным способом для NAP, а также для NSP.

Корпоративный доступ

Корпоративный доступ часто требует наличия служб виртуальной частной сети (VPN). Это означает, что корпорация не будет предоставлять IP-адреса для NAP и не позволит NAP объявлять пространство корпоративных IP-адресов в IP-ядре NAP, поскольку это может привести к нарушению безопасности. Корпорации обычно применяют собственные IP-адреса для своих клиентов, или же позволяют получить доступ безопасным способом, например с помощью сетей MPLS/VPN или протокола L2TP.

Другой подход к обеспечению безопасного корпоративного доступа состоит в том, где NAP предоставляет исходные IP - адреса тем абонентам. Поэтому абоненты становятся подключенными к LAN к NAP. После назначения абонентам исходных IP-адресов, они могут установить туннельное соединение с организацией с помощью клиентского программного обеспечения L2TP, запущенного на хосте. В свою очередь, организация аутентифицирует абонента и предоставляет IP-адрес из собственного пространства IP-адресов. Этот IP-адрес используется адаптером VPN L2TP. Таким образом, у абонентов есть опция, чтобы или соединиться с их интернет-провайдером для Интернет-соединения или получить доступ к их корпорации через защищенный туннельный доступ L2TP. Однако, при этом необходимо что бы корпорация предоставила конечный IP-адрес туннеля абоненту, который должен быть маршрутизируем через NAP IP-ядро.

Возможности выбора служб поддержки

Применение точки доступа к сети (NAP) обеспечивает широкие возможности по выбору служб с помощью функциональных возможностей Cisco SSG. SSG предлагает два метода выбора служб: через Уровень 2 (который известен как PTA-MD), и Веб - выбор Уровня 3. Для RBE можно использовать только метод веб-выбора уровня 3. Это требует, чтобы абоненты были подключены к LAN к NAP; т.е. NAP предоставляет исходный IP - адрес абоненту и предоставляет доступ к Выбранной инструментальной панели сервиса Cisco (SSD).

В случае архитектуры RBE Метод веб - выбор Cisco SSG является хорошим способом составлять трафик абонента.

Заключение

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

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 12917