vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

Эксплуатация

Дата публикации: 28.03.2014
Количество просмотров: 3732

Глава 1 : Биллинг

Некоторые АСР:

NetUP UTM

( http://www.netup.ru/)

Автоматизированная система расчетов NetUP UTM призвана решить круг задач, связанных с расчетом с абонентами за услуги доступа в Интернет. Универсальность системы позволяет использовать ее в сетях практически любого масштаба — от небольших офисов до крупных интернет-провайдеров. Современный подход к решению проблемы учета трафика позволил сделать систему совместимой практически со всеми распространенными платформами и сетевыми устройствами.

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

Основным серверным компонентом системы является ядро. Архитектура ядра такова, что оно органично вписывается в многопроцессорные архитектуры и при высоких нагрузках равномерно использует все предоставленные ресурсы. Ядро UTM разработано на языке C++, что обеспечивает максимально высокую производительность и стабильность.

Биллинговая система UTM 5 cобирает статистику об услугах в реальном времени, производит тарификацию и мгновенно блокирует абонентов при исчерпании средств на счету.

Система позволяет предоставлять широкий спектр услуг:

  • интернет по выделенным линиям (Ethernet, Radio Ethernet, сети кабельного телевидения, xDSL, VPN, PPPoE и др.)
  • коммутируемые соединения (VPN, dial-up, PPPoE)
  • точки публичного доступа (hotspot)
  • IP-телефония (VoIP)
  • классическая телефония

Разработан отдельный модуль для учета услуг платного цифрового телевидения (IPTV).

Биллинговая система NetUP UTM имеет более 1500 инсталляций на территории Российской Федерации и за её пределами.

Поддерживаемые протоколы:

  • Netflow v5
  • RADIUS

Совместимое оборудование:

  • Cisco systems
  • Sun microsystems
  • NSG
  • D-Link
  • Revolution
  • Nomadix
  • MikroTik
  • PC routers

Операционные системы для серверной части:

  • Linux
  • FreeBSD
  • Solaris
  • Windows

Администрирование:

  • Платформонезависимый JAVA-интерфейс администратора

Интерфейсы пользователя:

  • Web-интерфейс
  • утилита UTM5 Wintray

Поддерживается работа с платежными системами::

  • ОСМП
  • Яндекс-Деньги
  • WebMoney
  • E-Port
  • E-Port v2
  • Бином
  • Sms4Pay
  • CyberPlat
  • Z-Pay
  • Волжский банк
  • Кредит-Пилот
  • Одно касание
  • Рапида
  • Уникасса

Сертификат соответствия "Связь" № ОС-1-СТ-0025 на АСР "NetUP UTM" версии 5.0

(Linux, FreeBSD, Solaris, Windows)

BG - биллинг

( http://www.bgbilling.ru/)

Биллинговая система "BG - биллинг" создана для автоматизации деятельности операторов связи. Большой набор модулей позволяет тарифицировать широкий круг услуг, таких как:

  • коммутируемый доступ в Интернет
  • доступ в Интернет по карточкам
  • доступ в Интернет по выделенным линиям
  • доступ в Интернет по VPN
  • IP - телефония
  • услуги классической телефонии
  • услуги кабельного телевидения
  • услуги цифрового кабельного телевидения
  • и др. (список доступных модулей)

В настоящее время система внедрена и успешно эксплуатируется в нескольких десятках организаций по всей територии России, СНГ и зарубежных стран (карта). Кратко о системе: программа написана на Java, в клиент-серверном варианте, база данных MySQL. АРМ администратора системы и операторов реализованны в виде GUI приложения. Для абонентов доступен Web-интерфейс.

Детально:

Платформонезависимость. Благодаря использованию технологии JAVA, программа (как клиент так и сервер) способна запускаться на любой платформе безо всякой модификации, перекомпиляции кода, смен конфигурации.

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

Клиентский GUI Клиент BGBilling - это полнофункциональное GUI приложение, способное к запуску на любой платформе и обеспечивающее легкое манипулирование данными в привычном Windows оконном режиме.

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

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

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

Встроенный планировщик Для запуска регулярных задач вроде начисления абонплат или очистки старых таблиц. Простой интерфейс настройки. Больше никаких мрачных конфигов CRONа!

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

Гибкая настройка параметров договоров Набор параметров договоров может быть изменен произвольно, разным договорам могут соответствовать различные группы параметров. По каждому параметру может быть произведен поиск договора.

Группировка договоров В вашем распоряжении 62 группы, в которые могут быть включены договора. Группы могут быть переименованы, один договор может входить в несколько групп. По группам может быть произведен поиск.

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

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

Открытость и интегрируемость Открытый и простой протокол обмена Клиент - Сервер (HTTP + XML) позволит вам производить простую интеграцию с внешними программами (в т.ч. с бухгалтерскими).

Мощная система разграничения доступа и аудита BG-SECURE Позволит вам быть уверенным что пользователь системы обладает только нужными ему возможностями и отследить некорректные действия операторов по логам. Количество ролей пользователей не ограничено.

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

CRM Система BG-CRM Удобный учет звонков клиентов, проблем сети и задач. Контроль исполнителей и групп решения. Возможность автоматизации процессов подключения, отключения клиентов, сервисных выездов. Учет по адресам.

Сертификат соответствия "Связь" № OC-1-CT-0124 на АСР "BGBilling" версии 4.0

(Любая ОС, поддерживающая SUN Java 1.6.0 и выше)

Билл-Мастер

( http://www.bill-master.ru/)

Автоматизированная система расчетов (АСР) "Билл-Мастер" – современная сертифицированная конвергентная биллинговая система, предназначенная для поставщиков Интернет-услуг, операторов предоставляющих услуги мультимедийных трансляций, операторов фиксированной и IP-телефонии.

АСР "Билл-Мастер" создана с учетом многолетнего и обширного опыта эксплуатации узлов операторов связи, соответствует передовым стандартам и по праву занимает ведущие позиции на российском рынке современных автоматизированных систем расчета телекоммуникационных услуг.

Сертификат соответствия № ОС-3-СТ-0126

(неизвестно)

LANBilling

( http://www.lanbilling.ru/)

Программный комплекс LANBilling 1.8 - тиражируемая автоматизированная система расчетов (АСР) с абонентами за услуги связи, предоставляемые сервис провайдерами (операторами). Система позволяет производить сбор первичной информации об оказанных услугах, обработку первичных данных, в процессе которого, обеспечивается тарификация потребленных услуг, хранение данных и генерацию выходных документов. Версия 1.8 в своем составе имеет модули (агенты) для тарификации всех 4 типов услуг: объемных (Интернет доступ по выделенной линии), временных (все виды телефонии), разовых и периодических.

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

Комплекс использует объектную модель, которая предоставляет оператору возможность выбора между двумя возможными типами расчетов с абонентами. Расчет по совокупному балансу (конвергентный биллинг), возможный в модификации Pro, и раздельный расчет по каждой услуге индивидуально (модификация "Базовая версия"). АСР обеспечивает контроль доступа абонентов к услугам посредством гибких (настраиваемых) механизмов управления внешними по отношению к АСР устройствами, обеспечивающих предоставление услуг.

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

Система обладает развитым и защищенным www интерфейсом как для административного управления АСР персоналом оператора, так и для доступа к пользовательским функциям абонентами.

Сертификат соответствия № ОС-1-СТ-0039

(Linux, FreeBSD)

КРУС

( http://www.krus.ru)

Автоматизированная биллинговая система "КРУС" — автоматизированный программный комплекс для предприятий связи. В "КРУС" реализованы процедуры автоматизации основных бизнес-процессов по обслуживанию абонентов: регистрация новых абонентов в системе, подержание актуальной информации о балансе и пополнении счетов в соответствии с указанной тарификацией, возможности печати счетов и отчетов. В системе предусмотрены гибкие инструменты для сбора и обработки статистики, работы с оперативными данными журнала операций, возможности автоматического отключения и подключения абонентов.

Система "КРУС" — оптимальное решение для компаний, предоставляющих услуги:

  • доступа к Интернет по выделенным и коммутируемым каналам;
  • телефонной связи (IP, местной, междугородней и международной);
  • организации сетей передачи данных и аренды каналов связи;

Сертификат соответствия "Связь" № ОС/1-СТ-325

(Установка осущетсвляется сотрудниками компании)

Ideco ICS

( http://www.ideco-software.ru)

Ideco Internet Control Server 2.5 – это универсальный Интернет шлюз с межсетевым экраном и функциями учета трафика. Ideco ICS позволяет быстро и легко настроить качественный доступ в Интернет всем пользователям, сделает работу с Интернет управляемой и безопасной.

Возможности Ideco ICS

  • Контроль и управление доступом в Интернет
  • Защита пользователей и сети предприятия
  • Учет трафика, планирование и ограничение расходов
  • Прозрачное кэширование веб трафика
  • Антивирус веб трафика
  • Фильтрация трафика, блокирование рекламы
  • Интеллектуальная приоритезация трафика – QoS
  • Удаленное подключение сотрудников и подразделений
  • Почтовый сервер с антивирусом и веб-интерфейсом
  • Кэширующий DNS
  • Корпоративный веб-сервер
  • Firewall, NAT, портмаппинг,
  • Ограничение скорости - shaper.
  • DHCP, FTP, VPN, VLAN
  • Поддержка нескольких интернет каналов, резервирование и автоматическое переключение.
  • и многое другое...

Сертификат соответствия №ОС-1-СТ-0125

(Программное обеспечение на базе ядра Linux)

Traffic Inspector

( http://www.smart-soft.ru/)

Серверная часть программы Traffic Inspector реализована только под платформу Windows (2000/XP/2003/Vista), клиенты же могут использовать любую операционную систему - тут ограничений нет. Система легко устанавливается, настраивается и управляется, имеются средства удаленного администрирования. Для настройки программы не нужны особые знания и квалификация - специалист, способный установить Windows, настроить сеть и подключиться к Интернет, без проблем настроит и эту программу.

В Traffic Inspector мы постарались в одном продукте реализовать, по крайней мере, большинство задач, возникающих при подключении к Интернет по выделенному каналу. Эти задачи можно разделить так:

  • Обеспечить доступ в сеть Интернет из внутренней сети.
  • Авторизация и разграничение доступа пользователей.
  • Билинг - тарификация пользователей, подсчет трафика и блокировка доступа при перерасходе.
  • Обеспечить пользователей средствами экономии трафика и дать им возможность самостоятельно контролировать свою работу в Интернет.
  • Сетевая защита (Firewall) - закрыть сервер доступа и внутреннюю сеть от несанкционированного доступа извне.
  • Подробный анализ сетевого трафика, потребляемого у провайдера.
  • Динамическое ограничение скорости работы пользователей или их групп.
  • Advanced Routing (Policy Routing или Source Routing) - возможность гибкой настройки перенаправления разных пользователей и видов трафика на разные каналы доступа.
  • Отключение пользователей от сети Интернет при заражениях сетевыми вирусами.

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

Эта программа - полностью самодостаточное решение. Но при необходимости ее отдельные службы могут быть использованы отдельно. Например, Traffic Inspector с некоторыми ограничениями может работать как система билинга для других серверов, например Microsoft ISA Server.

Сертификат соответствия №ОС-1-СТ-0080

(Windows)

Bil-2000

( http://bil-2000.berdaflex.com)

Программа Bil-2000 предназначена для автоматизации деятельности студий кабельного телевидения (СКТВ), домофонных сетей и других видов бизнеса, которые связаны с оказыванием клиентам периодических и разовых услуг.

Основные функции системы управления абонентами КТВ Bil-2000

  • Регистрация договоров с клиентами на оказание услуг;
  • Сбор и хранение информации об абонентах;
  • Поиск и выборка клиентов по разнообразным критериям;
  • Ввод и учет информации о предоставляемых клиентам пакетах услуг;
  • Автоматический (при использовании CAS) и полуавтоматический режимы учета состояния (подключено / отключено) оказываемых клиенту услуг;
  • Тарификация предоставляемых услуг;
  • Начисление сумм к оплате клиентам за предоставленные услуги;
  • Ручной и автоматический ввод информации о платежах клиентов;
  • Возможность предоставления скидок отдельным клиентам;
  • Вывод разнообразной статистической информации по клиентам и работе операторов системы.
  • Формирование и печать разнообразных отчетов по статистике, истории задолженности клиентов и т. д.;
  • Получение информации по проживанию клиентов (абонентов) в зоне обслуживания кабельной сети;
  • Сводка по процентному соотношению подключений в разрезе домов для анализа эффективности вложений в данный сектор;
  • Получение подробной информации по клиентам, их задолженности, платежам, истории оказываемых услуг и т.д.;
  • Формирование и рассылка писем с уведомлениями по задолженности;
  • Автоматизирован процесс от многократного напоминания, до формирования документов в суд по взысканию платежей от злостных неплательщиков.

(Windows)

Реквест-Биллинг

( http://requestbilling.com/)

Пользовательский интерфейс

АСР «Реквест-Биллинг» позволяет быстро и интуитивно просто осуществить все виды работ с абонентом: заведение договоров, техническую поддержку, расчет и детализацию услуг, предоставленных абоненту, формирование бухгалтерских документов, формирование отчетов и многое другое.

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

Виды услуг

В биллинге реализованы следующие основные типы доступа:

  • Доступ в интернет через выделенные линии (xDSL, Ethernet, WiFi, Radio Ethernet и т.д.; с использованием (PPPoE, PPTP) и без использования VPN)
  • Доступ в интернет через Dialup
  • Традиционная телефония
  • IP-Телефония, в том числе посредством карточек

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

Гибкая тарификация

Возможности при создании тарифов ограничены лишь фантазией заказчика. Могут учитываться какие угодно параметры: объём и длительность соединений, исходящий и входящий трафик, время суток, праздники и выходные, предоплатные и кредитные схемы, мультивалютность, потребленный трафик на прошлой неделе или в прошлом году - вплоть до температуры за окном. Тарифные планы способны менять свои условия по вр

Контроль доступа

Управление доступом абонентов, как правило, осуществляется в полностью автоматическом режиме. Вместе с тем работают: механизмы отсроченных платежей, постоянных кредитов, система учета VIP абонентов – все это обеспечивает максимальную гибкость при обслуживании абонентов.

«Реквест-Биллинг» способен спрогнозировать отключение абонента в течении ближайшего времени и проинформировать его о скором отключении и о необходимости пополнения счета.

Интеграция

«Реквест-Биллинг» имеет развитую систему интеграции со сторонними приложениями и системами. Пополнение счета может происходить в реальном времени непосредственно из 1С-Бухгалтерии, из платежных систем (например, Свободная Касса), из банкоматов (Сбербанк, Балтийский Банк), с помощью интернет-карт оплаты. Кроме этого, реализован обмен данными с 1С-Бухгалтерией по абонентам и их начислениям. Вы можете выбрать, как будут формироваться бухгалтерские документы: непосредственно в 1С-Бухгалтерии или в биллинге.

 

Сертификат соответствия "Связь" №ОС-1-СТ-0234 на Автоматизированную систему расчетов «Реквест-Биллинг» (версия ПО 1.0)

(Windows)

Глава 2 : Процесс принятия решения в BGP (коротко о главном)

Итак после длительного и мучительного ожидания, переписок с RIPE и некоторых расходов Вы таки получили свою AS и сеть к ней, и хотите влиться в дружный коллектив интернет-провайдеров. Или еще не получили, но уже хотите разобраться в том как работает BGP. Или хотите узнать что-то новое.

В данный статье я постараюсь осветить некоторые "общеизвестные" моменты настройки работы протокола BGP, которые многим начинающим незнакомы или освещены недостаточным образом. Главный упор будет делаться на практические примеры.

Итак что есть BGP ? BGP - это модифицированный дистанционно-векторный протокол маршрутизации, созданный с прицелом решать не столько технические, сколько политические задачи по управлению глобальной сетью и взаимодействию внутри нее. Из чего же, так сказать, состоит BGP? Главными элементами этого протокола являются:

  • Автономная система (AS),
  • eBGP/IGP(в том числе iBGP),
  • соседи ("нейборы"),
  • атрибуты и работа с ними.

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

В качестве транспорта для протокола BGP используется протокол TCP (порт 179). Маршрутизаторы, на которых включена поддержка протокола BGP общепринято называть спикерами. 2 спикера, которые обмениваются между собой маршрутной информацией по протоколу BGP называются соседями или "нейборами", или же "пирами". При работе с протоколом BGP, взаимодействующих соседей надо указывать явным образом. Соседи устанавливаем друг с другом tcp-соединения и начинают "договариваться" об установке соединения для обмена информацией по протоколу BGP. Такого рода соединение называется "BGP сессия".

Процесс создания BGP сессии достаточно сложен и проходит множество стадий, на которых соседи обмениваются различной служебной информацией и сверяют ее. Если на этапе обмена служебной информацией не произошло никаких ошибок, то соединение переходит в состояние, когда происходит обмен маршрутной информацией. Такое состояние BGP сессии называется установленное (Established). Процесс обмена маршрутами состоит в обмене специальным набором данных, которые состоят из префиксов сетей и их атрибутов. Ну, если префикс сети - это префикс сети и есть, и с ним все ясно, то что есть атрибуты ?

Атрибуты - это специальные данные, соответствующие префиксу и несущие ряд служебной информации о данном префиксе. К примеру, атрибут NEXT_HOP указывает, на какой ip-адрес надо направить пакеты, чтобы достичь той или иной сети.

Атрибуты бывают обязательные и необязательными, а также транзитивными или не транзитивными. Обязательный атрибут маршрута - это такой атрибут, без которого невозможна передача маршрута. К примеру, это, уже указанный выше, NEXT_HOP. Транзитивными же называются те атрибуты, передача которых производится не только между маршрутизаторами внутри своей AS, но и в другие AS. Не транзитивные же атрибуты за пределы своей AS "не выходят", то есть в другие AS не передаются.

К обязательным атрибутам относятся:

ORIGIN - Обязательный транзитивный атрибут. Указывает источник обновления маршрута, то есть откуда пришла информация о маршруте. Может принимать 3 значения:

  • IGP - информация о доступности маршрута была генерированной внутри той AS, откуда пришел префикс.
  • EGP - информация о доступности сети была получена через протокол EGP.
  • INCOMPLETE - информация о доступности сети была получена по другому, то есть неизвестно как.

AS_PATH - Обязательный транзитивный атрибут. Определяет путь, через который проходит маршрут, прежде, чем попасть к нам. К примеру, если есть префикс x.y.z.w/N в некой AS (к примеру, 1), и между нами и AS1 расположены AS с номерами 3,5 и 7, то AS_PATH этого префикса будет иметь вид: 1 3 5 7. А после прохождения нашей AS, в AS_PATH добавится номер нашей AS (к примеру - 10) и примет вид 1 3 5 7 10.

NEXT_HOP - Обязательный транзитивный атрибут. Мы уже вскользь упоминали его. Суть данного атрибута - указать ip, который является шлюзом для достижения той или иной сети, причем в зависимости от характера работы протокола BGP, характер его поведения видоизменяется (подробнее об этом - чуть позже).

Кроме этих 3-х обязательных атрибутов есть еще и множество необязательных, рассматривать которые сразу (в отрыве от применения) нет смысла.

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

  1. Если NEXT_HOP маршрута не доступен, маршрут игнорируется.
  2. Сравнивается вес (атрибут WEIGHT) маршрутов. Маршрут с большим весом является предпочтительным (атрибут WEIGHT - это локальный атрибут, впервые появился на маршрутизаторах Cisco ).
  3. При равном весе сравниваются атрибуты локального предпочтения LOCAL_PREFERENCE. Опять же, чем больше LOCAL_PREFERENCE, тем "лучше" маршрут.
  4. При равном LOCAL_PREFERENCE сравниваются AS_PATH. Чем AS_PATH короче - тем лучше.
  5. Если AS_PATH равны, то сравнивается ORIGIN. При этом IGP лучше EGP, а EGP лучше INCOMPLETE.
  6. При равных ORIGIN сравниваются атрибуты MED. Чем меньше MED - тем лучше маршрут.
  7. Если MED равны, то eBGP маршруты лучше iBGP.
  8. Если все еще наблюдается равенство, то выбирается маршрут с путем, кратчайшим по отношению к NEXT_HOP.
  9. И уж как последняя надежда - сравнение атрибутов ROUTER_ID. ROUTER_ID - это уникальный ID маршрутизатора (чаще всего берется ip с интерфейса обратной петли). Чем меньше - тем лучше.
  10. Но даже если по ROUTER_ID не удалось принять решение, то выбирается тот маршрут, BGP-сессия с которым на текущий момент длится дольше.

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

  1. AS_PATH предназначен для избежания петель маршрутизации. Делается это очень просто - если в AS_PATH принятого маршрута есть наша AS - маршрут игнорируется.
  2. Внутри AS, для обеспечения связности между всеми маршрутизаторами, входящими в эту AS и работающих по протоколу BGP необходимо иметь iBGP сессии, то есть каждый маршрутизатор внутри AS должен быть логически связан с другими.

Для понимания процесса приведем несколько примеров настройки протокола BGP. Условия: есть AS , в ней 3 маршрутизатора. Один из них R1 - соединен с с аплинком, а два других (R2 и R3) с R1 и между собой.

Изображение:bgp_1.png

R1:

! включаем поддержку bgp. NN - это номер Вашей AS, для примера - 10 router bgp NN ! отключаем синхронизацию с IGP no synchronization ! указываем какие сети анонсировать ! формат network сеть mask маска опции ! стоит отметить, что сеть анонсируется только при наличии ее в ! таблице маршрутизации network 172.16.1.0 mask 255.255.255.0 ! описываем соседей. Формат neighbor адрес_bgp_соседа опции ! Аплинк ! опция remote-as указывает на AS соседа. neighbor 192.168.1.1 remote-as 1 ! Опция next-hop-self необходима при правильной установки атрибута NEXT_HOP ! при внутренних сетей соседями из других AS neighbor 192.168.1.1 next-hop-self ! сессии с маршрутизаторами из своей AS neighbor 192.168.2.2 remote-as 10 neighbor 192.168.3.2 remote-as 10

R2:

router bgp 10 no synchronization network 172.16.2.0 mask 255.255.255.0 neighbor 192.168.2.1 remote-as 10 neighbor 192.168.4.1 remote-as 10

R3:

router bgp 10 no synchronization network 172.16.3.0 mask 255.255.255.0 neighbor 192.168.3.1 remote-as 10 neighbor 192.168.4.2 remote-as 10

Стоит отметить, что каждый раз при изменении настроек соседей необходимо произвести сброс BGP-сессии. Делается это командой:

clear ip bgp ip_соседа

При этом процедура создания bgp сессии проходит заново. Если хотите сбросить все - вместо ip подставьте * .

Если изменения настроек соседей производятся "на живом человеке", то при изменении атрибутов маршрутов, коммунити, route-map, advertise-map, prefix-list, distribute-list и т.п., можно использовать "мягкий сброс" сессии, как входящей, так и исходящей:

- clear ip bgp soft out для случаев изменения наших анонсов - clear ip bgp soft in для случаев изменения нашей политики обработки маршрутов от соседа

Далее:

  • route-map, prefix-list .
  • LOCAL_PREFERENCE - управляем исходящим трафиком.
  • AS_PATH - управление входящим трафиком а также фильтрация.
  • COMMUNITY.
  • BGP Conditional Advertisement.
  • Конфедерации и отражатели маршрутов.
  • BGP в работе - разные полезные советы.

Глава 3 : Route-map, prefix-list

Как Вам несомненно известно, в протоколе BGP множество атрибутов, причем несущих самую разную информацию. Ими надо как-то управлять, причем управлять осмысленно. Одним из главных инструментов, служащих данной цели, являются так называемые "карты маршрутов" (route-map). С помощью них можно с высокой точностью управлять как входящими, так и исходящими атрибутами и анонсами протокола BGP.

Формат применение карты маршрутов к соседу:

neighbor x.x.x.x route-map имя_карты направление

имя_карты - это собственно имя карты маршрутов, под которым она фигурирует в конфигурации. Чаще всего дают названия, несущие некий смысловой характер. К примеру названием AS1234-in очень удобно назвать карту маршрутов, которая работает с входящими анонсами от AS1234.

направление - эта директива указывает на направление, в отношении которого примется карта маршрутов. Соответственно, in - карта маршрутов применяется к анонсами приходящим от данного соседа, out - карта маршрутов применяется к анонсами уходящим к данному соседу.

Непосредственно формат "карты маршрутов":

route-map название действие номер1

match критерий1 ... match критерийN set действие1 ... set действиеN

route-map название действие номер2

match критерий1 ... match критерийN set действие1 ... set действиеN

название - это опять же имя карты. действие - это действие, которое производится при совпадении анонса с критерием (или критериями) match. Может принимать значение permit (разрешить прохождение анонса) или deny (запретить прохождение анонса). В том случае, если анонс совпадает с критериями текущего номера карты маршрутов, его дальнейшая обработка не производится. Действие по умолчанию - deny. номер - это номер правила внутри карты, который регулирует порядок прохождения. То есть, иначе говоря, применение правил идет от правила с меньшей цифрой по возрастанию. Теперь давайте разберемся с критериями и действиями. В качестве критерия может выступать выражение, которое указывает какой атрибут анализировать и каким образом он должен "выглядеть".

К примеру, Вам необходимо "отловить" анонсы сети 192.168.0.0/23. Реализуется это следующим образом:

! сам критерий match ip address 1 ! ACL соот. данному критерию access-list 1 permit 192.168.0.0 0.0.1.255

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

А пока для иллюстрации карт маршрутов рассмотрим решение простенькой задачки: Есть у Вас сеть 172.16.1.0/24. Есть маршрутизаторы R1 и R2, и Вам необходимо чтобы трафик, связанный с этой сетью проходил через R2 (не "прожует" R1 трафика к этой сети). Пикантность ситуации добавляет тот факт, что R2 не понимает BGP (ну например, не роутер это, а L3-коммутатор без BGP). Ну с исходящим трафиком все просто: R2 - шлюз по умолчанию для сети 172.16.1.0/24, а для R2 шлюз по умолчанию некий вышестоящий роутер. А что-же делать с входящим трафиком? Можно ли неким образом рассказать BGP-соседям, что сеть то живет за R2 ? Можно. Для этого необходимо модифицировать атрибут NEXT_HOP таким образом, чтобы он указывал на R2. Для этого на R1 делается:


Изображение:Bgp 2.png

router bgp 10 no synchronization network 172.16.1.0 mask 255.255.255.0 neighbor 192.168.1.1 remote-as 1 neighbor 192.168.1.1 next-hop-self neighbor 192.168.1.1 route-map NET-TO-R2 out

access-list 10 permit 172.16.1.0 0.0.0.255

route-map NET-TO-R2 permit 10 match ip address 10 ! ключевое действие - объясняем bgp соседу, что трафик к сети 172.16.1.0 должен ! пройти через R2 set ip next-hop 192.168.1.3

! пропускаем другие анонсы без модификации route-map NET-TO-R2 permit 20

«Отлично», - скажете Вы, вот мы можем неплохо фильтровать анонсы, но ведь неудобно же работать с префиксами сетей. И будете правы - неудобно. Вот только мало кто работает с префиксами сетей с помощью карт маршрутов. Для этого существует специальный инструмент - списки префиксов (на "мове" prefix-list). С помощью данного инструмента можно изгаляться надо префиксами как Вам на душу положит. Причем как с входящими, так и исходящими.

Формат применение префиксов к соседу аналогичен карте маршрутов:

neighbor x.x.x.x prefix-list имя_префикс_листа направление

Думается мне, тут расшифровки не требуется. Само же описание списка префиксов выглядит следующим образом:

ip prefix-list имя_префикс_листа seq номер_правила_внутри_листа действие сеть ge начало_диапазона le конец_диапазона

С именем все понятно, разберемся с номером. В списке может быть несколько правил, и номер определяет какое правило будет применено ранее. Как и в картах маршрутов, правила с меньшими номерами будут "пройдены" раньше. Если при прохождении найдено совпадение - следующие правила не рассматриваются. Действие – те же сакраментальные permit или deny. Соответственно permit разрешает прохождение префикса, а deny - запрещает. Как всегда по умолчанию - запрет.

В качестве параметра сеть выступает интересующий префикс. Параметры "ge начало_диапазона" и "le конец_диапазона" являются необязательными и указывают на, соответственно, начало и конец диапазона масок префиксов. То есть ge NN срабатывает на префиксах, маска которых более NN, а le NN срабатывает на префиксах у которых маска меньше NN.

Звучит слегка диковато и для понимания нужен пример. Есть 2 аплинка .От аплинков мы должны получить префиксы, маска которых меньше или равна 23 (для экономии памяти маршрутизатора, причем сети аплинков принимаем без "обрезания") и не принимать маршруты по умолчанию (предположим они нам отдают full-view), а им анонсировать свои сети , но не мельче чем /23, и не анонсировать свой маршрут по умолчанию и свои серые сети.

  • Сеть аплинка 1 x1.y1.z1.w1/8
  • Сеть аплинка 2 x2.y2.z2.w2/10

Изображение:bgp_3.png


router bgp 10 no synchronization neighbor 1.2.3.1 remote-as 1 neighbor 1.2.3.1 next-hop-self neighbor 1.2.3.1 prefix-list UP1-in in neighbor 1.2.3.1 prefix-list UP-out out neighbor 1.1.3.1 remote-as 2 neighbor 1.1.3.1 next-hop-self neighbor 1.1.3.1 prefix-list UP2-in in neighbor 1.1.3.1 prefix-list UP-out out

! запрещаем анонсирование маршрута по умолчанию ip prefix-list UP-out seq 1 deny 0.0.0.0/0 ! убираем серые сети ip prefix-list UP-out seq 5 deny 10.0.0.0/8 le 32 ip prefix-list UP-out seq 10 deny 172.16.0.0/12 le 32 ip prefix-list UP-out seq 15 deny 192.168.0.0/16 le 32 ! Разрешаем все префиксы /23 и менее (то есть /23,22 и др будет пропущен, ! в то-же время /24 пойдет лесом). ip prefix-list UP-out seq 20 permit 0.0.0.0/0 le 23

! алинк1 ! запрещаем прием маршрута по умолчанию ip prefix-list UP1-in seq 1 deny 0.0.0.0/0 ! пропускаем сеть первого аплинка без "обрезания" ip prefix-list UP1-in seq 10 permit x1.y1.z1.w1/8 ge 9 ! Разрешаем все префиксы /23 и менее ip prefix-list UP1-in seq 20 permit 0.0.0.0/0 le 23

! алинк2 ! запрещаем прием маршрута по умолчанию ip prefix-list UP2-in seq 1 deny 0.0.0.0/0 ! пропускаем сеть второго аплинка без "обрезания" ip prefix-list UP2-in seq 10 permit x2.y2.z2.w2/10 ge 11 ! Разрешаем все префиксы /23 и менее ip prefix-list UP2-in seq 20 permit 0.0.0.0/0 le 23


Далее:

  • LOCAL_PREFERENCE - управляем исходящим трафиком.
  • AS_PATH - управление входящим трафиком а также фильтрация.
  • COMMUNITY.
  • BGP Conditional Advertisement.
  • Конфедерации и отражатели маршрутов.
  • BGP в работе - разные полезные советы.

Глава 4 : LOCAL PREFERENCE - управляем исходящим трафиком

После того, как мы изучили некоторые практические основы работы протокола BGP, настроили пиринг и даже вроде бы все заработало, пришло время перевести дух и немного поразмышлять. А думать есть о чем - адреса то мы получили, с аплинками /IX местечкового масштаба пиринг подняли. И вроде все хорошо. Кроме одного - трафик "ходит" совсем не так, как нам хотелось бы. Естественно, что такая практика совершенно неприемлема. Приступим к процессу приведения путей движения трафика к нужному нам виду. И начнем мы с самого простого - исходящего трафика. Для управления исходящим трафиком предназначен атрибут LOCAL_PREFERENCE. LOCAL_PREFERENCE - это атрибут, представляющий собой число из диапазона от 1 до 32768, которое характеризует степень предпочтения анонса. Чем больше LOCAL_PREFERENCE - тем более предпочтительным является анонс. То есть если, к примеру, у Вас 2 анонса, лучшим будет выбран тот, у кого LOCAL_PREFERENCE больше. Атрибут LOCAL_PREFERENCE передается между iBGP пирами, то есть является нетранзитивным.

Для иллюстрации того, каким образом с ним работать, приведу пример: У нас есть 2 аплинка , которые анонсируют нам некие свои сети и маршрут по умолчанию, и мы включены в один паритет. Задача:

  • трафик для сетей паритета должен уходить через паритет.
  • трафик для сетей аплинков должен уходить через соответствующего аплинка.
  • в качестве провайдера по умолчанию должен использоваться 1-й провайдер.

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

  • анонсы из IX - большой LOCAL_PREF, к примеру 500
  • анонсы сетей из провайдеров - LOCAL_PREF 400
  • анонс сети по умолчанию из аплинка 1 - LOCAL_PREF 300
  • анонс сети по умолчанию из аплинка 2 - LOCAL_PREF 200

Реализация на практике:

Изображение:bgp_4.png

router bgp 10 no synchronization ! описываем всех соседей и соот. привязываем фильтры neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 next-hop-self neighbor 1.1.1.1 route-map UP1-IN in neighbor 1.2.1.1 remote-as 2 neighbor 1.2.1.1 next-hop-self neighbor 1.2.1.1 route-map UP2-IN in neighbor 1.3.1.1 remote-as 3 neighbor 1.3.1.1 next-hop-self neighbor 1.3.1.1 route-map IX-in in

access-list 1 permit 0.0.0.0 0.0.0.0

! устанавливаем для всех анонсов из IX LOCAl_PREF 500 route-map IX-in permit 10 set local-preference 500

! устанавливаем для маршрута по умолчанию из UP 1 LOCAl_PREF 300 route-map UP1-IN permit 10 match ip address 1 set local-preference 300

! для сетей из UP 1 LOCAl_PREF 400 route-map UP1-IN permit 20 set local-preference 400

! устанавливаем для маршрута по умолчанию из UP 2 LOCAl_PREF 200 route-map UP2-IN permit 10 match ip address 1 set local-preference 200

! для сетей из UP 2 LOCAl_PREF 400 route-map UP2-IN permit 20 set local-preference 400


Далее:

  • AS_PATH - управление входящим трафиком а также фильтрация.
  • COMMUNITY.
  • BGP Conditional Advertisement.
  • Конфедерации и отражатели маршрутов.
  • BGP в работе - разные полезные советы.

Глава 5 : AS PATH - управление входящим трафиком а также фильтрация

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

Придется идти в обход и вспоминать атрибуты BGP. Как Вы несомненно знаете, одним из ключевых атрибутов, который используется при работе с анонсами, является атрибут AS_PATH, представляющий собой список AS, которые необходимо пересечь для достижения искомой сети. То есть, иначе говоря, чем короче AS_PATH, тем более предпочтителен маршрут. А чем длиннее - тем соответсвенно и "хуже". А раз так, спросите Вы, то нельзя ли неким образом, удлинить тот маршрут, который для Вас менее предпочтителен? Можно, и даже более того, в ряде случаев даже нужно. То, как это сделать будет показано чуть ниже. Кроме того, атрибут AS_PATH позволяет строить простые и удобные фильтры для фильтрации анонсов, главное удобство которых в том, что можно не строить больших выражений и учитывать множество префиксов.

Для начала приведем пример фильтрации анонсов с помощью AS_PATH. К примеру, Ваша AS соединена с нескольким аплинками (AS1 и AS2), включена в некий IX (AS3) и имеет несколько точек (AS5 и AS5) пиринга с соседями. Вам необходимо:

  1. Не допустить что-бы Ваша AS стала транзитной для вышестоящих провайдеров (иначе говоря что-бы ни при каких условиях трафик между AS1 и AS2 не попытался пройти через Вашу AS )
  2. Анонсировать в точку обмена трафика и своим соседям только свою AS.
  3. Принимать от соседей только их их собственные сети.

Реализация:

Изображение:bgp_5.png

router bgp 10 no synchronization ! описываем всех соседей и соот. привязываем фильтры neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 next-hop-self neighbor 1.1.1.1 filter-list 10 out neighbor 1.2.1.1 remote-as 2 neighbor 1.2.1.1 next-hop-self neighbor 1.2.1.1 filter-list 10 out neighbor 1.3.1.1 remote-as 3 neighbor 1.3.1.1 next-hop-self neighbor 1.3.1.1 filter-list 10 out neighbor 1.4.1.1 remote-as 4 neighbor 1.4.1.1 next-hop-self neighbor 1.4.1.1 filter-list 10 out neighbor 1.4.1.1 filter-list 15 in neighbor 1.5.1.1 remote-as 5 neighbor 1.5.1.1 next-hop-self neighbor 1.5.1.1 filter-list 10 out neighbor 1.5.1.1 filter-list 20 in

! Самое главное - сами фильтры ip as-path access-list 10 permit ^$ ip as-path access-list 15 permit ^4$ ip as-path access-list 20 permit ^5$

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

. Все символы * Все выражения + 1 и более выражений ? 0 и более выражений ^ Начало строки а также в качестве символа инвертирования внутри диапазона $ Конец строки _ Соответствует точке(.), фигурным и обычным скобкам ({} и () ), начало и конец строки а также пробел [диапазон] Определяет диапазон символов в выражении - разделяет конечные точки диапазона

Для того, чтобы не внося изменения в настройки оборудования посмотреть какие анонсы подпадают под созданное Вами регулярное выражение, можно воспользоваться командой: sh ip bgp regexp выражение

Фильтры атрибута AS_PATH на основе регулярных выражений можно также использовать и в картах маршрутов. Та же самая задача, реализованная с применением карт маршрутов (пояснительного рисунка, мне думается, не требуется - принцип абсолютно аналогичен приведенному выше примеру):

router bgp 10 no synchronization ! описываем всех соседей и соот. привязываем фильтры neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 next-hop-self neighbor 1.1.1.1 route-map PEER-out out neighbor 1.2.1.1 remote-as 2 neighbor 1.2.1.1 next-hop-self neighbor 1.2.1.1 route-map PEER-out out neighbor 1.3.1.1 remote-as 3 neighbor 1.3.1.1 next-hop-self neighbor 1.3.1.1 route-map PEER-out out neighbor 1.4.1.1 remote-as 4 neighbor 1.4.1.1 next-hop-self neighbor 1.4.1.1 route-map PEER-out out neighbor 1.4.1.1 route-map PEER4-in in neighbor 1.5.1.1 remote-as 5 neighbor 1.5.1.1 next-hop-self neighbor 1.5.1.1 route-map PEER-out out neighbor 1.5.1.1 route-map PEER5-in in

! Самое главное - сами фильтры ip as-path access-list 10 permit ^$ ip as-path access-list 15 permit ^4$ ip as-path access-list 20 permit ^5$ route-map PEER-out permit 10 match as-path 10 route-map PEER4-in permit 10 match as-path 15 route-map PEER5-in permit 10 match as-path 20

После того, как освоены принципы фильтрации, перейдем к главному - управлению входящим трафиком на основе принципа искусственного удлинения AS_PATH.

К примеру, Ваша AS (10), которая соединена с нескольким аплинками (AS1 и AS2). У аплинка 1 канал большой пропускной способности довольно надежен, но оплата по трафику, а у второго аплинка канал не всегда надежен, зато трафик не считается, а продается полосой.

У Вас есть 2 сети:

  • 10.0.0.0/22 - обычные клиенты
  • 192.168.0.0/23 - VIP клиенты.

Вы хотите, что-бы в стандартной ситуации клиенты получали входящий трафик через провайдера 2, а VIP клиенты через провайдера 1. Решается это следующим образом:

Изображение:bgp_6.png

router bgp 10 no synchronization network 10.0.0.0 mask 255.255.252.0 network 192.168.0.0 mask 255.255.254.0 neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 next-hop-self neighbor 1.1.1.1 route-map GW1-out out neighbor 1.2.1.1 remote-as 2 neighbor 1.2.1.1 next-hop-self neighbor 1.2.1.1 route-map GW2-out out

access-list 10 permit 10.0.0.0 0.0.3.255 access-list 20 permit 192.168.0.0 0.0.1.255

route-map GW1-out permit 10 match ip address 10 ! для соот. сети удлиняем AS_PATH set as-path prepend 10 10 10 10 route-map GW1-out permit 20

route-map GW2-out permit 10 match ip address 20 ! для соот. сети удлиняем AS_PATH set as-path prepend 10 10 10 10 route-map GW2-out permit 20


[ править]

Далее:

  • COMMUNITY.
  • BGP Conditional Advertisement.
  • Конфедерации и отражатели маршрутов.
  • BGP в работе - разные полезные советы.

Глава 6 : COMMUNITY

Итак BGP настроен как надо, и все довольны тем, как хорошо все работает. Но счастье вечным не бывает - добавляются новые паритеты и аплинки, появляются клиенты со своими AS, Вы расширяетесь и получаете новые сети. Вобщем, жизнь бьет ключом и, как это увы часто бывает, по голове. Потому что эти изменения требуют от Вас с каждым днем все большего напряжения памяти, так как Клиента 1 анонсировать в часть аплинков не надо, клиента 2 вообще надо анонсировать только с большим AS PREPEND, клиент 3 вообще сам хочет управлять тем, как его анонсировать (с препендами или без), часть собственных сетей надо анонсировать через один канал с "препендами" в другой без них. А учитывая "размножение" устройств с поддержкой BGP в сети, процесс усложнения управлением этого хозяйства подобен сходу снежной лавине. Что же каcается понимания как ЭТО работает (читай сопровождения) - картина грустная.

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

Первое, что приходит на ум, поступить с анонсами так, как поступают с пакетами при работе с QoS - промаркировать, а затем работать только с маркерами (или метками) . Но можно ли таким же образом поступить с анонсами сетей в протоколе BGP ? Можно. Осуществляется сие действо с помощью применения специального атрибута, именуемого COMMUNITY. COMMUNITY - это необязательный транзитивный атрибут. Он имеет переменную длину и состоит из совокупности четырех байтовых значений из диапазона 0x00000000 до 0x0000FFFF (разве не по 0xFFFF0000???) (диапазон с 0xFFFF0000 по 0xFFFFFFFF зарезервирован для спец. целей ).

По умолчанию BGP не посылает и не принимает данный атрибут. Для того, чтобы включить возможность посылки и приема данного атрибута следует указать в свойствах нейбора send-community. К примеру:

neighbor 1.2.3.4 send-community

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

На практике community принято использовать в виде: XX:YY где XX - это номер AS, а YY - это 2-х байтное число, которое вы можете назначать по своему усмотрению. К примеру, значение community равное 1234:1 традиционно означает, что в AS1234 имеется группа анонсов и индексом 1 или как говорят "сообщество" N в AS 1234 которому соответствует значения community 1234:1.

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

Рассмотрим пример установки метки 1234:3456 на анонсы клиента (AS 3456).

router bgp 1234 no synchronization neighbor 2.3.4.1 remote-as 3456 neighbor 2.3.4.1 send-community neighbor 2.3.4.1 next-hop-self neighbor 2.3.4.1 route-map AS3456-In in

! Включаем поддержку нового формата community ip bgp-community new-format

route-map AS3456-In permit 10 set community 1234:3456

Таким образом, все анонсы клиента полученные от нейбора 2.3.4.1 получат метку. Но это пока малоинтересно, просто потому, что этой меткой надо воспользоваться, то есть на ее основе произвести некие действия. Для примера возьмем ситуацию, когда Вы входите в некий IX, анонсировать в который своих клиентов строго запрещено. Ваши анонсы имеют метку 1234:1-1234:9 Исходя из данного соображения мы строим исходящие фильтры:

Изображение:bgp_7.png

router bgp 1234 no synchronization neighbor 2.1.4.1 remote-as 1024 neighbor 2.1.4.1 send-community neighbor 2.1.4.1 next-hop-self neighbor 2.1.4.1 route-map AS1024-Out out

ip bgp-community new-format

route-map AS1024-Out permit 10 match community MY_NET

ip community-list expanded MY_NET permit 1234:[1-9]

Ключевым в данном случае является ip community-list. Данный лист имеет следующий формат: ip community-list {standard | expanded} Имя листа {permit | deny} { номер community | регулярное выражение } Регулярное выражение используется в листе расширенного формата (expanded). Формат регулярного выражения соответствует традициям компании Сisco. Стандартным действием является deny. К примеру рассмотрим пример такого рода листов:

ip community-list expanded TEST deny _1234:10_ ip community-list expanded TEST permit _1234:.*_

Данный лист запрещает прохождение анонсов, в которых содержится community 1234:10, но разрешает прохождение анонсов с community, в которых содержится 1234:XX.

А на закуску я проиллюстрирую пример того, каким образом можно дать возможность клиенту автоматически управлять своими анонсами, то есть чтобы сам клиент решал анонсировать его нормально, с препендами, или вообще не анонсировать. Для этого Вам необходимо разработать "политику сообществ", то есть указать какие community для чего служат. К примеру:

Изображение:bgp_8.png

1234:10 - анонсы с таким community нормально анонсируются всюду (кроме есст. "закрытых" IX) 1234:11 - анонсы с таким community анонсируются аплинком с препендом 1234:12 - анонсы с таким community не анонсируются аплинкам.

И в зависимости от того, какой community имеют анонсы клиента, Вы и соответствующим образом работаете с этими анонсами.

Практически это будет выглядеть следующим образом: Сессия с клиентом:

router bgp 1234 no synchronization neighbor 2.3.4.1 remote-as 3456 neighbor 2.3.4.1 send-community neighbor 2.3.4.1 next-hop-self neighbor 2.3.4.1 route-map AS3456-In in

ip bgp-community new-format

ip community-list expanded NORMAL permit _1234:10_ ip community-list expanded PREPEND permit _1234:11_ ip community-list expanded INTERNAL permit _1234:12_

route-map AS3456-In permit 10 match community NORMAL ! переназначение community необходима для того, что-бы клиент не злоупотреблял ! доверием и не начал пытаться вложить неположенные community set community 1234:10

route-map AS3456-In permit 15 match community PREPEND set community 1234:11

route-map AS3456-In permit 20 match community INTERNAL set community 1234:12

route-map AS3456-In permit 25 ! помечаем все остальное стандартным community set community 1234:10

Сессия с аплинком:

router bgp 1234 no synchronization neighbor 2.1.1.1 remote-as 555 neighbor 2.1.1.1 next-hop-self neighbor 2.1.1.1 send-community neighbor 2.1.1.1 route-map AS555-Out out

ip bgp-community new-format

ip community-list expanded NORMAL permit _1234:10_ ip community-list expanded PREPEND permit _1234:11_ ip community-list expanded INTERNAL permit _1234:12_

route-map AS555-Out permit 10 match community NORMAL ! удаляем из анонсов аплинку наш community set comm-list NORMAL delete ! добавляем в анонс community, который указывает аплинку на нормальное ! анонсирование данных анонсов (если аплинк разрешает Вам это делать) set community 555:1 additive

route-map AS555-Out permit 15 match community PREPEND set as-path prepend 1234 1234 1234 1234 ! можно также воспользоваться директивой ! set as-path prepend last-as 4 ! которая добавит в значению AS_PATH 4 раза номер последней AS set comm-list PREPEND delete ! добавляем в анонс community, который указывает аплинку на нормальное ! анонсирование данных анонсов (если аплинк разрешает Вам это делать) set community 555:2 additive

route-map AS555-Out deny 20 match community INTERNAL

route-map AS555-Out permit 30

При правильном проектировании community становятся незаменимым инструментом по управлению анонсами, который позволяет довольно точно и главное наглядно управлять анонсами BGP.

И в качестве завершающего штриха стоит упомянуть про специальные значения community :

  • no-export - анонсы с таким значением community не анонсируются нейборам, чей номер AS отличается от номера AS роутера.
  • local-as - анонсы с таким значением community анонсируются нейборам не только из той-же AS, в которой находится роутер, но и анонсируются соседям по конфедерации. За пределы конфедерации анонсы не уходят.
  • no-advertise - анонсы с таким значением community не анонсируются вообще никуда.


Далее:

  • BGP Conditional Advertisement.
  • Конфедерации и отражатели маршрутов.
  • BGP в работе - разные полезные советы.

Глава 7 : BGP Conditional Advertisement

Клиенты бывают разные. Разные как в смысле характера, так и в смысле платежеспособности. Вот только если "жирный" клиент хочет услугу на своих условиях, «продажники», увы, сперва подписывают а потом думают. А разбираться приходится нам, технарям. Ну да в сторону лирику - перейдем к сути задачи.

А задача заключается в том, что есть у Вас "жирный" клиент, который покупает большую полосу и платит он (по меркам Вашей конторы) вагон и малую телегу денег. Но хочет этот клиент, чтобы Вы обеспечивали железобетонную связь с сетью. До включения этого клиента у Вас было 2 аплинка и в принципе их надежность Вас устраивала. Однако иногда (редко, но все-же) наступал всеобщая катастрофа - падали оба. Ладно, нашли Вы третий аплинк. Независимый и с хорошим качеством, но цены на трафик заставят покраснеть любого. То есть, иначе говоря, канал от него должен использоваться только сетью VIP клиента, и только в случае если через первые 2 аплинка "умерли".

Первое, что приходит в голову - анонсировать в 3-й аплинк только сеть с VIP-клиентом (как минимум /24 , а желательно /23) и очень сильно удлинить AS_PATH для этого префикса. Это сделать конечно можно, но где гарантия что аплинк вообще будет смотреть (Вы для него-то клиент) на Ваш AS_PATH ? Поставит большой LOCAl_PREF для анонсов из Вашей сети и поминай как звали - поползет трафик по дорогому каналу как миленький.

С другой стороны, городить "костыли" типа скриптов, которые смотрят анонсы и, в случае необходимости, меняют настройки сессии с 3-м аплинком, не хочется. Тем более вставать ночью. Как-же сделать все в автоматическом режиме без "костылей" ?

Для решения этой задачи необходимо воспользоваться метода BGP Conditional Advertisement Feature. Суть данного метода состоит в том, что если в таблице маршрутизации нет некой сети, то мы начинаем анонсировать в третьего аплинка сеть VIP-клиента. От 2-х первых аплинков мы получаем full-view, а от третьего - только маршрут по умолчанию.

Изображение:bgp_10.png

router bgp 10 ! /...кусь../ ! neighbor 3.2.3.1 remote-as 3 ! ключевой момент. Если нет совпадений в карте, указанной в директиве non-exist-map ! то в "работу идет" карта из IF-NET neighbor 3.2.3.1 advertise-map IF-NET non-exist-map IF-NO-NET neighbor 3.2.3.1 prefix-list UP3-out out ! /...кусь../

! сеть клиента access-list 1 permit x1.y1.z1.w1 0.0.1.255 ! некая показательная сеть /19 , при пропадании которой мы анонсируем клиента ! в 3-го аплинка access-list 2 permit x2.y2.z2.w2 0.0.31.255 ! route-map IF-NO-NET permit 10 match ip address 2 ! route-map IF-NET permit 10 match ip address 1

! ограничиваем анонсы в 3-й аплинк. ip prefix-list UP3-out seq 1 permit x1.y1.z1.w1/23

И мы получим, что при проблемах с 2-мя аплинками (например пьяный варяг рубанул общую оптику) сеть с VIP-клиентом будет получать сервис через 3-го аплинка.

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


[ править]

Далее:

  • Конфедерации и отражатели маршрутов.
  • BGP в работе - разные полезные советы.

Глава 8 : Конфедерации и отражатели маршрутов

Вернемся к вопросу, поднятому в прошлой главе "Счастье вечным не бывает". Растущая с каждым днем сеть вносит в Вашу жизнь некое подсознательное беспокойство - плохой сон, аппетит и др. Все чаще перед Вы говорите себе: "Так жить нельзя". В чем же причина ? А причина в том, что в обычном виде, поскольку внутри Вашей AS приходится на каждом маршрутизаторе поддерживать N-1 (N - число BGP маршрутизаторов в AS) iBGP-сессий, а общее число iBGP сессий составляет N(N-1) очень трудно сопровождать такого рода "конструкцию" равно как и диагностировать проблемы.

Изображение: bgp_11.png

К примеру у Вас в AS есть 20 маршрутизаторов, надо добавить 21-й. Правда грустно заходить на каждый из 20-ти и добавлять? А если где-то промахнешься, забудешь добавить и т.д. - нарушится целость AS, со всеми вытекающими (такими как одна сеть не "видит" другую и др.)

Для решения такого рода проблем существует 2 способа:

  1. Конфедерации
  2. Отражатели маршрутов.

Для начала рассмотрим концепцию BGP-конфедерации. В основу данной концепции положена идея разбиения большой AS на множество мелких "серых" AS. Взаимодействие между этими "мелкими" AS будет происходить по протоколу EBGP. То есть, к примеру, у нас 20 маршрутизаторов (2 из которых связаны с аплинками, паритетами, то есть с другими AS ) в AS 10. Мы разбиваем AS 10 на 3 конфедерации - 65001,65002,65003 взаимодействие между которыми происходит по eBGP.

Примеры настроек маршрутизаторов: R1 - маршрутизатор в AS 65001, который кроме того поддерживает связь с аплинком (AS 20) с маршрутизаторами иных конфедераций и с маршрутизаторами своей конфедерации:

Изображение: bgp_12.png

router bgp 65001 no synchronization ! наша AS - 10, ей должен соот. номер confederation identifier bgp confederation identifier 10 bgp confederation peers 65001 ! сессия с аплинком neighbor 1.2.3.1 remote-as 20 neighbor 1.2.3.1 next-hop-self ! ключевой момент - удаляем серые AS из AS_PATH анонсов, отправляемых в ! сторону соседа с реальной AS neighbor 1.2.3.1 remove-private-as ! сессия с роутером из другой конфедерации. neighbor 2.2.3.1 remote-as 65002 neighbor 2.2.3.1 next-hop-self ! сессия с роутером из нашей конфедерации. neighbor 2.3.9.1 remote-as 65001

R2 - роутер внутри серой AS.

router bgp 65001 no synchronization bgp confederation identifier 10 bgp confederation peers 65001 ! сессии с роутерами нашей конфедерации neighbor 2.2.9.2 remote-as 65001

........ neighbor 2.3.9.N remote-as 65001 ! если нужно - сессия с роутером из другой конфедерации. neighbor 2.2.3.2 remote-as 65003 neighbor 2.2.3.2 next-hop-self

Таким образом, основным отличием является применение директив bgp confederation identifierб bgp confederation peers и remove-private-as. Директива bgp confederation peers для сохранения нетранзитивных атрибутов (таких как LOCAL_PREF) для передачи через сеанс EBGP внутри сети с конфедерациями. Для роутеров внутри вашей AS, не связанных напрямую с реальными AS директива remove-private-as не применяется.

Как говорится дешево и сердито. Разбив сеть на конфедерации, мы значительно уменьшаем кол-во iBGP-сессий и получаем относительно (того, кто проектировал) понятную структуру. Особый смысл обретает понятие конфедерации в случае приобретения нами провайдера или резким расширение сети. В этом случае соответствующие участки просто включаются как отдельные "серые" AS и нам не приходится морочить голову с их с долгой интеграцией в нашу сеть.

Однако у конфедераций есть довольно существенный недостаток - если уже существует немалая сеть, то относительно трудно перейти к использованию конфедераций.

С другой стороны, кроме концепции конфедерации для решения проблем работы BGP в больших AS существует концепция "отражателей маршрутов". Суть концепции отражателей маршрутов заключается в том, что внутри AS, исходя из физической топологии, выявляются специальные маршрутизаторы (которые и называются отражателями маршрутов), которые получив анонс по протоколу iBGP, не просто заносят его к себе в таблицу маршрутизации а еще и передают их другим маршрутизаторам. Таким образом в сети, где работают отражатели маршрутов обычным маршрутизаторам нужно поддерживать iBGP-сессию только с отражателем маршрутов. Сами же отражатели соответственно поддерживают iBGP-сессии с другими отражателями и клиентами.

Для примера возьмем уже пригодившийся пример с AS. Исходя из топологии мы выбрали 3 отражателя маршрутов, настройка которых будет следующей:

Изображение: bgp_13.png

router bgp 10 no synchronization / кусь / ! ключевой момент - сессия с клиентами neighbor 2.2.3.1 remote-as 10 neighbor 2.2.3.1 route-reflector-client ....................... neighbor 2.2.3.N remote-as 10 neighbor 2.2.3.N route-reflector-client ! сессии с другими отражателем маршрутов ! тут - все аналогично обычному iBGP neighbor 2.5.3.1 remote-as 10 neighbor 2.5.4.1 remote-as 10

Для клиента не измениться ничего:

router bgp 10 no synchronization ! ключевой момент - сессия с клиентами neighbor 2.2.3.2 remote-as 10

Все это конечно хорошо, скажите Вы мне, но как-же избежать петель маршрутизации при использовании отражателей ? Для избежания образования петель при использовании отражателей используются атрибуты ORIGINATOR_ID и CLUSTER_LIST. Атрибут ORIGINATOR_ID в префиксе - это ROUTER_ID того маршрутизатора, который этот самый маршрут генерировал. И если полученный префикс имеет ORIGINATOR_ID равный ROUTER_ID нашего маршрутизатора - префикс отвергается.

Теперь разберемся с CLUSTER_LIST. Но для начала опять же представим нашу большую AS. Если AS большая, то в ней так или иначе немало и отражателей маршрутов. И эти отражатели имеют своих клиентов. Так вот отражатели вместе с клиентами представляют собой кластер отражателей маршрутов. Каждый кластер идентифицирует уникально число - CLUSTER_ID. Так вот - CLUSTER_LIST - это список тех CLUSTER_ID, через которых прошел префикс. И если маршрутизатор обнаруживает внутри CLUSTER_LIST свой CLUSTER_ID - маршрут игнорируется. Для активации данной возможности, необходимо разбить на некие логические участки причем сделать это с учетом имеющихся отражателей. Как уже говорилось отражатели вместе с клиентами будут составлять кластер. Затем каждому кластеру назначить некий id (число) и в настройках отражателей указать его с помощью команды: bgp cluster-id XX

К примеру если у Вас получается 3 кластера, то отражатели первого:

bgp cluster-id 100

второго:

bgp cluster-id 200

третьего:

bgp cluster-id 300

Что же лучше отражатели или конфедерации ? К сожалению, на этот вопрос однозначного ответа нет. Надо "смотреть по месту", то есть учитывать конкретные условия и требования. Иногда эти 2 подхода даже можно комбинировать - к примеру очень большую AS разбиваем на конфедерации, а внутри них - использовать отражатели.


[ править]

Далее:

  • BGP в работе - разные полезные советы.

Глава 9 : BGP в работе - разные полезные советы

Итак мы почти дошли до конца. Но почти - не значит совсем. На "десерт" мы рассмотрим некоторые необязательные, но очень важные моменты работы протокола BGP.

И начнем с агрегации. Давайте подставим, что у нас есть 2 сети - 192.168.0.0/24 и 192.168.1.0/24. А вспомним любимый нами CIDR и запишем эти сети одной сетью - 192.168.0.0/23. Иначе говоря, маленькие ручейки стекаются в большие реки, то есть теоретически чем более приближен маршрутизатор к глобальный магистралям, тем менее длинными префиксами он оперирует. На практике (по многим причинам ) это правило выполняется не всегда. Однако, так или иначе разобраться в вопросе необходимо - как минимум потому, что серьезный оператор не будет заниматься анонсированием сотни префиксов /24 (опять же в общем случае) , если их можно объединить в 2-3 префикса.

Итак главная задача агрегации - это сократить число префиксов и тем самым упростить диагностику проблем и повысить надежность. Да-да, именно надежность. Просто потому, что многие операторы в целях экономии аппаратных ресурсов (к слову, в примере Выше я также использовал данный прием) принимают только префиксы /23 и меньше ..... /24 они не принимают. То есть, иначе говоря, анонсируя только /24 Вы рискуете столкнуться с тем, что некоторая часть сети Вас видеть не будет. Кроме того, проблемы внутри сети при анонсировании отдельных префиксов могут быть причиной блокировки отдельных маршрутов Вашей сети как "проблемных" (о том что это такое - ниже).

Агрегация может осуществляются несколькими способами способами:

1)С помощью статических маршрутов. Как это не странно - но это так. Для понимания сути механизма, приведем пример. Вам выдана сеть 192.168.0.0/22. Естественно внутри сети Вы ее делите на необходимое к-во сетей. А анонсировать надо /22. В таком случае указанная сеть привязывается к интерфейсу Null0 и прописывается данную сеть в директиву network. Ну и само собой аплинкам с помощью префикс листов (я думаю Вы сами справитесь с построением соот. листа) анонсируем только эту сеть.

router bgp 10 no synchronization ! анонсируем объединенную сеть с помощью протокола bgp network 192.168.0.0 mask 255.255.252.0 ! сессия с аплинком1 neighbor 1.2.3.1 remote-as 20 neighbor 1.2.3.1 next-hop-self ! сессия с аплинком2 neighbor 1.1.3.1 remote-as 30 neighbor 1.1.3.1 next-hop-self ! а забываем, что bgp не анонсирует абы что, а анонсирует только те префиксы, ! которые есть в таблице маршрутизации. Мы соот. и привязываем объединенный ! префикс к интерфейсу Null0. ip route 192.168.0.0 255.255.252.0 Null0


2)Использование специальной директивы (рис. 14, 15, 16).


Изображение: bgp_14.png


Изображение: bgp_15.png


Изображение: bgp_16.png


Для управления объединением сетей используется директива aggregate-address. Синтаксис данной директивы имеет следующий вид.

aggregate-address сеть маска [as-set] [summary only] [suppress-map карта1] [attribute-map карта2 ]

Для понимания - приведем примеры: 1) просто

aggregate-address 192.168.0.0 255.255.252.0

Данная директива просто генерирует объединенный маршрут, но при этом не трогает более мелкие. То есть кроме /22 будут анонсироваться префиксы /23, /24 и др.

2) если мы добавим summary only - будет анонсироваться только объединенный маршрут, то есть /22.

Для понимания зачем необходимы as-set рассмотрим пример:

У Вас есть некая сеть - к примеру несколько префиксов /23 и /22. И есть клиент со своей AS, у которого тоже некие сети, но более мелкие - /24, к примеру. Если же некие Ваши префиксы и клиента объединить в один - получится красивый префикс /21. Но при просто объединении префиксов атрибуты теряются и, главное, сбрасывается AS_PATH. То есть префикс /21 будет выглядеть как сеть целиком из Вашей AS. Получается очень некрасиво: за такие фокусы можно и по шее получить ;) . Так вот, для того, что-бы в объединенном маршруте сохранялись такая Важная информация, как AS_PATH, то и необходимо добавлять в директиву aggregate-address опцию as-set. И при применении такого рода директивы, если часть маршрутов прошли через некую (или некие) AS, то этот список добавляется к AS_PATH в виде {список пройденных AS}. Вспоминая пример, AS_PATH для объединенного маршрута будет выглядеть так:

10 {20} i, где 20 - номер AS клиента.

3) Опция suppress-map предназначена для того, что-бы четко определить: какие префиксы, кроме объединенного, подлежат анонсированию. Соответствующая карта строится по общепринятым правилам.

4) Опция attribute-map указываем на карту, которая изменяет атрибуты уже объединенного маршрута.

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

Второй и главной темой для обсуждения нашего "десерта", стоит рассмотреть вопрос обеспечения стабильности протокола bgp.

Изображение: bgp_17.png

К примеру есть некая сеть, которая имеет 2 канала выхода в глобальную сеть. Все бы хорошо, но один из этих каналов время от времени начинает "плющить как радиорелейку при восходе солнца" (знающие поймут). То упадет, то поднимется, и так далее. А поскольку путь через "плохой" канал наиболее короток, то пока по глобальной сети распространится информация о его непригодности, то все пакеты будут потеряны. Кроме того, каждая такая перестройка "кушает" ресурсы маршрутизаторов. Неплохо бы, скажете Вы, неким образом в автоматическом режиме отлавливать такого рода жуков и на время помещать их в некий "черный список": вдруг хозяин AS починит за это время канал. И еще лучше - при стабилизации маршрута исключать их из "черного списка". Можно ли так сделать ?

Можно, и делается это с помощью механизма "разгрузки маршрутов". Его суть сводится к простой схеме: каждому маршруту присваивается специальный индекс "ненадежности", по англицки – penalty, и, начиная с некоторого значения penalty, маршрут просто блокируется. Расчет penalty довольно прост: у нас есть некий промежуток времени, и если в его течении произойдет пропадание/возвращение маршрута, к значению penalty добавляется штрафной бал. Если за интервал времени проблем не было - штрафные балы маршруту снимаются. Как только сумма балов превысит разумные пределы, маршрут блокируется (то есть не принимает участие в принятии решений ) на указанное время. Блокировка может быть снята раньше, если сумма штрафных балов снизится до значения, меньшего спец. определенной цифре.

Перейдем к примеру. Нам необходимо защитить свою сеть от "зловредных" маршрутов. Для этого служить директива bgp dampening. формат: bgp dampening [таймер1 порог_восстановления порог_отбрасывания время_блокировки] [route-map имя_карты ]

Для начала рассмотрим первый случай - для всех сетей глобальный настройки, то есть: bgp dampening [таймер1 порог_восстановления порог_отбрасывания время_блокировки]

таймер1 - это у помянутый Выше промежуток времени. От 1-й до 45 минут. По умолчанию - 15 минут. порог_восстановления - это порог штрафных балов, при значении ниже которого маршрут вновь становиться активным. Может принимать значения от 1 до 20000. По умолчанию - 750. порог_отбрасывания - этот порог штрафных балов, при достижении которого маршрут блокируется. Может принимать значения от 1 до 20000. По умолчанию - 2000. время_блокировки - максимально время блокировки маршрута. От 1-й до 255 минут. По умолчанию - рассчитывается по формуле: таймер1x4.

К примеру, Вы хотите интервалом измерения сделать 10 минут, порог отбрасывания 5000, а порог восстановления - 2000.

bgp dampening 10 2000 5000 40

Теперь вспомним, что под одну гребенку всех грести все-же не стоит. Неплохо бы для разных сетей устанавливать разные пороги.

Для этого и служит второй вариант - bgp dampening route-map имя_карты В качестве примера - для одних сетей устанавливаем указанные Выше параметры, а для всех остальных более жесткие - 10 500 1000 40.

router bgp 10 no synchronization bgp dampening route-map SET_DUMP

! для сетей, полученных от аплинков - первые значения route-map SET_DUMP permit 1 match community UPLINK set dampening 10 2000 5000 40

! для остальных сетей route-map SET_DUMP permit 5 set dampening 10 500 1000 40

Теперь вернемся к первой главе и вспомним о том, как мы меняли параметры BGP-сессии и после этого сбрасывали ее "жестким" (то есть сбросом TCP сеанса) образом. Тогда это было приемлемо. Теперь же у нас большая сеть и мы не можем позволить себе роскошь при каждом чихе сбрасывать BGP сессию. Для того, чтобы менять параметры BGP-сессии, и при этом сохранять стабильность сети, необходимо воспользоваться механизмом мягкой перестройки. Для мягкой перестройки параметров, связанных с исходящими параметрами, необходимо воспользоваться командой:

clear ip bgp IP_соседа soft out

Для мягкой перестройки входящих параметров следует воспользоваться командой:

clear ip bgp IP_соседа soft in

И в качестве последнего аккорда рассмотрим понятие "группы узлов" и, главное, зачем это нужно. В ряде случаев, многие BGP-сессии имеют похожие параметры и очень не хочется по 10 раз вводить одно и тоже (да и попробуй потом этом зоопарке разберись). Для того, чтобы не напрягаться как при настройке так и при разборе конфигурации, и применяют группы узлов.

Синтаксис:

neighbor ИМЯ_ГРУППЫ peer-group neighbor ИМЯ_ГРУППЫ общая опция 1 ... neighbor ИМЯ_ГРУППЫ общая опция N

neighbor X.Y.Z.W peer-group ИМЯ_ГРУППЫ

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

Реализация:

neighbor PE peer-group neighbor PE remote-as 10 neighbor PE route-reflector-client neighbor PE send-community neighbor PE route-map AS10-PE-In in

А описание самой bgp сессии с этой группой сведется к:

neighbor 1.2.3.1 peer-group PE .......... neighbor 1.2.3.N peer-group PE

Глава 10 : Главное - это абонент

Каждый народ заслуживает таких
провайдеров, которых оплачивает.

Домашние сети и Ethernet-провайдинг явление во многом уникальное. Самим своим существованием подобные предприятия обязаны экономическому казусу. А точнее - резкому (и в общем неожиданному) падению стоимости оборудования из сектора SOHO/Enterprise (домашний, небольшой и средний офис).

В конце 90-х выяснилось, что оборудование, пригодное для создания районной и, тем более, внутридомовой разводки Ethernet стоит невообразимо дешево (по телекоммуникационным меркам, разумеется). Классические технологии провайдеров того времени (xDSL, V35, E1, и т.п.) уступали по стоимости в десятки, а порой даже в сотни раз.

Это положение не осталось незамеченным любителями и небольшими активными фирмами. Их не остановил даже не совсем понятный правовой статус создаваемых сетей, сложности освоения новых технологий, и прочие риски, присущие принципиально новым проектам. Не зря еще в позапрошлом столетии писал Карл Маркс:
"Капитал боится отсутствия прибыли или слишком маленькой прибыли, как природа боится пустоты. Но раз имеется в наличии достаточная прибыль, капитал становится смелым. Обеспечьте 10 процентов, и капитал согласен на всякое применение, при 20 процентах он становится оживленным, при 50 процентах положительно готов сломать себе голову, при 100 процентах он попирает все человеческие законы, при 300 процентах нет такого преступления, на которое он бы не рискнул, хотя бы под страхом виселицы."

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

В результате незаметно, в течении 3-4 лет, Ethernet-провайдеры через свои сети подключили многие тысячи абонентов. И захватили во многих городах (включая Москву, и прочие крупные центры) более половины (а кое-где и до 90%) рынка домашних пользователей выделенных линий. Серьезно потеснив xDSL и DialUp.

Сейчас ценовая диспропорция Ethernet с другими технологиями постепенно выравнивается, да и владельцы телефонной инфраструктуры под давлением конкуренции начали принимать меры по "самоспасению". Но мощный первоначальный экономический импульс еще далеко не исчерпан. Сети продолжают расти едва ли не в геометрической прогрессии.

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


У провайдеров не так много источников доходов. Вернее сказать, он только один - платежи абонентов. Поэтому именно с них нужно начать рассмотрение всех экономических вопросов операторов связи вообще и Ethernet-провайдеров в частности.

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

Для начала несколько усредненных цифр по отчетам экспертного агентства J'son & Partners. В Москве порядка 3 миллионов домохозяйств, из них к концу 2004 года будет подключено к Интернет широкополосным каналом около 250 тысяч. И быстрый рост (до 80-90%) продолжится еще один год, и к 2006 году количество абонентов вырастет до 500 тысяч. Далее рост замедлится, но к 2010 году их количество достигнет 2 миллионов (если не вмешаются серьезные катаклизмы экономики или политики).

Отметим, что для других регионов России эти данные то же вполне применимы - разумеется с определенной временной поправкой.

То есть при таком быстром росте нельзя строить сеть с расчетом на сегодняшние 10% (5%, 15%) подключенных домохозяйств. Нужно рассчитывать на "завтрашние" (заметно более выгодные) финансовые показатели по 20-ти процентам подключенных квартир. И иметь в виду возможность подключения до 80% через несколько лет.

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

Процент пользователей, готовых подключиться к Интернет
Рис. 7.1. Процент пользователей, готовых подключиться к Интернет, в процентах от опрощенных, в зависимости от суммы месячных затрат, в USD.

Конечно, сумма реальных затрат абонента может сильно отличаться от планируемых расходов. Однако уровень массового спроса вполне определен - это 20 USD в месяц (на 2004 год, для Москвы).

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

Например, один-два доллара с абонента можно заработать на доступе к качественно оформленному видео-аудио порталу. Или за "профессиональный" почтовый ящик с доступом по IMAP. Или за место под www сервер. В общем, так или иначе, но до 25 USD средний платеж "дотянуть" в Москве можно (в других регионах России эта величина будет меньшей - приблизительно от 10 до 20 долларов).

Что бы провайдерская фирма могла хоть как-то существовать (содержать штат, офис, платить налоги) нужно получить около 5к$ прибыли. Да еще оборудование центрального узла и лицензии - $20к разовая покупка. Учитывая, что стоимость обслуживания абонента сети около $10 (этот вопрос будет рассмотрен более подробно в следующих параграфах), то нужно подключить минимум 500 абонентов. Однако если подумать о начальных затратах, то выходит, что сети менее 1000 пользователей способны существовать только за счет внешних инвестиций (либо на иной, не коммерческой мотивации).

При себестоимости подключения абонента в $50 минимальный стартовый капитал для строительства жизнеспособной сети составляет 50 тысяч долларов. Однако, подключение процесс не одномоментный. И примерно год придется потратить на строительство при сохранении основных расходов. Это еще затраты порядка 50-100 тысяч. Таким образом, в районе с сильной конкуренцией "стартовать" без серьезных денег бессмысленно.

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

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

Можно предположить, что себестоимость услуг на абонента (обслуживание плюс трафик и другие покупные услуги) упадет с 15-20 долларов до 10. На оставшиеся $20-$10=$10 нужно жить и развиваться. Много это или мало?

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

Предположим (упрощенно), что сеть развивалась следующим образом (в месяц добавляется 100 абонентов, себестоимость подключения $50):

Экономические показатели развития домашней сети, в USD
Рис. 7.2. Экономические показатели развития домашней сети, в USD.

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

Однако, через 3 года вполне может оказаться, что сеть... устарела. И нуждается в тотальной реконструкции. На первоначальное строительство было затрачено $200к, реконструкция обойдется в $150к. А прибыль получена всего $330к. Т.е. результат - около 50% за 3 года... Далеко не блестящий - а ведь в реальности затраты всегда больше, а прибыль - меньше.

Конечно, в примере очень велики погрешности. На практике в данной ситуации возможна и заметная прибыль, например если подключать не 100 абонентов в месяц, а 200 - получить "чистыми" удастся $687к. Но если выбрать слишком дорогое оборудование и тратить на подключение $100 - то в результате сеть будет стоить $370к, а прибыль - $150к. Но тут и реконструкция может понадобиться не через 3, а через 4 года.

Таким образом, экономика сетей (как и любых проектов, рассчитанных на сбор средств с большого числа абонентов) очень сильно зависит от правильных решений. 2-3 лишних доллара с клиента способны полностью переломить ситуацию в ту или иную сторону. Малый темп подключений - убытки. Быстроустаревающая схема - убытки, дорогое решение "с запасом" - опять убытки. В общем, вариантов масса, и они требуют настоящего профессионального расчета.

Кроме цифр на выбор и платежи абонента влияет еще множество субъективных факторов. Район города, время года, уровень цен конкурентов DialUp, степень телефонизации, наличие или отсутствие повременной оплаты телефона, и многое другое. Это все желательно учитывать в бизнес-плане.

Но особенное внимание нужно обратить на качество услуг - это огромный вопрос, но и он выходит за рамки экономики Ethernet-провайдеров. Для простоты нужно считать, что качество не должно подлежать обсуждению. А просто должно быть. То же самое, кстати, можно сказать и об имидже оператора.

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

  • Привлечь максимум пользователей (причем обязательно платежеспособных).
  • Создать сеть с минимальной полной стоимостью (строительство плюс обслуживание);
  • Продать пользователям наибольший возможный пакет услуг. А вот как идти к поставленной цели - будет рассмотрено в следующих частях.



Глава 11 : Кадры решают все

Директор (общий, технический, коммерческий), Бухгалтерия, Техподдержка, Отдел строительства сетей Служба приема платежей Отдел рекламы и маркетинга Отдел продаж Отдел согласований)))

Глава 12 : Считать или резать, или разговор об анлимите

Попробуем сравнить прейскуранты оказывемых услуг разных интернет-провайдеров. Голова может пойти кругом - столько разных позиций, хотя, по сути, все продают одно и то же - интернет. Особенно забавны пункты вроде "после того, как купите 100, 101 получите со скидкой!" Если провести сравнение, то можно выделить основные типы подключений:

  1. По времени.
  2. По трафику.
  3. Без ограничений.

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

Поскольку интернет строится на каналах связи, интернет-каналы имеют соответствкнно ограничения по скорости передачи данных а следовательно и по пропускной способности. Например канал 64 Кбит/сек способен обеспечить скорость передачи данных до 8 Кбайт/сек. Нетрудно подсчитать - 8 Кбайт/сек, 480 Кбайт/мин, 28,8 Мбайт/час, 691,2 Мбайт/сутки, 20,736 Гбайт/месяц. Это тот обьем, который максимально можно передать через канал 64 Кбит/сек. Нетрудно теперь посчитать стоимость одного мегабайта или гигабайта. Здесь необходимо еще сделать поправки. Канал не бывает всегда загружен на 100% (а если такое случается, то это резко снижает качество передачи данных). Также загрузка канала зависит от времени суток - ночью, как правило, канал менее загружен. Эти факторы также учитываются при расчете стоимости. Отсюда и возникает желание провайдера вводить различную стоимость в зависимости от времени суток.

Историческая справка.
В 90-е годы прошлого столетия многие провайдеры интернета были горды IP-каналами, работавшими через каналы телефонии на скорости 19.2Kbit/s (33.6Kbit/s вообще было пределом мечтаний). И ведь работали! Потому как другого ничего не было, а спутниковые каналы были непозволительной роскошью, доступной немногим.

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

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

Интернет можно сравнить с телефонией. Снова сначала немного истории.

  1. В начале 90-х годов была фиксированная абонплата за местную связь и поминутная за междугородную и международную.
  2. В конце 90-х годов стали появляться цифровые АТС и вмести с ними появился тариф за местную связь (поминутный), состоящий из абонентской платы и оплаты за исходящий трафик.
  3. Середина 00-х годов. Тариф за местную связь практически повсеместно поминутный. В конце 00-х годов снова наблюдается переход на тарифы с фиксированной оплатой.

Теперь посмотрим с другой стороны.

  1. Начало 90-х годов. Оператор связи единственный - гортелеком и к тому же он монополист. Установить телефон в частном секторе да еще на окраине города большинству пользователей практически нереально.
  2. Конец 90-х. Появляются частные операторы связи. Спрос на проводной телефон очень высок (сотовый слишком дорог). Применение поминутного тарифа позволяет существенно уменьшить нагрузку по соединительным линиям в сторону гортелекома, получая при этом дополнительную прибыль. Увеличение соединительных линий представляет собой дорогостоющую задачу, связанную с дооборудованием существующих станций гортелекома.
  3. Начало 00-х годов. Гортелеком производит постепенную модернизацию АТС и вводит на них поминутный тариф.
  4. Конец 00-х годов. Телефон установить нет проблем. Стоимость установки - несущественная. Вот только надобности в нем уже нет. Зачем? Если у каждого в семье есть мобильный ...

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

Какой из всего вышесказанного можно сделать вывод?
Каждая телекоммуникационная система имеет ограничение по пропускной способности абонентского трафика. Если потребности абонентов по передаче трафика превышают возможности системы, то владелец системы вводит тарифы по учету трафика. Услуги без ограничений при этом тоже есть, но они практически никем не востребованы по причине высокой стоимости. Когда пропускная способность системы достаточна, то стоимость трафика выходит очень маленькой и владельцу становится невыгодно считать "милликопейки". Гораздо проще продавать оптом - по фиксированной цене.

Глава 13 : Метод передачи РРР через Ethernet (PPPoE)

Метод передачи РРР через Ethernet (PPPoE).


Перевод с английского: Вединов С. Ф.
(e-mail: gray@kubtelecom.ru)

Назначение этого руководства.
Это руководство предоставляет информацию для провайдеров Интернет. Но оно не определяет стандарт Интернет какого-либо вида. Распространение этого руководства не ограничено.


Авторские права.
Авторское право принадлежит " Обществу Интернет " (The Internet Society) (1999). Все права оговорены.

Краткий обзор.
Протокол двухточечной передачи данных (Point-to-Point Protocol (PPP)) представляет собой стандартный метод передачи многопротокольных (мультипротокольных) дейтаграмм1 через двухточечные линии передачи.
Этот документ описывает, как обеспечить РРР сессию и инкапсулировать пакеты РРР через Ethernet.

Применение.
Эта детализация предназначена для того, чтобы обеспечить такую возможность управления РРР, которая определена Протоколом Управления Связью (Link Control Protocol), Протоколом Контроля Загруженности Сети (Network-layer Control Protocol), аутентификацией и т. д. РРР предусматривает обмен данными только между двумя точками и не предназначен для многоточечной передачи данных, которая возможна в Ethernet и в других многодоступных средах.
Это руководство может быть использовано совместными Хостами со сложной структурой, Ethernet-ом для открытия РРР-сессий многоадресного доступа к информации посредством одного или нескольких объединенных модемов. Оно предназначено для использования в технологиях широкополосного доступа, которые представляют объединенную топологию Ethernet, когда провайдеры, предоставляющие такой доступ желают ассоциировать РРР-сессию с каждым клиентом.
Этот документ описывает технологию инкапсуляции РРР через Ethernet, которая внедрена такими компаниями как RedBack Networks, RouterWare, UUNET и другими.


1. Введение

Перед современными технологиями доступа стали несколько несовместимых целей. Желательно соединять Хосты со сложной структурой на отдаленных участках с помощью одного и того же клиентского устройства доступа. Предоставлять контроль над доступом и биллинговую функциональность в стиле "dial-up" с использованием РРР. Во многих технологиях доступа самый дешевый способ соединять Хосты с помощью одного и того же клиентского устройства - это способ с использованием Ethernet. Вдобавок, желательно сохранять низкую стоимость этого устройства до тех пор, пока спрос мал или оно не сконфигурировано.
РРРоЕ предоставляет возможность соединять сетевые Хосты с помощью нескольких объединенных устройств доступа в единый удаленный Узел доступа. C такой моделью, каждый Хост использует свой собственный РРР-стек, а пользователь работает со знакомым интерфейсом. Управление доступом, типом услуги и биллинг может осуществляться по каждому пользователю, а не по сайту.
Чтобы обеспечить двухточечное соединение через Ethernet, каждая РРР-сессия должна узнавать Ethernet-адрес удаленного пиринга, как только установлен уникальный идентификатор сессии. РРРоЕ включает Discovery-протокол, который это обеспечивает.


2. Обзор документа

РРРоЕ имеет два различных уровня. Это Discovery-уровень и уровень РРР-сессии. Когда Хост открывает новую РРР-сессию, сначала проходит идентификация MAC2 - адреса Ethernet на Discovery-уровне и идентифицируется РРР-сессия. Пока РРР определяет отношения между двумя точками, Discovery-уровень находится в неопределенных отношениях "клиент-сервер"3. Далее на Discovery-уровне Хост получает доступ на Сервер. В топологии сети может быть более одного Узла доступа, с которым Хост может общаться. Discovery-уровень предоставляет возможность Хосту связаться со всеми Узлами доступа и выбрать один. Когда процесс на Discovery-уровне успешно завершен и Хост и выбранный Узел доступа уже имеют информацию, которую они будут использовать при установлении двухточечного соединения через Ethernet.
Discovery-уровень остается в неопределенном состоянии, пока не установлена РРР-сессия. Как только РРР-сессия установлена и Хост, и Узел доступа распределяют ресурсы для создания виртуального интерфейса РРР.


3. Полезные сведения

Полезные сведения будут описаны применительно к Discovery-уровню и уровню РРР-сессии.

Фрейм Ethernet выглядит следующим образом


1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
Адрес пункта назначения
(48 бит)
Адрес документа
(48 бит)
Тип Ethernet
(16 бит)
Полезные сведения
Контрольная сумма4

Поле "Адрес пункта назначения" содержит также адрес однонаправленной передачи Ethernet, или широковещательный адрес Ethernet (0хffffffff). Для пакетов Discovery-уровня объем является или unicast или широковещательным адресом как определено в Discovery-разделе. Для трафика РРР-сессии это поле должно содержать пиринговый unicast-адрес, который определяется из Discovery-уровня.

Поле "Адрес документа" должно содержать МАС-адрес Ethernet исходного устройства.

Значение поля "Тип Ethernet" устанавливается или 0х8863 (Discovery-уровень), или 0х8864 (уровень РРР-сессии).

Полезные сведения Ethernet для РРРоЕ выглядит следующим образом:


1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Версия Тип Код Идентификатор сессии
Длина Полезные сведения

Поле "Версия" четырехбитное и его значение должно быть 0х1 для этой версии РРРоЕ-детализации.

Поле "Тип" также четырехбитное и его значение должно быть 0х1 для этой версии РРРоЕ-детализации.

Поле "Код" восьмибитное и описывается ниже применительно к уровню Discovery и уровню РРР-сессии.

Поле "Идентификатор сессии" шестнадцатибитное. Оно имеет неопределенное значение в сетевом байтовом порядке. Это значение описывается ниже для пакетов уровня Discovery. Это значение зафиксировано для открытия РРР-сессии и, фактически определяет РРР-сессию вместе с адресом пункта назначения и адресом документа Ethernet. Значение 0хffffff зарезервировано для использования в будущем и не используется.

Поле "Длина" шестнадцатибитное. Значение в сетевом байтовом порядке показывает продолжительность полезной сведений РРРоЕ.


4. Уровень Discovery

Уровень Discovery проходит в четыре этапа. Когда эти этапы завершены, обе точки знают идентификатор РРР-сессии и адрес пиринга Ethernet, который однозначно описывается вместе с РРРоЕ -сессией. Этапы содержат Хост, транслирующий пакет Инициации, один или более Узлов Доступа, посылающих пакет-Предложение, Хост, посылающий unicast-пакет-Запрос Сессии и выбранный Узел Доступа, посылающий пакет-Подтверждение. Когда Хост получает пакет-Подтверждение, он может переходить на уровень РРР-сессии. Когда Узел Доступа посылает пакет-Подтверждение, он также может переходить на уровень РРР-сессии.
Все фреймы Ethernet Discovery-уровня имеют значение поля "Тип Ethernet" 0х8863. Полезные сведения РРРоЕ содержат в себе 0 или более ТЭГов. Любой ТЭГ является ТЭГом TLV (тип-длина-значение) и выглядит следующим образом:


1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Тип (TAG_TYPE) Длина (TAG_LENGTH)
Значение (TAG_VALUE)

"Тип" - это шестнадцатибитное поле в сетевом байтовом порядке. Приложение А содержит список всех типов ТЭГов и их значений.

"Длина" - это также шестнадцатибитное поле. Оно не прописано в сетевом байтовом порядке, указывает длину значения ТЭГа в байтах

Если Discovery-пакет получен c ТЭГом неизвестного типа, то это ТЭГ игнорируется, если только не будет задан иным способом в данном документе. Это обеспечивает обратную совместимость, если/когда новый ТЭГ добавлен. Если обязательные ТЭГи добавлены, то номер версии будет расти.

Некоторые примеры Discovery-пакетов представлены в Приложении Б.


4.1 PADI5 - пакет

Хост посылает PADI-пакет с адресом места назначения, установленного для адреса вещания. Поле "Код" имеет значение 0х09, а Идентификатор Сессии устанавливается 0х0000.

PADI-пакет должен содержать ровно один ТЭГ типа "Service Name", указывающий услугу, которую запрашивает Хост и любой номер других типов ТЭГов. Входной PADI-пакет (включающий заголовок РРРоЕ) не должен превышать 1484 байта, чтобы сохранить достаточно места для смены агента, чтобы добавить RSI6 ТЭГ.


4.2 PADO7 - пакет

Когда Узел Доступа получает PADI-пакет, которым он может оперировать, в ответ он посылает PADO-пакет. Адрес Места Назначения - это Unicast-адрес Хоста, который посылает PADI-пакет. Значение поля "Код" устанавливается 0х07, а Идентификатор Сессии остается - 0х0000.

PADO-пакет должен содержать один AC-name ТЭГ, содержащий в себе название Узла Доступа, Service Name ТЭГ тот же, что и для PADI-пакетов, и несколько других Service Name ТЭГов, содержащие другие услуги, которые предлагает Узел Доступа. Если Узел Доступа не может оперировать PADI, то он не посылает ответ с PADO.


4.3 PADR8 - пакет

Как только PADI был передан, Хост может получить более одного PADO. Хост просматривает все PADO-пакеты, которые получает и выбирает один. Выбор может основываться на AC-name или на названии предложенных услуг. Затем Хост посылает один PADR-пакет Узлу Доступа, который был выбран. Поле "Адрес места назначения" устанавливается для unicast-адреса Ethernet Узла Доступа, который посылает PADO. Значение кодового поля устанавливается 0х19, а "Идентификатор сессии" - 0х0000.

PADR-пакет должен содержать только один ТЭГ типа "Service Name", указывая услугу, Хост запрашивает и любое число других типов ТЭГов.


4.4 PADS9 - пакет

Когда Узел Доступа получает PADR-пакет, он готовится открыть РРР-сессию. Он генерирует уникальный Идентификатор для РРРоЕ-сессии и отвечает Хосту, посылая PADS-пакет. Поле "Адрес места назначения" - это unicast-адрес Ethernet Хоста, посылающего PADR-пакет. Значение поля "Код" устанавливается 0х65, а значение "Идентификатора сессии" должно устанавливаться в уникальной форме, сгенерированной для этой РРРоЕ-сессии.

PADS-пакет содержит только один ТЭГ типа "Service Name", указывая услугу, под которой Узел Доступа принимает РРРоЕ-сессию и любое число других типов ТЭГов.

Если Узлу Доступа не подходит "Service Name" PADR-пакета, то он в ответ посылает PADS-пакет, содержащий ТЭГ типа "Ошибка Service Name" (и любое число других типов ТЭГов). В этом случае значение Идентификатора сессии устанавливается 0х0000.


4.5 PADT10 - пакет

Этот пакет может быть послан в любое время после основания сессии для указания того, что РРРоЕ-сессия была закончена. Он может быть послан или Хостом, или Узлом Доступа. "Адрес места назначения" - unicast-адрес Ethernet, значение кодового поля устанавливается 0ха7, а значение "Идентификатора сессии" устанавливается для того, чтобы указать, какая именно сессия была закончена, при этом ТЭГи не требуются.

Когда PADT-пакет получен, никакого дальнейшего РРР-трафика, который бы отсылался, используя эту РРР-сессию, не допускается. Даже обычные РРР-пакеты окончания сессии не должны отсылаться, когда послан или получен PADT-пакет. PPP peer должен использовать сам протокол PPP, чтобы снизить PPPoE-сессию, но PADT-пакет может использоваться, когда PPP не может быть использован.


6. Уровень РРР-сессии

Если PPPoE-сессия начинается, данные PPP посылаются как при любой другой инкапсуляции PPP. Все Ethernet-пакеты являются unicast-пакетами. Значение "Тип Ethernet" устанавливается 0х8864. Код РРРоЕ устанавливается 0х00. "Идентификатор сессии" не меняется для этой РРРоЕ-сессии, а назначается на Discovery-уровне. Полезные сведения РРРоЕ содержат РРР-фрейм, который начинается с идентификатора протокола РРР.

Пакет-пример показан в Приложении Б.


7. Анализ LCP

Рекомендуется выбор системного кода11 LCP-конфигурации, но не рекомендуется выбор (PFC)12. При выполнении запрос о любом из следующих выборов отвергается, а именно:

выбор FCS13 , ACFC14 , ACCM15 .

При выборе, MRU16 не должен иметь больший размер, чем 1492 байта. Поскольку Ethernet имел максимальный размер полезной информации 1500 байт, PPPoE-заголовок - 6 байт, а идентификатор протокола PPP - 2 байта, PPP MRU не должен превышать 1492 байта.

Желательно, чтобы Узел Доступа время от времени послал Echo-Request-пакеты Хосту, чтобы определить состояние сессии. Иначе Хост закрывает сессию без отсылки Terminate-Request-пакета и Узел Доступа не сможет определить, что сессия закрыта.

Когда LCP закрывается, Хост и Узел Доступа должны прекратить использование данной РРР-сессии. Если Хост желает открыть другую РРР-сессию, то он должен вернуться на Discovery-уровень.


8. Прочая информация

Когда Хост не получает PADO-пакет в пределах заданного времени, он пересылает PADI-пакет и удваивает период ожидания. Это повторяется столько, сколько требуется. Если Хост ожидает получения PADS-пакета, используется аналогичный механизм тайм-аута, а Хост постоянно посылает PADR-пакеты. После определенного числа повторных попыток, Хост должен заново передать PADI-пакет.

Поля "Тип Ethernet", использованные в этом документе (0x8863 and 0x8864), назначены IEEE для использования РРР с Ethernet (PPPoE). Использование этих значений и поля "Версия" РРРоЕ однозначно оговорены в данном протоколе.

UTF-8 [5] используется в этом документе вместо ASCII. UTF-8 поддерживает целый набор ASCII символов, а также наборы международных символов. См. [5] для более подробной информации.


9. Безопасность

Чтобы защититься от атаки DOS17, Узел Доступа может применить AC-Cookie ТЭГ. Узел Доступа должен однозначно регенерировать ТЭГ-Значение, который базируется на адресе PADR-пакета. Используя это, Узел Доступа может гарантировать, что адрес PADI-пакета доступен и затем может ограничить параллельные сессии для этого адреса. Какой алгоритм использовать не оговаривается, а оставляется как часть процесса выполнения. Как пример можно рассматривать HMAC [3] через МАС-адрес Хоста, использующий ключ, известный только Узлу Доступа.

Пока AC-Cookie полезен при защите только от некоторых DOS-атак, он не может защитить от всех DOS-атак и Узел Доступа может применить другие средства, чтобы защитить ресурсы.

Многие Узлы Доступа не захотят предоставить информацию относительно тех услуг, которые они предлагают. В таком случае Узел Доступа должен применить одну из двух политик. Он никогда не должен отклонять запросы, основанные на Service-Name-ТЭГе и должен всегда возвращать ТЭГ-Значение, который ему был послан. Или он должен принимать запросы, основанные на Service-Name-ТЭГе c нулевым ТЭГом-длиной (указание любой услуги). Но первое решение предпочтительнее.

10. Уведомления

Этот документ базируется на концепциях, обсуждавшихся на различных форумах, включая ADSL18 -форум. Огромное количество информации было взято из RFC 1661, RFC 1662 и RFC 2364.


11. Ссылки

1. Simpson W., Редактор, " The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Июль 1994

2. Bradner, S., "Ключевые термины используемые в RFC для указания уровней запроса", BCP 14, RFC 2119, Март 1997.

3. Krawczyk, H., Bellare, M. и R. Canetti, "HMAC: Хэширование по ключу для аутентификации сообщения", RFC 2104, Февраль 1998.

4. Reynolds, J. И J. Postel, "Стандартная нумерация19 ", STD 2, RFC 1700, Октябрь 1994. Смотри также: http://www.iana.org/numbers.html

5. Yergeau, F., "UTF-8, Формат преобразования ISO 10646", RFC 2279, Январь 1998.



Приложение A

ТЭГ-Тип и ТЭГ-Значение TAG_TYPES and TAG_VALUES

0x0000 - Конец списка (End-Of-List)

Этот ТЭГ указывает, что больше в списке ТЭГов нет. ТЭГ-Длина (TAG_LENGTH) в этом ТЭГе всегда равен нулю. Использование этого ТЭГа не требуется, но оставляется для обратной совместимости.
0x0101 Название услуги (Service-Name)
Этот ТЭГ указывает имя услуги. ТЭГ-Значение (TAG_VALUE) в строке UTF-8 указывает, что строка не заканчивается на ноль. Когда ТЭГ-Длина (TAG_LENGTH) равен нулю, то он используется, чтобы указать, что любая услуга приемлема. Например, Service-Name-TAG указывает в ISP имя или класс, или качество услуги.
0x0102 AC-Name
Этот ТЭГ указывает, что следующая строка однозначно идентифицирует Узел Доступа от всех других. Это может быть комбинацией торговой марки, модели, серийной информации идентификатора или просто преобразованием MAC-адреса в строке UTF-8. Эта строка не должна заканчиваться нулем.
0x0103 Уникальность Хоста (Host-Uniq)
Эта ТЭГ используется Хостом, чтобы однозначно ассоциировать ответ Узла Доступа (PADO или PADS) и индивидуальный запрос Хоста (PADI или PADR). ТЭГ-Значение (TAG_VALUE) представляет собой двоичные данные любой величины и длины, которую выбирает Хост. Это не интерпретируется Узлом Доступа. Хост может включить Host-Uniq TAG в PADI или PADR. Если Узел Доступа получает этот ТЭГ, он должен включить исходный ТЭГ в ассоциированный ответ PADO или PADS-пакетов.
0x0104 AC-Cookie
Этот ТЭГ используется Узлом Доступа, чтобы помочь в защите против DOS (см. раздел "Безопасность"). Узел Доступа может включить этот ТЭГ в PADO-пакет. Если Хост получает этот ТЭГ, он должен вернуть исходный ТЭГ в следующий PADR-пакет. ТЭГ-Значение (TAG_VALUE) - это двоичные данные любой значения и длины, не интерпретируемые Хостом.
0x0105 Vendor-Specific
Этот ТЭГ используется, чтобы передать конфиденциальную информацию поставщика услуг. Первые четыре байта ТЭГа-Значения (TAG_VALUE) содержат идентификатор поставщика, а все остальное не расматривается. Старший байт идентификатора поставщика, равный 0 и младший - 3 байта управляют Сетевым Код-Поставщиком SMI Частных Предприятий в сетевом байтовом порядке, как определено в Стандартных Числах RFC [4].

Использование этого ТЭГа не рекомендуется. Чтобы гарантировать внутреннюю работоспособность, при исполнении Vendor-Specific-TAG может проигнорироваться.
0x0110 Смена идентификатора сессии (Relay-Session-Id)
Этот ТЭГ может быть добавлен к любому Discovery-пакету промежуточным агентом, который передает трафик. ТЭГ-Значение (TAG_VALUE) в этом случае непонятен как Хосту, так и Узлу Доступа. Если или Хост, или Узел Доступа получает этот ТЭГ, то они включают исходный ТЭГ в любой Discovery-пакет, который они посылают как ответ. Все PADI-пакеты должны гарантировать достаточное место для добавления ТЭГа смены идентификатора сессии (Relay-Session-Id) с ТЭГом-Длиной (TAG_VALUE), равным 12 байт.

ТЭГ смены идентификатора сессии (Relay-Session-Id) не включается в Discovery-пакет, если он уже содержит его. В этом случае промежуточный агент должен использовать существующий ТЭГ смены идентификатора сессии (Relay-Session-Id). Если он не может использовать существующий ТЭГ, или недостаточно места, чтобы добавить Relay-Session-Id-ТЭГ, тогда промежуточный агент возвращает ТЭГ Общей Ошибки (Generic-Error TAG) отправителю.
0x0201 Ошибка названия услуги (Service-Name-Error)
Этот ТЭГ (обычно с разделом нулевых данных) указывает, что по той или иной причине, запрос данного Названия Услуги не может быть выполнен. Если есть данные, и первый байт данных ненулевой, тогда они выводятся в строке UTF-8, в которой объясняется, почему запрос был отвергнут. Эта строка не должна заканчиваться нулем.
0x0202 AC-System-Error
Этот ТЭГ указывает, что на Узле Доступа имеется какая-то ошибка в выполнении запроса Хоста. (например, недостаточно ресурсов, чтобы создать виртуальный канал.) Этот ТЭГ может быть включен в PADS-пакеты.

Если есть данные, и первый байт данных ненулевой, тогда они выводятся в строке UTF-8, в которой объясняется природа ошибки. Эта строка не должна заканчиваться нулем.
0x0203 Общая ошибка (Generic-Error)
Этот ТЭГ указывает ошибку. Он может быть добавлен к PADO, PADR или PADS-пакетам, когда происходит неисправимая ошибка и нет соответствующих ТЭГов, сообщающих о ней. Если есть данные, и первый байт данных ненулевой, тогда они выводятся в строке UTF-8, в которой объясняется природа ошибки. Эта строка не должна заканчиваться нулем.



Приложение Б

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

PADI-пакет:


1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0xFFFFFFFF
0xFFFF Host_mac_addr
Host_mac_addr (cont)
ETHER_TYPE = 0x8863 v = 1 t = 1 CODE = 0x09
SESSION_ID = 0x0000 LENGTH = 0x0004
TAG_TYPE = 0x0101 TAG_LENGTH = 0x0000

PADO-пакет:


1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Host_mac_addr
Host_mac_addr (cont) Access_Concentrator_mac_addr
Access_Concentrator_mac_addr (cont)
ETHER_TYPE = 0x8863 v = 1 t = 1 CODE = 0x07
SESSION_ID = 0x0000 LENGTH = 0x0020
TAG_TYPE = 0x0101 TAG_LENGTH = 0x0000
TAG_TYPE = 0x0102 TAG_LENGTH = 0x0018
0x47 0x6f 0x20 0x52
0x65 0x64 0x42 0x61
0x63 0x6b 0x20 0x2d
0x20 0x65 0x73 0x68
0x73 0x68 0x65 0x73
0x68 0x6f 0x6f 0x74

PPP LCP-пакет: значение протокола PPP установлено (0xc021), но полезная нагрузка PPP оставлены получателю. Это пакет, который Хост посылает Узлу Доступа:


1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Access_Concentrator_mac_addr
Access_Concentrator_mac_addr(c) Host_mac_addr
Host_mac_addr (cont)
ETHER_TYPE = 0x8864 v = 1 t = 1 CODE = 0x00
SESSION_ID = 0x1234 LENGTH = 0x????
PPP PROTOCOL = 0xc021 PPP payload




Адреса авторов:

Louis Mamakos
UUNET Technologies, Inc.
3060 Williams Drive Fairfax, VA 22031-4648 США
EMail: louie@uu.net

Kurt Lidl
UUNET Technologies, Inc.
3060 Williams Drive Fairfax, VA 22031-4648 США
EMail: lidl@uu.net

Jeff Evarts
UUNET Technologies, Inc.
3060 Williams Drive Fairfax, VA 22031-4648 США
EMail: jde@uu.net

David Carrel
RedBack Networks, Inc.
1389 Moffett Park Drive Sunnyvale, CA 94089-1134 США
EMail: carrel@RedBack.net

Dan Simone
RedBack Networks, Inc.
1389 Moffett Park Drive Sunnyvale, CA 94089-1134 США
EMail:dan@RedBack.net

Ross Wheeler
RouterWare, Inc.
3961 MacArthur Blvd., Suite 212 Newport Beach, CA 92660 США
EMail: ross@routerware.com


Полное авторское уведомление

Авторское право принадлежит " Обществу Интернет " (The Internet Society) (1999). Все права оговорены.

Этот документ и его переводы могут копироваться и добавляться к другим документам. Вторичные документы, комментирующие или каким - либо иным способом объясняющие содержание данного документа, или помогающие в его применении могут подготавливаться, копироваться, публиковаться и распространяться, целиком или частично, без всякого рода ограничений, при условии, что вышеуказанное авторское уведомление и этот параграф будут включаться во все такие копии. Тем не менее, сам этот документ нельзя как - либо изменять, например, удаляя авторское уведомление или ссылки на Общество Интернет (Internet Society) или другие Интернет-организации, за исключением тех случаев, когда это необходимо для разработки стандартов Интернет или же правила перевода на другой язык не позволяют этого сделать. В этом случае должны соблюдаться правила данного авторского права, определенные в этих стандартах.

Ограниченные права, оговоренные выше, являются бессрочными и не отменятся Обществом Интернет (Internet Society), его преемниками или правопреемниками.

Этот документ и информация, содержащаяся в нем, предоставляется, как она есть. Общество Интернет (Internet Society) и Internet Engineering Task Force не дает никаких явных или неявных гарантий, включая и то, что, использование приведенной выше информации не нарушит каких - либо прав или неявных гарантий коммерческой ценности или пригодности для конкретной цели.

1. Дейтаграмма - пакет данных и связанной с ним адресной информации, который маршрутизируется в сети с переключением пакетов или передается по локальной сети.
2. Media Access Control - Управление доступом к среде
3. Хост - Узел доступа
4. Используется для подтверждения правильности данных, напр. в пакетах TCP/IP
5. The PPPoE Active Discovery Initiation
6. Relay-Session-Id - Идентификатор заменяющей сессии
7. The PPPoE Active Discovery Offer
8. The PPPoE Active Discovery Request
9. The PPPoE Active Discovery Session-confirmation
10. The PPPoE Active Discovery Terminate
11. Первое слово файла, определяющее его назначение, проф. магическое число
12. Protocol Field Compression
13. Field Check Sequence
14. Address-and-Control-Field-Compression
15. Asynchronous-Control-Character-Map (ACCM)
16. Maximum-Receive-Unit
17. Denial of Service
18. Asymmetric Digital Subscriber Line
19. Порядок присваивания номеров новым сетевым протоколам Internet, определяемый правилами IANA
Ссылка на материал, для размещения на сторонних ресурсах
/page/konkursy/25142/ekspluatatsiya.html