Frame relay cisco что это
Frame Relay — пример настройки и описание
Frame Relay – WAN-протокол, работающий на втором уровне модели OSI, то есть, там же, где работают Ethernet, PPP, HDLC и др. Frame Relay пришёл на смену протокола X.25, в России сравнительно широкого распространения не получил, а сейчас – и вовсе его время давно прошло. Знания этого протокола могут потребоваться, если вы работаете у провайдера, у которого по старой памяти остались какие-то абоненты, работающие по FR. Кроме того, знание Frame Relay помогает в понимании MPLS.
Принципы работы Frame Relay
Аналогично другим WAN протоколам мы, как клиент, настраиваем маршрутизатор как DTE. В качестве DCE выступает провайдерское оборудование, а именно, коммутатор FrameRelay switch. В качестве такого коммутатора может выступать обычный маршрутизатор cisco и пусть слово «коммутатор» вас не смущает. В этой статье я не буду останавливаться на терминологии WAN, большую часть материала можно прочитать в статье «Что такое clock rate, DCE и DTE?».
Как используется Frame Relay? Мы арендуем у провайдера виртуальную сеть для соединения двух удалённых подразделений, он даёт нам кабель и говорит: настройте у себя на маршрутизаторе Frame Relay и добавляет: «Чтобы попасть из офиса А в офис Б используется DLCI 102, чтобы попасть из офиса Б в офис А используется DLCI 201»
DLCI – это «Data Link Connection Identifier», идентификатор соединения. У провайдера есть большая сеть, через которую проходит множество разных соединений (Virtual Circuit-ов), каждое направление по каждому из них имеет свой идентификатор – DLCI. Причём, DLCI имеет локальное значение, так что, если смотреть на приведённый рисунок, то первый же Frame Relay коммутатор «А», получив фрейм с DLCI 201 вполне может поменять его на другое значение, так как само число 201 имеет смысл только в контексте маленького участка сети между двумя соседними коммутаторами. Благодаря этому одни и те же номера DLCI можно использовать в разных частях сети, главное, чтобы все настройки на коммутаторах были согласованы между собой. DLCI Фактически это адрес канального уровня, то есть для Frame Relay DLCI – это способ идентификации общающихся устройств, как, например, MAC адрес для Ethernet. Только тут речь идёт скорее не об устройствах, а о каналах. В общем всё это для общего развития, а практически надо знать одно, с каждого из наших устройств, на границе облака, до каждого другого (до которого мы арендовали сеть от этого) ведёт один конкретный DLCI, который нам надо настроить.
Структура кадра Frame Relay
Кадр FR имеет следующий формат:
Для того, чтобы отправить что-то через сеть, надо, чтобы маршрутизатор знал, что его ждёт за тем или иным DLCI-ем, на том конце линии. Иными словами, необходима таблица соответствия DLCI-ев и IP адресов роутеров, находящимися за ними. Такая таблица называется frame relay map, она может строиться автоматически или настраиваться вручную администратором. С некоторой натяжкой можно провести аналогию между frame relay map и arp таблицей в Ethernet, так как в обоих случаях таблица нужна для установления соответствия между адресами протоколов второго и третьего уровней. Для автоматического создания таблицы есть протокол Inverse ARP – он позволяет, зная номер DLCI, узнать ip адрес маршрутизатора, находящегося на том конце соответствующего этому DLCI маршрута.
Frame Relay сам по себе занимается только доставкой данных. Однако, у него есть расширение LMI – Local management interface, которое позволяет, например, автоматически получать от провайдера список открытых для нас DLCI, через него же работает и Inverse ARP. Технически LMI помещает служебную информацию в поля ADDRESS и DATA обычного Frame Relay фрейма.
Настройка Frame Relay на маршрутизаторе
В CCNA рассматривается два способа настройки Frame Relay: с сабинтерфейсами и без. Второй способ проще, но через него не будет работать динамическая маршрутизация. Поэтому он может использоваться либо при соединениях точка-точка, либо, если вы знаете, что делаете.
Имеется топология, давайте попробуем настроить двумя способами.
Настройка без сабинтерфейсов
Пусть провайдер нам сообщил номера DLCI:
IP адреса маршрутизаторов:
Настройка без сабинтерфейсов – все DLCI-и выходят наружу с нашего маршрутизатора через один общий serial интерфейс.
Настройка достаточно простая: мы указали включили интерфейс, настроили инкапсуляцию и ip адрес, с помощью bandwith сообщили маршрутизатору реальную скорость канала (чтобы потом, например, метрика правильно считалась) и добавили две строчки в карту framerelay, сообщив, что 192.168.0.2 находится за DLCI-ем 102, а 192.168.0.3 – за 103. Слово broadcast означает в данном контексте вот что: Сам FR не поддерживает широковещательный трафик, но если мы задаём это слово, то при необходимости отправки брудкаста, он будет заменён на множество юникастовых фреймов – для всех получателей. Без этого слова не будут работать, например, протоколы динамической маршрутизации.
Аналогично настраиваем R3:
Настройка с сабинтерфейсами
Теперь попробуем реализовать то же самое, но с сабинтерфейсами. Отличие этого способа в том, что для каждого DLCI создаётся отдельный сабинтерфейс. Это нужно для работы протоколов динамической маршрутизации. Дело в том, что в динамической маршрутизации есть правило Split horizon, которое означает, что маршрутизатор не сообщает про некую сеть через тот же интерфейс, откуда он про неё узнал. То есть, если настраивать без сабинтерфейсов и R2 сообщит про какую-то сеть для R1, то R1 не сможет про неё рассказать дальше роутеру R3, так как он узнал про эту сеть с интерфейса s0/0/0, он не может через него же про неё сообщить. В случае использования сабинтерфейсов проблема решается, так как R1 узнал про эту сеть через интерфейс s0/0/0.102, а сообщил через s0/0/0.103. В этой топологии разные DLCI находятся на разных сабинтерфейсах, а значит надо поменять и ip адресацию чтобы не получилось, что у маршрутизатора два интерфейса в одной и той же сети.
Пусть сети будут такие:
Как и при создании сабинтерфейсов для работы с VLAN, сам номер сабинтерфейса не говорит ничего о номере DLCI для связывания с DLCI используется команда frame-relay interface-dlci. Но с точки зрения удобства и понятности, лучше делать номер сабинтерфейса совпадающим с номером DLCI.
К статье прилагаю два примера: настройка без сабинтерфейсов и с сабинтерфейсами.
VoIP через Frame Relay с QoS (фрагментация, формирование трафика, приоритет RTP IP/LLQ)
Параметры загрузки
Содержание
Общие сведения
В документе описан пример настройки сети с VoIP через Frame Relay с качеством обслуживания (QoS). В этот документ включены общие технические сведения о настроенных возможностях, указания по проектированию и описания основных стратегий проверки и устранения неисправностей.
Важно отметить, что пример настройки в этом документе содержит 2 голосовых маршрутизатора, подсоединенных к сети Frame Relay. Тем не менее, во многих топологиях маршрутизаторы с поддержкой передачи голоса могут быть установлены в любой зоне сети. Обычно голосовые маршрутизаторы используют LAN-подключение к другим маршрутизаторам, подключенным к WAN. Это важно, потому что если голосовые маршрутизаторы не подключаются напрямую через Frame Relay, все команды конфигурации WAN должны быть настроены на маршрутизаторах, подключенных к WAN, а не на голосовых маршрутизаторах, как показано в примере ниже.
Предварительные условия
Требования
Для данного документа нет особых требований.
Используемые компоненты
В данном документе приведены сведения для следующих версий программного и аппаратного обеспечения:
Маршрутизатор Cisco 3640 с ПО Cisco IOS® выпуск 12.2.6a (Enterprise Plus);
Маршрутизатор Cisco 2621 с ПО Cisco IOS выпуск 12.2.6a (Enterprise Plus);
Организация очереди с малым временем ожидания (LLQ) в постоянных виртуальных каналах Frame Relay (PVC). Данная функция представлена в ПО Cisco IOS версии 12.1(2)T;
Приоритет IP RTP протокола Frame Relay, представленного в ПО Cisco IOS выпуск 12.0(7)T;
Форум Frame Relay Forum (FRF). Фрагментация 12, представленная в ПО Cisco IOS выпуск 12.0(4)T;
Версии ПО Cisco IOS выше 12.0.5T обладают улучшенными характеристиками для сжатого RTP (cRTP).
Условные обозначения
Для получения дополнительной информации о принятых в документе условных обозначениях обратитесь к разделу Технические рекомендации Cisco. Условные обозначения.
Руководство по проектированию QoS для передачи голосовых вызовов по протоколу IP по технологии Frame Relay
Существует два основных требования для обеспечения хорошего качества голоса:
Требования к пропускной способности канала оптимизированы и технически выверены.
Для удовлетворения упомянутых требований следуйте инструкциям:
Строгая очередность для голосового трафика (приоритеты LLQ или IP RTP)
Для голосового трафика существуют 2 способа предоставления жесткого приоритета.
Приоритет IP RTP (также называется очередь с приоритетом/взвешенное справедливое управление очередями (PQ/WFQ))
LLQ (или PQ/очереди с весами на основе классов (PQ/CBWFQ))
Приоритет IP RTP
Приоритет IP RTP Frame Relay создает очередь со строгим приоритетом для постоянного виртуального соединения через Frame Relay для группы потоков пакета RTP, которая принадлежит диапазону порта назначения протокола UDP. В то время как фактические порты используют динамическое согласование между конечными устройствами и шлюзами, все продукты Cisco VoIP используют один и тот же диапазон UDP-портов (с 16384 до 32767). После распознания маршрутизатором трафика VoIP он будет помещен в строго приоритетную очередность. Когда PQ пустая, остальные очереди обрабатываются на основе стандартной программы WFQ. Механизм IP RTP Priority активизируется только при возникновении перегрузок в интерфейсе. На рисунке представлен механизм работы приоритета IP RTP:
Примечание. Приоритет IP RTP позволяет организовать PQ, когда в очереди по умолчанию (WFQ) есть полоса пропускания. Однако он жестко ограничивает содержание PQ, если интерфейс перегружен.
LLQ – это метод, который обеспечивает строго приоритетную очередность (PQ) для CBWFQ. LLQ включает единую строгую PQ в рамках CBWFQ на уровне класса. При использовании LLQ отправка данных, для которых важно время задержки и которые находятся в очереди по приоритету, выполняется вне очереди. В VoIP с установленной LLQ голосовой трафик размещается в строгом соответствии с приоритетом очередности.
PQ управляется так, чтобы справедливые очереди не испытывали недостатка пропускной способности. При настройке PQ следует указать в Кбитах максимальную ширину канала, доступную PQ. Когда интерфейс перегружен, организация очередей с приоритетами PQ обслуживается до тех пор, пока нагрузка не достигает установленного значения скорости в Кбит/с в приоритете оператора. После этого лишний трафик сбрасывается, чтобы избежать проблем нехватки полосы пропускания для PQ с низкими приоритетами, характерных для традиционных очередей Cisco с приоритетами.
Примечание. C помощью LLQ для Frame Relay очереди настраиваются через PVC. Каждый постоянный виртуальный канал имеет очередь приоритетов и назначенное число обычных очередей.
Этот метод более комплексный и гибкий, чем метод приоритета IP протокола реального времени. Выбор метода должен основываться на видах трафика в реальной сети и актуальных потребностях.
Сравнение приоритета LLQ и IP RTP
В таблице представлены главные различия между приоритетом LLQ и IP RTP и данные о границах применимости каждого метода.
Сопоставление голосового трафика основано на следующем:
Списки доступа. Например, следующие поля: диапазон UDP-портов, адреса хостов, тип услуги (ToS) в заголовке IP (например, приоритет IP-пакета, кодовая точка дифференцированных сервисов (DSCP);
Диапазон портов IP RTP;
Поля IP ToS—DSCP и/или приоритет IP-пакета;
Протоколы и входящие интерфейсы;
Все действительные критерии совпадения, используемые в CBWFQ.
Больше гибкости в процессе сопоставления потока данных и направления его на определенные PQ и CBWFQ;
Можно настроить дополнительные классы для гарантированной пропускной способности для другого трафика, такого как сигналы VoIP и видео.
Недостатки: сложная конфигурация.
Сопоставление голосового трафика основано на:
Данных относительно диапазона портов RTP/UDP: 16384-32767.
Достоинства: простая конфигурация.
Трафик протокола RTCP (сигнализация VoIP), обслуживаемый в WFQ-очереди.
Обслуживание трафика VoIP в PQ. Однако любой трафик, которому необходимо приоритетное обслуживание и гарантированная полоса пропускания, обслуживается в WFQ. WFQ позволяет различать потоки по весу (на основе приоритета IP-адреса), но не обеспечивает гарантированной полосы пропускания для любого потока.
Выбор между ними следует делать на основе моделей трафика в своей реальной сети и своих фактических потребностей;
Если необходимо установить строгий приоритет для голосового трафика, и другой трафик можно принять за однотипный (данные), то приоритет IP RTP окажется очень полезным для сети с простой конфигурацией;
Если планируется назначить приоритеты голосовому трафику на основе критериев, отличных от портов UDP. Например, Поведение дифференцированных служб (DiffServ) на каждом переходе (PHB) и LLQ.
FRTS для голоса
FRTS обладает рядом параметров, полезных для управления сетью при перегруженном трафике. FRTS позволяет решить проблему узких мест в сетях Frame Relay с высокоскоростным соединением с центральным узлом и низкоскоростными соединениями с удаленными офисами. Чтобы ограничить скорость передачи данных с виртуального канала (VC) на центральный узел, можно настроить значения контроля за скоростью.
Следующие определения относятся к FRTS:
Согласованная скорость передачи данных (CIR) — скорость (бит в секунду), гарантируемая поставщиком услуг Frame Relay для передачи данных. Значения CIR устанавливаются поставщиком услуг Frame Relay и настраиваются пользователем на маршрутизаторе;
Примечание. Значение скорости доступа порт/интерфейс может быть выше CIR. Значение является средним за период времени, равный фиксированному интервалу измерения скорости (Tc).
Согласованный пакет (Bc) — максимальное количество битов, которое сеть Frame Relay может передать за время Tc. Tc = Bc / CIR;
Избыточный пакет (Be) — максимальное количество несогласованных битов, которое сеть Frame Relay пытается передать за время Tc со скоростью выше CIR;
Фиксированный интервал измерения согласованной скорости (Tc) — интервал времени, за который передаются биты Bc или (Bc+ Be). Tc вычисляется следующим образом: Tc = Bc / CIR. Значение Tc не просто настраивается на маршрутизаторах Cisco. Оно рассчитывается после настройки значений Bc и CIR. Значение Tc не должно превышать 125 мс;
Пакет обратного явного уведомления о перегрузке (BECN) — бит в заголовке Frame Relay, означающий перегрузку сети. Когда коммутатор Frame Relay обнаруживает перегрузку, он задает бит BECN на кадрах, направленных на исходный маршрутизатор, предписывая ему снизить скорость передачи.
Настройка FRTS для голосового трафика отличается от настройки трафика, предназначенного только для передачи данных. При настройке FRTS на характеристики голоса приходится изменять некоторые настройки трафика данных. Для получения дополнительной информации обратитесь к разделу Фрагментация (FRF.12) этого документа.
Фрагментация (FRF.12)
Например, 1500-байтовому пакету требуется 214 мс, чтобы покинуть маршрутизатор через канал 56 кбит/с. Если посылаются пакеты данных размером 1500 байт в нереальном времени, то пакеты реального времени (голосовые) помещаются в очередь до тех пор, пока не закончится передача большого пакета данных. Такая задержка недопустима для голосового трафика. Если пакеты данных в нереальном времени фрагментируются на более мелкие кадры, то они перемежаются кадрами реального времени (голосовыми). Таким образом, и речевые, и информационные кадры могут передаваться вместе по низкоскоростным каналам, не вызывая чрезмерной задержки для голосового трафика в реальном времени.
Для получения дополнительной информации о фрагментации обратитесь к разделу Фрагментация для передачи голосовых данных в Frame Relay.
Примечание. При наличии выделенного канала с пропускной способностью, равной половине пропускной способности канала T1 (768 Кб/с), вам, возможно, не нужна функция фрагментации. Однако вам все равно необходим механизм QoS (в данном случае приоритет IP RTP или LLQ). Половина T1 или большие скорости дают достаточную пропускную способность, чтобы речевые пакеты могли входить и выходить из очереди в рекомендованном диапазоне задержки сериализации (10 мсек, не позднее чем 20 мсек). Кроме того, в случае полного соединения T1 можно обойтись без протокола сжатия в реальном времени (cRTP), который обеспечивает экономию полосы пропускания за счет сжатия заголовков IP RTP.
Сокращение полосы пропускания
Примечание. Для обеспечения хорошего качества голосовой связи cRTP не требуется. Эта функция позволяет уменьшить использование полосы пропускания. После соблюдения всех требуемых условий и настройки хорошего качества речи настройте cRTP. Данная процедура может ускорить устранение неисправностей, изолировав потенциальные проблемы cRTP.
Проконтролируйте загрузку ЦП маршрутизатора. Отключите cRTP, если она выше 75%. При больших значениях скорости канала, выгоды от экономии пропускной способности cRTP могут быть сведены на нет из-за дополнительной нагрузки ЦП. Рекомендуется использовать cRTP только в каналах со скоростью ниже 768 Кбит/с, если только маршрутизатор не работает с низким коэффициентом загруженности ЦП.
Примечание. В отсутствие единого стандарта был разработан протокол cRTP для Frame Relay, совместимый с собственным механизмом инкапсуляции Cisco. Поэтому он не совместим с инкапсуляцией IETF (Инженерной группы по развитию Интернета) для Frame Relay. В последнее время FRF.20 был усовершенствован для возможности сжатия заголовков RTP на инкапсуляции IETF. Однако на момент последнего обновления этого документа (май 2002 года) FRF.20 не поддерживается.
Для получения дополнительной информации обратитесь к разделу Сжатый транспортный протокол реального времени.
Выбор Coder/Decoder (Codec)
Используйте низкоскоростные кодеки в ветках вызова VoIP. По умолчанию для каждой точки вызова VoIP установлен кодек G.729 (8 Kбит/сек).
Примечание. Несмотря на то что двухтоновые многочастотные (DTMF) сигналы обычно точно передаются при использовании высокоскоростных голосовых кодеков, например G.711, низкоскоростные кодеки (например G.7 29 и G.723.1) оптимизированы под голосовые шаблоны и искажают DTMF-тоны. Этот подход может вызвать проблемы доступа к системам интерактивного голосового ответа (IVR). Команда dtmf relay решает проблему искажения DTMF. Она передает тональные сигналы DTMF вне полосы или отдельно от кодированного голосового потока. При использовании низкоскоростных кодеков (G.729, G.723) включите команду dtmf relay для адресуемой конечной точки вызова VoIP.
Включите функцию опознавания активности речи (VAD)
Обычный разговор, как правило, содержит 35-50% пауз. Пакеты молчания сжимаются при использовании VAD. При планировании полосы пропускания VoIP предполагается, что VAD уменьшает потребность в полосе на 35%. Опознавание активности речи (VAD) сконфигурировано по умолчанию в VoIP для равноправного коммутируемого элемента.
Настройка
В этом разделе приводятся сведения о настройке функций, описанных в данном документе.
Примечание. Для получения дополнительной информации об упомянутых в этом документе командах используйте Средство поиска команды ( только для зарегистрированных пользователей ).
Используйте эту процедуру для настройки LLQ:
Создайте схему классов для трафика VoIP и определите критерии совпадения.
Эти команды объясняют, как выполнить задание:
Эти списки доступа также используются для поиска соответствий голосового трафика с помощью команды match access-group:
Существуют другие методы поиска соответствий, которые можно использовать вместо команд групп доступа:
Начиная с Cisco IOS выпуска 12.1.2.T, функция IP RTP Priority внедрена для LLQ. Эта функция сопоставляет содержимое класса приоритета, которое настроено на порты UDP. Обслуживание только четных портов в PQ ограничено.
Предполагается, что эти два метода приемлемы, если пакеты VoIP маркированы на исходном хосте или сопоставлены и маркированы в маршрутизаторе до выполнения исходящей операции LLQ:
Примечание. Начиная с IOS версии 12.2.2T, VoIP адресуемые конечные точки вызова (dial-peer) могут помечать голосовой однонаправленный канал и сигнальные пакеты до срабатывания LLQ. Это позволяет сделать масштабируемыми маркирование и установку соответствий VoIP-пакетов с помощью значений кодов DSCP для LLQ. За более подробной информацией обратитесь к Классификации передачи сигналов и средств связи протокола VoIP с DSCP для QoS.
Создайте схему классов для VoIP-сигнализации и определите критерии сопоставления (необязательно).
Используйте следующие команды для выполнения этого задания:
Примечание: Вызовы VoIP можно устанавливать с помощью H.323, протокола инициализации сеанса (SIP), протокола управления шлюзами между средами передачи (MGCP) или облегченного протокола контроля вызовов (SCCP) (это собственный протокол, используемый в Cisco Call Manager). Приведенный выше пример предполагает наличие H.323 Fast Connect. Этот список содержит справочную информацию о портах, используемых каналами сигнализации и управления VoIP:
H.323/H.225 = TCP 1720;
H.323/H.245 = TCP 11xxx (Стандартное соединение);
H.323/H.245 = TCP 1720 (Быстрое соединение);
H.323/H.225 RAS = TCP 1719;
SCCP = TCP 2000-2002 (CM Encore);
ICCP = TCP 8001-8002 (CM Encore);
MGCP = UDP 2427, TCP 2428 (CM Encore);
SIP= UDP 5060, TCP 5060 (настраиваемый).
Создайте схему политик и свяжите ее со схемами классов VoIP.
Примечание. Несмотря на то, в PQ можно поставить в очередь различные типы трафиков в реальном времени, рекомендуется использовать эту очередь только для голосового трафика. Трафик в реальном времени, такой как видеоматериалы, может привести к вариации задержки (PQ относится к очередям FIFO). Голосовой трафик требует, чтобы задержки не были переменными, чтобы избежать «дрожания».
Примечание. Сумма величин для положений priority (приоритет) и bandwidth (полоса пропускания) должна быть меньше или равна minCIR для PVC. Иначе команда service-policy не может быть присвоена линии. minCIR в два раза меньше CIR по умолчанию. Чтобы получить сообщения об ошибке, убедитесь в активности команды logging console для консольного доступа и команды terminal monitor для доступа через Telnet.
Для получения дополнительной информации о командах bandwidth и priority обратитесь к разделам Сравнение команд bandwidth и priority политики службы QoS.
Включите LLQ, применив схему политики к исходящему интерфейсу WAN.
Чтобы включить LLQ, используйте следующие команды:
Приоритет IP RTP
Если вы не используете LLQ, следуйте этим инструкциям:
starting-rtp-port — начальный номер узла UDP. Самый низкий номер порта, на который отправляются пакеты. Для VoIP установите значение, равное 16384;
port-range — диапазон портов назначения UDP. Номер, добавляемый к starting-rtp-port, дает самый высокий номер узла UDP. Для VoIP установите значение, равное 16383;
bandwidth — максимальная пропускная способность для приоритетной очереди (в Кбитах). Установите этот номер на основе количества спонтанных звонков, добавляя для каждого звонка ширину полосы пропускания каждого звонка, поддерживаемую системой.
Формирование трафика для передачи голоса
Следуйте инструкциям для настройки управления трафиком для передачи голоса:
Не следует превышать CIR для PVC;
Отключите адаптивное управление Frame Relay;
Установите низкое значение Bc, так чтобы Tc (интервал формирования) был равен 10 мсек (Tc = Bc/CIR). Чтобы получить ожидаемое значение Tc, настройте значение Bc;
Укажите для Be значение 0.
Для получения дополнительной информации обратитесь к разделу Формирование трафика Frame Relay для VoIP и VoFR.
Примечание. Некоторые пользователи используют раздельные PVC для данных и голоса. Если, имея два PVC, вы хотите использовать PVC для пакета данных, оставаясь на уровне CIR или ниже, для голосового PVC, качество голоса будет так же неудовлетворительным, т.к. каналы PVC используют один и тот же физический интерфейс. В таких случаях поставщик услуг Frame Relay и маршрутизатора, должны обеспечить первостепенный приоритет голосового PVC. Последнее можно реализовать с помощью Очередей приоритетов на уровне интерфейса PVC (PIPQ), доступных на базе Cisco IOS выпуск 12.1(1)T.
Фрагментация (FRF.12)
Для низкоскоростных каналов (менее 768 кбит/с) включите фрагментацию. Установите размер фрагмента таким образом, чтобы голосовые пакеты не подлежали фрагментации; задержка сериализации при этом не должна превышать 20 мсек. Установите размер фрагмента на основе самой низкой скорости портов всех маршрутизаторов. Например, если в топологии звездообразной сети Frame Relay концентратор работает на скорости Т1, а удаленные маршрутизаторы имеют порты 64 Кб, то размер фрагмента на обоих маршрутизаторах должен устанавливаться как для 64 Кб портов. Другие PVC, имеющие тот же самый физический интерфейс, необходимо настроить на размер фрагмента, установленный для голосового PVC. Используйте приведенную таблицу для определения размера фрагмента.
Наименьшая скорость связи на пути
Рекомендуемый размер фрагмента (для сериализации 10 мсек)