Глобальная сеть (WAN) : Протокол PPP

Multichassis Multilink PPP (MMP) (часть 2)

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


Содержание


Введение

Этот документ продолжает описывать поддержку Многоканального подключения PPP (MP) в "стеке" или многокорпусной среде (иногда называемый MMP, для PPP Многоблочного мультиканального протокола), на платформах сервера доступа Cisco Systems.

Этот документ является Частью Два из документа с двумя частями. Отнеситесь для Разделения Одного из этого документа для получения дополнительной информации.

Предварительные условия

Предварительные условия для этого документа даны в части Один из этого документа.

Примеры

AS5200 в стеке (с номеронабирателями)

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

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

systema#config
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3

  username stackq password therock

  int dialer 1
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  ppp multilink

  controller T1 0
  framing esf                    
  linecode b8zs                  
  pri-group timeslots 1-24

  interface Serial0:23
  no ip address
  encapsulation ppp
  dialer in-band
  dialer rotary 1
  dialer-group 1

Следующий пример от Контроллера e1:

controller E1 0
  framing crc4  
  linecode  hdb3
  pri-group timeslots 1-31
  interface Serial0:15
  no ip address
  encapsulation ppp
  no ip route-cache
  ppp authentication chap
  ppp multilink

После того, как групповой интерфейс создан, он клонирован с только командами PPP от интерфейса номеронабирателя. Последующие спроектированные PPP - связи также клонированы с командами PPP от интерфейса номеронабирателя. Рисунок 3 показывает, как интерфейс номеронабирателя находится поверх группового интерфейса. Сравните его с рисунком 2, на котором нет никакого интерфейса номеронабирателя.

PRI и BRIs по умолчанию являются интерфейсами номеронабирателя; PRI, настроенный без прямого номеронабирателя (посредством команды dialer rotary), является все еще интерфейсом номеронабирателя на Serial0:23, как показано следующим примером:

interface Serial0:23
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  dialer rot 1
  ppp multilink
Рис. 3: Stack Group–stackq–consisting системы, systemb и systemc. ссылка системы настроена на интерфейсе номеронабирателя.

/image/gif/paws/14945/figure3-mmp.gif

Использование сервера разгрузки

systema определяется разгрузочный сервер (использующий команду sgbp seed-bid). Все другие члены группы стека должны быть определены с командой sgbp seed-bid default (или, если вы не определяете thesgbp предложенная прототипом команда, это не выполняет своих обязательств к этому).

systema#config
  multilink virtual-template 1
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3
  sgbp seed-bid offload
  username stackq password therock

  interface virtual-template 1
  ip unnumbered e0
  :

  ppp authen chap
  ppp multilink
Рис. 4: система как разгрузочный сервер.

/image/gif/paws/14945/figure4-mmp.gif

Сервер разгрузки с физическими интерфейсами

Если определяемый разгрузочный сервер также имеет физические интерфейсы (например, PRI) желание служить той же группе последовательного поиска telco (телефонная компания) в качестве других элементов стека, можно настроить его для этого путем объединения конфигураций, показанных в разделах названного AS5200 этого документа в Стеке (С Номеронабирателями) и Использование Разгрузочного сервера.

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

Эта конфигурация не рекомендуется из-за сложности конфигураций, требуемой на номеронабирателе и интерфейсах виртуального шаблона.

Асинхронные, последовательные и другие интерфейсы без номеронабирателя

В то время как можно настроить асинхронный и последовательные устройства как интерфейсы номеронабирателя (когда это возвращается к AS5200 в Стеке (С Номеронабирателями), как показано в том разделе этого документа), можно принять решение поддержать многокорпусный MP без любой конфигурации программы набора номера для асинхронных, последовательных, и других интерфейсов без набора номера. Источник всей конфигурации тогда определен в интерфейсе виртуального шаблона, как показано ниже.

#config
  multilink virtual-template 1
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3
  username stackq password therock
  interface virtual-template 1
  ip unnumbered e0
  :
  ppp authen chap
  ppp multilink

  int async 1
  encap ppp 
  ppp multilink 
  ppp authen chap
  :

  line 1
  login 
  autoselect ppp 
  autoselect during-login
  speed 38400
  flow hardware

Внешние телефонные соединения в многоблочной конфигурации

В настоящее время многоблочная конфигурация не поддерживает подключение к внешней службе, потому что протокол переадресации уровня 2 (L2F) не поддерживает подключение к внешней службе.

Следовательно, нет никакого пути к разгрузочному серверу (где маршрут имитируется, на профиле DDR, и т.д.) инициировать набор на члене стека внешнего интерфейса в том же стеке групп. Любые поддельные маршруты должны быть установлены на члены стека внешнего интерфейса, потому что они - те с физическими набираемыми соединениями (такими как PRI).

Некоторые обходные пути следующие:

  • Когда команда sgbp ppp-forward выполнена на члене стека внешнего интерфейса, это означает, что весь PPP и вызовы PPP multilink автоматически переданы победителю предложения Протокола приглашения стека групп (SGBP), такому как разгрузочный сервер.

    Необходимо положиться на Сервер доступа к сети (NAS) наборка номера и позволить конвергенции IP routing (только для IP), берут его курс. Например, для вызова номера 1.1.1.1 поместите этот адрес в инструкцию схемы набора номеров на NAS и поместите статический маршрут на NAS, следующим образом:

      ip route 1.1.1.1 255.255.255.255 serial0:23
      int serial0:23
      ip address 3.3.3.3 255.0.0.0
      dialer map ip 1.1.1.1 howard 7771234
    

    Когда набираемые подключения к удаленному узлу, PPP - подключение сформирован между удаленным узлом и разгрузочным сервером. Член стека внешнего интерфейса полностью обходится. PPP на разгрузочном сервере тогда устанавливает маршрут хоста к узлу — 1.1.1.1. На этом этапе протокол IP-маршрутизации сходится от к маршруту хоста в разгрузочном сервере, потому что метрика маршрутизации гравитирует маршрут там.

    Примечание: Маршрутизация конвергенции приводит к задержке.

  • Когда команда sgbp ppp-forward не определена на члене стека внешнего интерфейса, это означает, что только вызовы PPP multilink автоматически переведены выбранному SGBP устройство, такому как разгрузочный сервер. Таким образом номеронабиратель от члена стека внешнего интерфейса к удаленному узлу охватывает PPP - подключение между фронтэндом и удаленным узлом — то же поведение, как будто NAS не был частью стека групп.

    Примечание: Это происходит, пока соединение является прямым PPP (и не PPP multilink).

Телефонные соединения с многоблочной конфигурацией

Если у вас есть IP routing (такой как Протокол EIGRP и Протокол OSPF) текущий между клиентом и элементом стека, который в конечном счете выигрывает предложение (такое как разгрузочный сервер), вот несколько советов для придержаний:

Предотвратите установку связанного маршрута на клиентской стороне

Настройте клиент 1.1.1.2, где 1.1.1.2 адрес NAS (прозрачное средство передачи кадра), как показано ниже.

  int bri0

  dialer map 1.1.1.2 ....

Если у вас есть EIGRP, например, работающий между клиентом и разгрузочным сервером, таблица маршрутизации на разгрузочном сервере указывает, что для получения до 1.1.1.2 маршрут должен пройти через интерфейс виртуального доступа. Это вызвано тем, что IP Control Protocol PPP (IPCP) на клиентской стороне устанавливает связанный маршрут 1.1.1.2 к интерфейсу BRI. EIGRP тогда объявляет этот маршрут к разгрузочному серверу по сеансу PPP (по L2F). EIGRP на разгрузочном сервере таким образом указывает, что для получения до 1.1.1.2 это должно направить клиенту — маршрут 1.1.1.1 клиента к интерфейсу виртуального доступа.

Теперь, вам предназначили пакет для клиента 1.1.1.1. IP routing передает пакет к интерфейсу виртуального доступа. Интерфейс виртуального доступа инкапсулирует IP/Протокол данных пользователя (UDP) инкапсуляция/L2F/PPP и передает пакет к NAS L2F — 1.1.1.2. Все обычно на этом этапе. Затем вместо того, чтобы передать пакет через (например), Интерфейс Ethernet, IP routing передает его через интерфейс виртуального доступа снова. Это вызвано тем, что таблица маршрутизации указывает, что для получения до NAS она должна пройти через клиент. Это создает цикл маршрутизации и эффективно отключает ввод/вывод по туннелю L2F.

Для предотвращения этого не позволяйте IPCP устанавливать связанный маршрут на клиентской стороне.

Примечание: Это принадлежит только, когда у вас есть некоторый протокол IP-маршрутизации, работающий между Домашним шлюзом Cisco и клиентом.

Конфигурация клиента следующие:

  int bri0

  no peer neighbor-route

Cхемы набора номеров у клиента

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

Например: :

  client 1.1.1.1

  int bri0

  dialer map 1.1.1.3 ...

В данном примере, 1.1.1.3 всего один разгрузочный сервер.

Пакет, предназначенный для 1.1.1.2 маршрутов к BRI и номеронабирателя, набирает назначение, потому что существует соответствие cхемы набора номеров. Разгрузочный сервер 1.1.1.4 фактически wins предложение и сеанс PPP спроектирован там. EIGRP обмениваются между клиентом и разгрузочным сервером. Таблица IP-маршрутизации у клиента заполнена маршрутом 1.1.1.4 (разгрузочный сервер) к BRI0. Теперь, у клиента, пакет, предназначенный для 1.1.1.4, маршрутизируется к BRI0. Номеронабиратель, однако, не может набрать, поскольку нет никакого соответствия номеронабирателя.

Примечание: Всегда определяйте cхемы набора номеров для всех потенциальных получателей положительного ответа на запрос SGBP у клиентов каждый раз, когда доступ к разгрузочным серверам является требованием клиентов.

Конфигурация и ограничения

  • J-образ предприятия требуется для многокорпусного MP.

  • Только один стек групп может быть определен для каждого сервера доступа.

  • С большой задержкой каналы WAN между элементами стека, вызывая задержки повторной сборки MP, могут заставить многокорпусный MP быть неэффективным.

  • Интерфейсы поддерживаются для PRI, [M] BRI, последовательные, и асинхронные устройства.

  • Подключение к внешней службе не поддерживается.

Настройка попротокольных конфигураций интерфейсов

Для всех практических целей не настраивайте определенный адрес на виртуальном шаблоне.

  interface virtual-template 1

  ip address 1.1.1.2 255.0.0.0

  :

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

  interface virtual-template 1

  ip unnum e0

  :

Конфигурация глобальных настроек протокола

Клиент, который набирает в маршрутизатор одиночного обращения и ожидает, что сервер доступа будет иметь уникальный глобальный адрес (такой как DECnet) теперь фактически, набирает к стеку групп многоблочного мультиканального протокола, состоящему из нескольких серверов доступа. В этом типе ситуации завершите стек групп детерминировано в сервере одиночного доступа. Чтобы сделать это, выполните команду sgbp seed-bid offload на определяемом сервере доступа (или задайте самое высокое предложение).

Устранение неисправностей

Первое, что нужно сделать, если у вас есть проблемы, состоит в том, чтобы вернуться к одиночному элементу стека, отключая все другие элементы стека. Затем протестируйте многоканальные соединения PPP и пройдите через обычную аутентификацию Протокола аутентификации по квитированию вызова (CHAP) и конфигурацию интерфейса для ошибок в конфигурации и т.д. Когда вы удовлетворены, что это работает, включите другим элементам стека, затем продолжитесь следующим образом:

  1. Удостоверьтесь, что SGBP в порядке.

  2. Многоканальный Debug PPP.

  3. VPN отладки и L2F.

Проверка функционирования SGBP

Выполните команду show sgbp, чтобы удостовериться, что все состояния члена АКТИВНЫ. В противном случае высматривайте ПРОСТАИВАЮЩИЙ, AUTHOK или Активные состояния. Как упомянуто ранее, ПРОСТАИВАЮЩИЙ допустимое состояние для всех удаленных элементов стека, которые преднамеренно неактивны.

Если вы находите проблему, как описано выше, включаете debug sgbp hellos и команду debug sgbp error. Аутентификация между двумя элементами стека, например между systema и systemb, должна быть следующим образом (на systema):

  systema# debug sgdp hellos

  %SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stackq
  %SGBP-7-CHALLENGED: Hello Challenge message from member systemb (1.1.1.2)
  %SGBP-7-RESPONSE: Send Hello Response to systemb group stackq
  %SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stackq
  %SGBP-7-RESPONDED: Hello Response message from member systemb (1.1.1.2)
  %SGBP-7-AUTHOK: Send Hello Authentication OK to member systemb (1.1.1.2)
  %SGBP-7-INFO: Addr = 1.1.1.2 Reference = 0xC347DF7
  %SGBP-5-ARRIVING: New peer event for member systemb

systema передает проблему стиля CHAP и получает ответ от systemb. Точно так же systemb отсылает проблему и получает ответ от systema.

Если аутентификация отказывает, вы видите:

  %SGBP-7-AUTHFAILED - Member systemb failed authentication

Это означает, что удаленный пароль systemb для stackq не совпадает с паролем, определенным на systema.

  %SGBP-7-NORESP -Fail to respond to systemb group stackq, may not have password

Это означает, что systema не определяли имя пользователя или пароль локально или через TACACS +.

В целом определите общий пароль по всем элементам стека для стека групп stackq. Можно определить их локально или через TACACS +.

Локальное имя пользователя, определенное на каждом элементе стека:

  username stackq password blah

Этот общий пароль должен упростить запрос линии и разрешение конфликтов SGBP членов стека.

Обратитесь к разделу PPP Multilink Отладки этого документа для обсуждения аутентификации Канала "PPP", когда удаленный клиент наберет в элементам стека.

В случае проводного соединения или проблем маршрутизации, одна распространенная ошибка имеет IP - адрес источника элемента стека (который фактически получен в пакет приветствия SGBP сообщение), отличающийся от локально определенного IP-адреса для того же элемента стека.

  systema#debug sgbp error
  %SGBP-7-DIFFERENT - systemb's addr 1.1.1.2 is different from hello's addr 3.3.4.5

Это означает, что IP - адрес источника пакет приветствия SGBP полученного от systemb не совпадает с IP-адресом, настроенным локально для systemb (посредством команды sgbp member). Исправьте это, переходя к systemb и проверяя для нескольких интерфейсов, которыми пакет приветствия SGBP может передать сообщение.

Другая типичная причина для ошибок:

  %SGBP-7-MISCONF, Possible misconfigured member routerk (1.1.1.6)

Это означает, что вам не определяли systemk локально, но другой элемент стека делает.

Отладка Multilink PPP

Первая вещь проверить состоит в том, подтвердили ли клиент и элемент стека подлинность на PPP правильно.

Данный пример демонстрирует Аутентификацию CHAP, поскольку это более включено. Как знакомый пример, это использует Платформу cisco в качестве клиента вместе с локальными именами пользователя (Terminal Access Controller Access Control System (TACACS) Плюс (TACACS +) поддерживается также, но не показан здесь).

Клиентский userx Каждый участник стека stackq
#config

username stackq password blah
#config

username userx password blah

Никакие включенные интерфейсы номеронабирателя

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

  1. Сначала удостоверьтесь, что многоканальное количество глобального виртуального шаблона определено на каждом элементе стека.

      #config
      Multilink virtual-template 1
    
  2. Если вы не настроили интерфейсов номеронабирателя для рассматриваемых физических интерфейсов (таких как PRI, BRI, асинхронный, и синхронный последовательный), можно определить:

      interface virtual-template 1
      ip unnumbered e0
      ppp authen chap
      ppp Multilink
    

    Примечание: Вы не определяете определенный IP-адрес на виртуальном шаблоне. Это вызвано тем, что проектируемые интерфейсы виртуального доступа всегда клонируются от интерфейса виртуального шаблона. Если последующий Канал "PPP" также спроектирован элементу стека с интерфейсом виртуального доступа, уже клонированным и активным, у вас есть идентичные IP - адреса на этих двух виртуальных интерфейсах, заставляя IP ошибочно направить между ними.

Включенные интерфейсы номеронабирателя

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

Примечание: Интерфейс номеронабирателя, Номеронабиратель 1, отображен на сеансе многоканального подключения PPP следующим образом:

  systema#show ppp Multilink
  Bundle userx 2 members, Master link is Virtual-Access4
  Dialer interface is Dialer1
  0 lost fragments, 0 reordered, 0 unassigned, 100/255 load
  0 discarded,  0 lost received, sequence 40/66 rcvd/sent
  members 2
  Serial0:4  
  systemb:Virtual-Access6    (1.1.1.1)

LCP и NCP

Состояния LCP на всех задействованных интерфейсах должны произойти. IPCP, ATCP и другие NCP должны произойти только на групповом интерфейсе.

Групповой интерфейс Virtual-Access4 покажите, что международные выходные данные должны читать следующим образом:

  router#show int  Virtual-Access4
  Virtual-Access4 is up, line protocol is up 
          :
      LCP Open, Multilink Open
      Open: ipcp
              :

Все другие задействованные интерфейсы должны иметь придерживающееся, показывают международные выходные данные:

  router# show int Serial0:4
  Serial0:4 is up, line protocol is up 
          :
  LCP Open, Multilink Open
  Closed:  ipcp

Отладка VPN/L2F

Включите придерживающееся:

  debug vpn event
  debug vpn error

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

  Serial0:21 VPN Forwarding 
  Serial0:21 VPN vpn_forward_user userx is forwarded

На целевом члене стека, если вы видите придерживающееся:

  Virtual-Access1 VPN PPP LCP not accepting rcv CONFACK
  Virtual-Access1 VPN PPP LCP not accepting sent CONFACK

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

Помните минимальную конфигурацию (использующий CHAP в качестве примера):

  #config
  multilink virtual template 4
  int virtual-template 4
  ip unnum e0
  encap ppp
  ppp authen chap 
  ppp Multilink

Можно видеть придерживающееся:

Virtual-Access1 VPN PPP LCP accepted sent & rcv CONFACK

Если вы видите вышеупомянутое сообщение, это означает, что L2F успешно спроектировал Канал "PPP" от элемента стека, который сначала принял входящий звонок элементу стека, где групповой интерфейс для того же клиента находится (или создаст, как в разгружать сценарии).

Распространенная ошибка является сбоем для определения имени пользователя для общего названия стека (stackq) или не соответствие с паролем стека на всех элементах стека.

Выполните следующую команду:

  debug vpdn l2f-error

Результаты следующего сообщения:

  L2F Tunnel authentication failed for stackq

Исправьте соответствие имени пользователя и пароля на каждом элементе стека в этом случае.

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

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


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


Document ID: 14945