По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой заключительной статье о перераспределении маршрутов мы проверим работу Route redistribution с помощью IPv6 и увидим небольшое отличие в настройке routes redistributed IPv6 от routes redistributed IPv4.
Предыдущие статьи из цикла:
Часть 1. Перераспределение маршрутов (Route redistribution)
Часть 2. Фильтрация маршрутов с помощью карт маршрутов
Часть 3. Перераспределение маршрутов между автономными системами (AS)
Перераспределение подключенных сетей
Во-первых, рассмотрим маршрутизатор, выполняющий маршрутизацию, предположим, что используется протокол OSPF. Кроме того, предположим, что маршрутизатор имеет несколько интерфейсов, которые участвуют в маршрутизации OSPF. Представьте, что на этом же маршрутизаторе мы запускаем другой протокол маршрутизации (скажем, EIGRP), и мы делаем взаимное перераспределение маршрутов.
Вот что удивительно. Если мы делаем перераспределение маршрута на этом маршрутизаторе, сети IPv4, связанные с интерфейсами этого маршрутизатора, участвующими в OSPF в нашем примере, будут перераспределены в EIGRP. Однако сети IPv6, будут вести себя по-другому. В частности, в сетях IPv6 мы должны ввести дополнительный параметр в нашу конфигурацию перераспределения маршрутов, явно указывая, что мы хотим перераспределить подключенные сети. В противном случае эти маршруты IPv6, связанные с непосредственно с подключенными интерфейсами, не перераспределяются.
Логика такого поведения вытекает из понимания того, что для перераспределения маршрута данный маршрут должен появиться в таблице IP-маршрутизации маршрутизатора. Конечно, когда посмотрим таблицу IP-маршрутизации маршрутизатора и увидим непосредственно подключенные сети, эти сети отображаются как подключенные сети, а не сети, которые были изучены с помощью определенного протокола маршрутизации.
В то время как route redistribution для IPv4 понимает, что сеть напрямую подключена, но участвует в процессе маршрутизации и поэтому будет перераспределена, route redistribution для IPv6 не делает такого предположения. В частности, если мы перераспределяем сети IPv6 из одного протокола маршрутизации в другой, эти сети должны отображаться в таблице маршрутизации IPv6 маршрутизатора вместе с указанием, что они были изучены с помощью перераспределяемого протокола маршрутизации. Конечно, мы можем добавить дополнительный параметр к нашей команде redistribute, чтобы заставить эти непосредственно подключенные сети IPv6 (участвующие в распространяемом протоколе) также быть перераспределенными. Эта настройка будет продемонстрирована немного позже.
Перераспределение в OSPF
В прошлой статье мы обсуждали потенциальную проблему, с которой вы можете столкнуться при распространении в OSPF (в зависимости от вашей версии Cisco IOS). Проблема была связана с подсетями. В частности, по умолчанию в более старых версиях Cisco IOS OSPF только перераспределяет классовые сети в OSPF, если мы не добавим параметр subnets к команде redistribute. Добавление этого параметра позволило перераспределить сети в OSPF, даже если у них не было классовой маски. Пожалуйста, имейте в виду, что последние версии Cisco IOS автоматически добавляют параметр подсети, не требуя от вас ручного ввода.
Однако параметр подсети в IPv6 route redistribution отсутствует. Причина в том, что IPv6 не имеет понятия о подсетях.
Пример route redistribution IPv6
Чтобы продемонстрировать перераспределение маршрутов IPv6, рассмотрим следующую топологию:
Протоколы маршрутизации OSPFv3 и EIGRP для IPv6 уже были настроены на всех маршрутизаторах. Теперь давайте перейдем к маршрутизатору CENTR и настроим взаимное route redistribution между этими двумя автономными системами. Убедимся в этом, проверив таблицу маршрутизации IPv6 маршрутизатора CENTR.
Приведенные выше выходные данные показывают, что мы изучили две сети IPv6 через OSPF, две сети IPv6 через EIGRP, а CENTR напрямую подключен к двум сетям IPv6. Далее, давайте настроим взаимное перераспределение маршрутов между OSPFv3 и EIGRP для IPv6.
CENTR # conf term
Enter configuration commands, one per line. End with CNTL/Z.
CENTR (config)# ipv6 router eigrp 1
CENTR (config-rtr) # redistribute ospf 1 metric 1000000 2 255 1 1500?
include-connected Include connected
match Redistribution of OSPF routes
route-map Route map reference
cr
CENTR (config-rtr) #redistribute ospf 1 metric 1000000 2 255 1 1500 include-connected
CENTR (config-rtr) #exit
CENTR (config) # ipv6 router ospf 1
CENTR (config-rtr) #redistribute eigrp 1?
include-connected Include connected
metric Metric f or redistributed routes
metric-type OSPF/IS-IS exterior metric type for redistributed routes
nssa-only Limit redistributed routes to NSSA areas
route-map Route map reference
tag Set tag for routes redistributed into OSPF
cr
CENTR (config-rtr) #redistribute eigrp 1 include-connected
CENTR (config-rtr) #end
CENTR#
Обратите внимание, что конфигурация взаимного перераспределения маршрутов, используемая для маршрутов IPv6, почти идентична нашей предыдущей конфигурации для перераспределения маршрутов IPv4. Однако для обеих команд перераспределения был указан параметр include-connected. Это позволило маршрутизатору CENTR перераспределить сеть 2003::/64 (непосредственно подключенную к интерфейсу Gig0/1 маршрутизатора CENTR и участвующую в OSPF) в EIGRP. Это также позволило маршрутизатору CENTR перераспределить сеть 2004::/64 (непосредственно подключенную к интерфейсу Gig0/2 маршрутизатора CENTR и участвующую в EIGRP) в OSPF.
Чтобы убедиться, что наша конфигурация рабочая, давайте перейдем на оба маршрутизатора OFF1 и OFF2, убедившись, что каждый из них знает, как достичь всех шести сетей IPv6 в нашей топологии.
Вышеприведенные выходные данные подтверждают, что маршрутизаторы OFF1 и OFF2 знают о своих трех непосредственно связанных маршрутах и трех маршрутах, перераспределенных в процессе маршрутизации. Итак, как мы видим, что когда речь заходит о routes redistributed IPv6, то не так уж много нового нужно узнать по сравнению с routes redistributed IPv4.
Всем привет! Сейчас мы расскажем об основных правилах, которые следует соблюдать при удаленном подключении телефона к IP-АТС. Актуально не только для Asterisk, но и для вообще любых IP-АТС.
Основные проблемы возникают из-за 3 факторов: Недостаточная пропускная способность сети, конфигурация межсетевых экранов и функционал инспектирования SIP-трафика. Но обо всём по порядку.
Пропускная способность (Bandwidth)
Давайте посчитаем, какая нам потребуется пропускная способность для одного звонка с использованием кодека G.711. При условии, что мы передаём голос в стандартной Ethernet – сети и будет задействован стек протоколов – IP/UDP/RTP :
По умолчанию, кодек G.711 формирует два голосовых семпла общей длительностью 20 мс, размер которых = 160 байт. Скорость потока, создаваемого G.711 = 64 Кбит/c
Заголовки канального уровня (Layer 2) потребуют ещё 18 байт
Заголовки сетевого уровня (IP - Layer 3) добавят ещё 20 байт
Далее заголовки UDP – ещё 8 байт
Наконец, RTP потребует 12 байт
Таким образом, общий размер пакета, в котором будет передаваться 20 мс голоса составит: 160 + 18 + 20 + 8 + 12 = 218 байт
Количество пакетов в секунду, формируемых G.711 = скорость потока кодека / размер голосовой нагрузки (сэмплов) = 64000 бит/c / (160 байт * 8 бит на байт) = 50 пакетов в секунду
Теперь мы можем посчитать полосу пропускания, необходимую для передачи 50 пакетов, содержащих 20 мс голоса, которые будут передаваться по сети. Полоса пропускания = 218 байт * 8 бит на байт * 50 = 87200 бит/с = 87.2 Кбит/c.
Рекомендуется ещё закладывать 5% в качестве защитного интервала: 87.2 * 1.05 = 91.56 Кбит/с
Вот примерно такой должна быть полоса пропускания интернет соединения со стороны подключения удалённого телефона, и на стороне IP-АТС. Если у одной из сторон будет медленное соединение, то качество голоса будет неудовлетворительным.
Зная параметры VoIP сети и используемого кодека, Вы без проблем сможете вычислить необходимую Вам полосу пропускания. Чтобы больше узнать про кодеки, рекомендуем почитать нашу статью.
Телефонный звонок – это симметричное соединение. Поэтому необходимо иметь минимум 91.56 Кбит/с как для входящего трафика (download speed), так и для исходящего (upload speed). Если удалённый пользователь имеет 10 Мб на скорость скачивания (download), то это ещё не значит, что он имеет сколько же на upload.
Но даже если наш удалённый пользователь будет иметь 10 Мб на скачивание и 512 Кбит на загрузку, это ещё не гарантирует нормальное VoIP соединение. Потому что полоса пропускания будет делиться между всеми активностями, которые пользователь совершает в Интернете. Догадайтесь - что будет, если наш пользователь находится в телефонном звонке, а кто-то в его сети начнёт скачивать тяжёлый файл или смотреть онлайн видео? При скачивании файлов задержка или потеря пакета может быть даже не заметна. А вот VoIP трафик передаётся в реальном времени и он очень чувствителен к задержкам и потерям пакетов. Любой из этих факторов может привести к срыву звонка.
Если Вы столкнулись с такой проблемой, рекомендуем настроить Quality of Service или Traffic Shaping. Данный функционал позволяет раздать приоритеты разным видам трафика на маршрутизаторе. Более подробно о механизме QoS можно почитать в нашей статье. А здесь примеры настройки на маршрутизаторе Mikrotik.
Межсетевой экран (Firewall)
Необходимо точно понимать, что удалённый телефон – это телефон, который подключается к Вашей IP-АТС не напрямую. Он не находится в Вашей локальной сети (LAN) и, что ещё важнее, он не находится в Вашей виртуальной локальной сети (VPN). Поэтому, для его корректной работы, нужно будет открыть кое какие порты на роутере или межсетевом экране.
5060 - По стандарту именно этот UDP порт используется протоколом SIP для обмена сигнальной информацией.
10000 – 20000 - (В большей степени актуально для Asterisk). UDP порты используются протоколом RTP и RTCP для передачи исходящего и приема входящего аудио трафика. Если вы столкнулись с проблемой односторонней слышимости или полным её отсутствием (при условии наличия сигнализации SIP) – скорее всего, дело в RTP портах на одной из сторон соединения.
69 TFTP / 21 FTP - Порты для обмена файлами. В IP-АТС используются для автоматической настройки и обновления телефонных аппаратов при помощи функции auto-provision.
Отнеситесь данному пункту очень серьёзно. Нельзя просто открывать эти порты всему миру. Необходимо также настроить правила, чтобы доступ к этим портам могли получить только доверенные устройства.
Если Вы используете Asterisk/FreePBX, то рекомендуем более подробно узнать какие ещё порты может понадобиться открыть вот тут.
Функционал испектирования SIP
SIP ALG (Application Layer Gateway) – это функционал, который испектирует SIP трафик, который проходит через маршрутизатор и позволяет модифицировать его так, чтобы не нужно было делать проброс портов для SIP и RTP.
Зачастую, администраторы, которые настраивают удалённый телефон для подключения к IP-АТС, сталкиваются именно с проблемами включенного на маршрутизаторе SIP ALG. Дело в том, что SIP ALG может изменить сигнальные пакеты так, что АТС не сможет их распознать и телефон не сможет нормально зарегистрироваться. Поэтому если Вы столкнулись с проблемой подключения телефона, рекомендуем также обратить внимание на функционал SIP ALG Вашего маршрутизатора.
Многие производители включают его по умолчанию. Мы же рекомендуем либо правильно настроить его в соответствии с инструкцией от производителя, либо, если никаких других вариантов не осталось – отключить его.
Вот примеры названий данного функционала у разных производителей, но все они значат одно и то же:
SIP ALG
SIP Helper
SIP Fixup
SIP Markup
SIP Translation
Например на роутерах Mikrotik, чтобы отключить данный функционал нужно зайти в IP → Firewall → Service Ports и убедиться, что сервис SIP выключен.
Либо отключить его используя CMD Mikrotik: /ip firewall service-port disable sip
Проблемы при подключении более 1 телефонного аппарата из одной и той же удаленной точки
Представьте, что Вы пытаетесь зарегистрировать два удалённых телефона на своей IP-АТС. Пусть их внутренние номера будут 100 и 101. Когда эти телефоны будут отправлять запрос регистрации, то Ваша IP-АТС получит его от удалённого роутера, за которым находятся эти телефоны и запрос этот будет от одного и того же IP адреса. Может быть эти телефоны и зарегистрируются на АТС, но когда на один из этих номеров будет поступать вызов, то удалённый маршрутизатор не сможет разобраться на какой из телефонов его отправлять 100 или 101.
Лучшим решением данной проблемы – будет организация виртуальной локальной сети (VPN) между удалёнными точками и IP-АТС. Тогда телефоны, находящиеся в удалённых офисах смогут регистрироваться на IP-АТС как если бы они находились в одной локальной сети.
Когда синхронизация менее важна, чем фактическая доставка, трафиком часто можно управлять с помощью метода взвешенной справедливой организации очереди на основе классов (CBWFQ). В CBWFQ участвующие классы трафика обслуживаются в соответствии с назначенной им политикой. Например, трафику, помеченному как AF41, может быть гарантирована минимальная пропускная способность. Для трафика, помеченного как AF21, также может быть гарантирована минимальная пропускная способность, возможно, меньшая, чем объем, предоставленный трафику AF41. Немаркированный трафик может получить любую оставшуюся полосу пропускания.
CBWFQ имеет понятие справедливости, когда различные классы трафика могут доставляться по перегруженному каналу. CBWFQ обеспечивает справедливое обслуживание пакетов в очереди в соответствии с политикой QoS. Пакеты будут отправляться всем классам трафика с назначенной им полосой пропускания.
Например, предположим, что пропускная способность канала составляет 1024 Кбит / с. Для класса трафика AF41 гарантирован минимум 256 Кбит / с. Для класса AF31 гарантирована скорость минимум 128 Кбит / с. Для класса AF21 гарантирована скорость минимум 128 Кбит / с. Это дает нам соотношение 2: 1: 1 между этими тремя классами. Остальные 512 Кбит / с не распределены, то есть доступны для использования другим трафиком. Включая нераспределенную сумму, полное соотношение составляет 256: 128: 128: 512, что сокращается до 2: 1: 1: 4.
Чтобы решить, какой пакет будет отправлен следующим, очередь обслуживается в соответствии с политикой CBWFQ. В этом примере пропускная способность 1024 Кбит / с делится на четыре части с соотношением 2: 1: 1: 4. Для простоты предположим, что перегруженный интерфейс будет обслуживать пакеты в очереди за восемь тактов:
Тактовый цикл 1. Будет отправлен пакет AF41.
Тактовый цикл 2. Будет отправлен еще один пакет AF41.
Тактовый цикл 3. Будет отправлен пакет AF31.
Тактовый цикл 4. Будет отправлен пакет AF21.
Тактовые циклы 5-8. Пакеты с другими классификациями, а также неклассифицированные пакеты будут отправлены.
В этом примере предполагается, что есть пакеты, представляющие каждый из четырех классов, находящихся в буфере, поставленных в очередь для отправки. Однако не всегда все бывает так однозначно. Что происходит, когда нет пакетов из определенного класса трафика для отправки, даже если есть место в гарантированном выделении минимальной полосы пропускания?
Гарантированная минимальная пропускная способность не является резервированием. Если класс трафика, которому назначен гарантированный минимум, не требует полного распределения, другие классы трафика могут использовать полосу пропускания. Также нет жестких ограничений гарантированного минимума пропускной способности. Если объем трафика для определенного класса превышает гарантированный минимум и полоса пропускания доступна, трафик для класса будет проходить с большей скоростью. Таким образом, происходящее могло бы выглядеть примерно так:
Тактовый цикл 1. Отправляется пакет AF41.
Тактовый цикл 2. Нет пакета AF41 для отправки, поэтому вместо него отправляется пакет AF31.
Тактовый цикл 3. Отправлен еще один пакет AF31.
Тактовый цикл 4. Нет пакета AF21 для отправки, поэтому отправляется неклассифицированный пакет.
Тактовые циклы 5-7. Отправляются пакеты с другими классификациями, а также неклассифицированные пакеты.
Тактовый цикл 8. Нет более классифицированных или неклассифицированных пакетов для отправки, поэтому отправляется еще один пакет AF31.
В результате неиспользованная полоса пропускания делится между классами с избыточным трафиком.
Перегрузка
CBWFQ не увеличивает пропускную способность перегруженного канала. Скорее, алгоритм предусматривает тщательно контролируемое совместное использование перенапряженного канала, отражающее относительную важность различных классов трафика. В результате совместного использования CBWFQ трафик доставляется через перегруженный канал, но с меньшей скоростью по сравнению с тем же каналом в незагруженное время.
Невозможно переоценить различие между "совместным использованием перегруженного канала" и "созданием полосы пропускания из ничего". Распространенное заблуждение о QoS заключается в том, что, несмотря на точки перегрузки на сетевом пути, взаимодействие с пользователем останется идентичным. Это совсем не так. Инструменты QoS, такие как CBWFQ, по большей части предназначены для того, чтобы максимально использовать плохую ситуацию. При выборе того, когда и когда пересылать трафик, QoS также выбирает, какой трафик отбрасывать. Среди потоков, передаваемых по сети, есть "победители" и "проигравшие".
LLQ является заметным исключением, поскольку предполагается, что трафик, обслуживаемый LLQ, настолько критичен, что он будет обслуживаться, исключая другой трафик, вплоть до назначенного ограничения полосы пропускания. LLQ стремится сохранить пользовательский опыт.
Другие инструменты управления перегрузкой QoS
Формирование трафика - это способ изящно ограничить классы трафика определенной скоростью. Например, трафик, помеченный как AF21, может иметь скорость 512 Кбит / с. Формирование изящное. Он допускает номинальные всплески выше определенного предела перед отбрасыванием пакетов. Это позволяет TCP более легко настраиваться на требуемую скорость. Когда пропускная способность сформированного класса трафика отображается на графике, результат показывает нарастание до предельной скорости, а затем постоянную скорость передачи на протяжении всего потока. Формирование трафика чаще всего применяется к классам трафика, заполненным слоновьими потоками.
Слоновидные потоки - это долговечные потоки трафика, используемые для максимально быстрого перемещения больших объемов данных между двумя конечными точками. Слоновые потоки могут заполнять узкие места в сети собственным трафиком, подавляя меньшие потоки. Распространенная стратегия QoS состоит в том, чтобы формировать скорость трафика слоновьих потоков, чтобы в узком месте оставалась достаточная пропускная способность для эффективного обслуживания других классов трафика.
Применение политик аналогично формированию трафика, но более жестко обращается с избыточным (несоответствующим) трафиком. Вместо того, чтобы допускать небольшой всплеск выше определенного предела пропускной способности, как при формировании перед сбросом, применение политик немедленно отбрасывает избыточный трафик. При столкновении с ограничителем трафика затронутый трафик увеличивается до предела пропускной способности, превышает его и отбрасывается. Такое поведение отбрасывания заставляет TCP заново запускать процесс наращивания мощности. Полученный график выглядит как пилообразный. Применение политик может использоваться для выполнения других задач, таких как перемаркировка несоответствующего трафика на значение DSCP с более низким приоритетом, а не отбрасывание.