По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Почитайте первую часть статьи. Первая проблема. Два роутера работают с одной областью OSPF, и каждый роутер имеет loopback интерфейс, объявленный в OSPF. Вот вывод таблиц маршрутизации: Как мы можем наблюдать, что роутер R1 узнал о сети 10.2.2.0/24 от роутера R2, но в таблице маршрутизации роутера R2 пусто. Что не так? Видно, что OSPF не включен на интерфейсе loopback0 роутера R1, так что же мы тогда объявляем в сетях? Похоже, мы объявляем сеть 10.10.1.0/24, но эта сеть не настроена ни на одном интерфейсе... Сеть 10.1.1.0/24 настроена на интерфейсе loopback0 роутера R1. Здесь вы видите неправильно введенную команду network. Удалим ее. R1(config)#router ospf 1 R1(config-router)#no network 10.10.1.1 0.0.0.0 area 0 R1(config-router)#network 10.1.1.0 0.0.0.255 area 0 Давайте удостоверимся, что команда network настроена правильно. Проблема устранена! Эта проблема может показаться не серьезной, но использование неправильных сетевых операторов - это то, что происходит постоянно. Особенно если мы используем меньшие подсети (например, /27 или /28 или аналогичные), люди склонны делать ошибки с обратными маскам. Итог урока: убедитесь, что вы настроили правильный сетевой адрес, обратную маску и область. Видео: протокол OSPF (Open Shortest Path First) за 8 минут Урок №2 Очередная возможная ситуация. Опять два роутера, но другая проблема. Вот таблицы маршрутизации: В очередной раз роутер R2 не увидел сеть 10.1.1.0/24. Что интересно, что роутер R1 не имеет сети 10.1.1.0/24 в своей таблице маршрутизации как непосредственно подключенной. Мы можем проверить, что роутер R1 использует правильную настройку команды network. Поскольку R1 даже не имеет сети в своей таблице маршрутизации, предположим, что проблема с интерфейсом. Кажется, кто-то забыл применить команду "no shutdown" на интерфейсе. R1(config)#interface loopback 0 R1(config-if)#no shutdown Давайте включим интерфейс. И теперь он появляется в таблице маршрутизации роутера R2. Итог урока: нельзя объявлять то, чего у тебя нет! Урок №3 Новый урок! Одна область, опять два роутера... мы хотели бы иметь "full connectivity", но не работает OSPF ... вот вывод таблиц маршрутизации: Роутер R1 не показывает никаких маршрутов OSPF, R2 показывает ... Необходимо выяснить, что не так: Быстро взглянем на роутер R2, чтобы убедиться, что он действительно объявляет правильную сеть(и). Да это так и есть. Вывод роутера R1 более интересен ... видно, что у него настроен distribute-list. В этом заключается наша проблема. Давайте удалим distribute-list. R1(config)#router ospf 1 R1(config-router)#no distribute-list 1 in Эта команда отключит его. Задача решена! Итог урока: знать о distribute-list, запрещающий объявление и / или установку префиксов в таблице маршрутизации. Урок №4 Взглянем на более сложные проблемы OSPF. На изображении выше мы имеем роутер R1 и роутер R2, но на этот раз мы имеем конфигурацию OSPF с несколькими областями. Вот конфигурация OSPF этих роутеров: Видно, что все сети были объявлены. Область 2 не связана напрямую с областью 0, поэтому была создана виртуальная связь. Роутер R1, однако, не увидел сеть 2.2.2.0/24 от роутера R2, но роутер R2 увидел сеть 1.1.1.0/24. Лучше всего начать с виртуальной линии здесь: Хм, это выглядит не очень хорошо. Виртуальная связь отключена. Обратите внимание на IP-адреса, которые мы видим здесь, это IP-адреса, настроенные на интерфейсах FastEthernet обоих маршрутизаторов. Всякий раз, когда мы настраиваем виртуальное соединение, нам нужно настроить идентификатор маршрутизатора OSPF другой стороны, а не IP-адрес другой стороны! Вот ошибка, так что давайте исправим ее. R1(config)#router ospf 1 R1(config-router)#no area 12 virtual-link 192.168.12.2 R1(config-router)#area 12 virtual-link 2.2.2.2 R2(config)#router ospf 1 R2(config-router)#no area 12 virtual-link 192.168.12.1 R2(config-router)#area 12 virtual-link 1.1.1.1 Вот так должна выглядеть virtual-link, настроенная между идентификаторами маршрутизаторов OSPF. Сразу после ввода правильных команд появятся данные сообщения в консоли. Запись OSPF для сети 2.2.2.0/24 появилась. Урок №5 Другая проблема. Те же роутеры, но появился "домен внешней маршрутизации". Это может быть другой протокол маршрутизации, такой как RIP или EIGRP, который мы будем распространять в OSPF. R2 перераспределяет сеть 2.2.2.0 / 24 в OSPF, но по какой-то причине она не отображается на R1. Чтобы было интересно, мы не будем просматривать конфигурацию OSPF на роутерах. Нет сети 2.2.2.0/24 на роутере R1, поэтому давайте изучим роутер R2. Как мы можем видеть, сеть находится в таблице маршрутизации роутера R2 как directly connected. Как мы можем видеть роутер R2 был настроен для перераспределения напрямую подключенных сетей. Это должно включать сеть 2.2.2.0/24 на интерфейса loopback0. Однако в базе данных OSPF пусто? Что может быть причиной этого? Возможно, вы помните правила различных типов областей OSPF. Давайте выясним, что это за область! Вот и объяснение, это stub area! Stub area не допускают LSA type 5 (внешние маршруты). Мы можем либо превратить эту область в normal area или NSSA. Давайте переведем в NSSA. R1(config)#router ospf 1 R1(config-router)#no area 12 stub R1(config-router)#area 12 nssa R2(config)#router ospf 1 R2(config-router)#no area 12 stub R2(config-router)#area 12 nssa Изменим тип области на обоих маршрутизаторах. Область NSSA допускает внешние маршруты с помощью LSA type 7. Наша сеть 2.2.2.0 / 24 теперь в базе данных OSPF маршрутизатора R2. Итог урока: Stub area не допускают внешних префиксов (LSA Type 5). Либо измените область на NSSA, либо прекратите перераспределение. Урок №6 Очередная проблема. Проблема default route OSPF. На рисунке имеются роутер R1 и роутер R2, и сеть 192.168.12.0 /24 объявленная в OSPF. Loopback интерфейсы роутера R2 не объявляется в OSPF, но мы используем default route, чтобы роутер R1 мог добраться до них. Здесь представлены конфигурации OSPF: Видно, что в выводе роутера R2 присутствует команда default-information originate для объявления default route. Увы, но мы не видим default route на роутере R1. Будем искать неполадки в настройке. Давайте проверим роутер R2: В таблице маршрутизации роутера R2 не виден default route. Чтобы OSPF объявлял default route, можно использовать два варианта: Убедитесь, что у вас есть default route в routing table (невозможно объявлять то, чего нет); Примените команду default-information originate always. Она объявит default route, даже если он не прописан. R2(config)#ip route 0.0.0.0 0.0.0.0 null 0 Выше первый метод решения проблемы. Мы создадим default route на роутере R2. Обычно указывается default route на ISP роутере, но сейчас другого роутера нет. Мы укажем default route для интерфейса null0, и он будет внесен в routing table. Правило работает! R2(config)#no ip route 0.0.0.0 0.0.0.0 null 0 R2(config)#router ospf 1 R2(config-router)#default-information originate always Итог урока: что бы объявить default route с помощью OSPF, вам нужно иметь default route в таблице маршрутизации или использовать ключевое слово "always". Урок №7 Немного сложнее проблема... те же два роутера , все в зоне 0. Вот настройки OSPF: Ничего особенного, все сети объявлены, и мы используем одну область. Увы ... таблицы маршрутизации пусты! По крайней мере, никакой отсутствует информация о OSPF ... Настройки network выглядят хорошо, так что это хороший момент вникнуть поглубже в OSPF LSDB. Давайте сначала проверим идентификаторы маршрутизатора OSPF: Здесь мы видим OSPF router ID. Если вы внимательно посмотрите на информацию выше, вы заметите что-то необычное. State full, но роутер R1 не выбрал DR / BDR, а роутер R2 выбрал роутер R1 в качестве BDR. Мы можем использовать команду show ip ospf database router для поиска информации от определенного соседа OSPF. Роутер R1 говорит нам, adv router is not-reachable. Это плохо. Роутер R2 также сообщает нам, что роутер R1 недоступен, и если вы посмотрите внимательно, то увидите, что он видит связь как point-to-point. Мы не видим этого в выводе на роутере R1. Это, вероятно, означает, что роутер R1 и роутер R2 используют другой тип сети OSPF, что приводит к разнице в LSDB. Это не позволит нашим роутерам устанавливать маршруты в таблицу маршрутизации! Теперь мы кое-что выяснили. Тип сети отличается ... широковещательная передача на роутере R2 и точка-точка на роутере R1. Нам действительно удалось установить соседство OSPF с этим, но возникает разница в LSDB. Произведем исправления. R1(config)#interface fa0/0 R1(config-if)#ip ospf network broadcast Изменение типа сети на роутере R1 сделает свое дело. Наконец "О" появляется в наших таблицах маршрутизации...проблема решена! Итог урока: убедитесь, что вы используете правильный тип сети OSPF на обоих роутерах. Урок №8 Очередная внештатная ситуация. OSPF настроено между роутерами R1 и R2, но не все сети объявлены. Loopback интерфейсы роутера R2 перераспределяются в OSPF. Вот настройки обоих роутеров: Мы наблюдаем команду redistribute connected на роутере R2, которая должна перераспределить сети на интерфейсах обратной связи в OSPF. Однако здесь ничего нет ... Обычно было бы неплохо проверить, есть ли distribute list или нет. Ключ к решению этой проблемы - эта команда. Если вы наберете redistribute connected OSPF будет распространять только classful networks. R2(config)#router ospf 1 R2(config-router)#redistribute connected subnets Нам нужно добавить параметр "subnets", позволяющий заставить его выполнять redistribute subnet основных сетей. Ну вот, наша маршрутная таблица заполнена. Итог урока: добавьте параметр " subnets " при использовании перераспределения или перераспределяются только classful networks.
img
Предыдущий материал из цикла про ARP в IPv4. Ждет вас по ссылке. Как хост может узнать, следует ли пытаться отправить пакет хосту через сегмент, к которому он подключен, или отправить пакет на маршрутизатор для дальнейшей обработки? Если хост должен отправлять пакеты на маршрутизатор для дальнейшей обработки, как он может узнать, на какой маршрутизатор (если их несколько) отправлять трафик? Эти две проблемы вместе составляют проблему шлюза по умолчанию. Для IPv4 проблему довольно легко решить, используя префикс и длину префикса. Рисунок ниже демонстрирует нам это. Реализации IPv4 предполагают, что любой хост в пределах одной подсети IPv4 должен быть физически подключен к одному проводу. Как реализация может определить разницу? Маска подсети - это еще одна форма длины префикса, которая указывает, где заканчивается сетевой адрес и начинается адрес хоста. В этом случае предположим, что длина префикса равна 24 битам, или сетевой адрес равен /24. 24 указывает вам, сколько битов задано в маске подсети: 24 bits = 11111111.11111111.11111111.0000000 Поскольку в IPv4 используется десятичная запись маски, это также можно записать как 255.255.255.0. Чтобы определить, находится ли C на том же проводе, что и A, A будет: Логическое умножение маски подсети с адресом локального интерфейса Логическое умножение маски подсети с адресом назначения Сравните два результата; если они совпадают, целевой хост находится на том же канале связи, что и локальный интерфейс На рисунке ниже это продемонстрировано. На рисунке выше показано четыре IPv4-адреса; предположим, что A должен отправлять пакеты в C, D и E. Если A знает, что длина префикса локального сегмента составляет 24 бита либо с помощью ручной настройки, либо с помощью DHCPv4, то он может просто посмотреть на 24 наиболее значимых бита каждого адреса, сравнить его с 24 наиболее значимыми битами своего собственного адреса и определить, находится ли пункт назначения на сегменте или нет. Двадцать четыре бита IPv4-адреса создают хороший разрыв между третьей и четвертой секциями адреса (каждая секция IPv4-адреса представляет собой 8 бит адресного пространства, в общей сложности 32 бита адресного пространства). Любые два адреса с такими же левыми тремя секциями, что и у A, называемые сетевым адресом, находятся в одном сегменте; любой адрес, которого нет в сегменте. В этом случае сетевой адрес для A и C совпадает, поэтому A будет считать, что C находится в одном сегменте, и, следовательно, будет отправлять пакеты C напрямую, а не отправлять их на маршрутизатор. Для любого пункта назначения, который A считает вне сегмента, он будет отправлять пакеты на IPv4-адрес конечного пункта назначения, но на MAC-адрес шлюза по умолчанию. Это означает, что маршрутизатор, выступающий в качестве шлюза по умолчанию, примет пакет и переключит его на основе IPv4-адреса назначения. Как выбирается шлюз по умолчанию? Он либо настраивается вручную, либо включается в параметр DHCPv4. А что насчет D? Поскольку сетевые части адресов не совпадают, A будет считать, что D находится вне сегмента. В этом случае A отправит любой трафик для D на свой шлюз по умолчанию, которым является B. Когда B получит эти пакеты, он поймет, что A и D достижимы через один и тот же интерфейс (на основе своей таблицы маршрутизации), поэтому он будет отправлять ICMP-перенаправление на A, говоря ему, что нужно отправлять трафик на D напрямую, а не через B. IPv6 представляет собой более сложный набор проблем, которые необходимо решить при выборе шлюза по умолчанию, потому что IPv6 предполагает, что одно устройство может иметь много адресов IPv6, назначенных конкретному интерфейсу. Рисунок ниже демонстрирует это. На рисунке выше предположим, что администратор сети настроил следующие политики: Ни один хост не может подключаться к A, если у него нет адреса в диапазоне адресов 2001: db8: 3e8: 110 ::/64. Ни один хост не может подключиться к D, если у него нет адреса в диапазоне адресов 2001: db8: 3e8: 112 ::/64. Примечание: В реальном мире вы никогда не построили бы такую политику; это надуманная ситуация, чтобы проиллюстрировать проблему, поставленную в сети минимального размера. Гораздо более реальной проблемой такого же типа была бы одноадресная переадресация обратного пути (uRPF). Чтобы эти политики работали, администратор назначил 110::3 и 112::12 хосту C и 111::120 хосту F. Это может показаться странным, но совершенно законно для одного сегмента иметь несколько подсетей IPv6, назначенных в IPv6; также совершенно законно иметь одно устройство с несколькими адресами. На самом деле, в IPv6 существует множество ситуаций, когда одному устройству может быть назначен диапазон адресов. Однако с точки зрения длины префикса нет двух адресов, назначенных C или F, в одной подсети. Из-за этого IPv6 не полагается на длину префикса, чтобы определить, что находится в сегменте, а что нет. Вместо этого реализации IPv6 ведут таблицу всех подключенных хостов, используя запросы соседей, чтобы определить, что находится в сегменте, а что нет. Когда хост хочет отправить трафик из локального сегмента, он отправляет трафик на один из маршрутизаторов, о котором он узнал из объявлений маршрутизатора. Если маршрутизатор получает пакет, к которому, как он знает, другой маршрутизатор в сегменте имеет лучший маршрут (поскольку у маршрутизаторов есть таблицы маршрутизации, которые говорят им, какой путь выбрать к какому-либо конкретному месту назначения), маршрутизатор отправит сообщение перенаправления ICMPv6, сообщающее хосту использовать какой-либо другой маршрутизатор первого перехода для достижения пункта назначения. В следующей статьей мы поговорим про пакетную коммутацию.
img
Привет! Сегодня в статье мы поговорим о настройке Music on Hold Server в Cisco Unified Communications Manager (CUCM) . Music on Hold – это музыка, которая проигрывается абоненту, когда он поставлен на удержание. Сервер может быть Multicast, когда используется один аудиопоток, посылаемый на групповой адрес, и Unicast, когда для каждого поставленного на удержания вызова используется отдельный аудиопоток. Файлы, которые будут использоваться для Music on Hold должны отвечать следующим требованиям: Формат .WAV (16 Bit PCM); Mono или Stereo; Частота дискретизации – 8, 16, 32 или 48 кГц; Настройка Music on Hold в CUCM Для начала загрузим аудиофайл на наш CUCM. Для этого переходим в раздел Media Resources – MOH Audio File Management. В новом окне нажимаем Upload File и указываем его месторасположение. Файл будет переконвертирован в формат нужного кодека. После этого он появится в таблице. Затем переходим во вкладку Media Resources – Music on Hold Audio Source и нажимаем Add New для создания нового потока Music on Hold. Тут в поле MOH Audio Stream Number указываем номер нашего потока (начиная с 2, т.к. первый номер занят за стандартным потоком). В строке MOH Audio Source File в выпадающем меню выбираем загруженный нами аудиофайл, а в строке MOH Audio Source Name указываем его имя. Также здесь можно включить Multicasting и повтор проигрывания. Далее переходим во вкладку Media Resources – Music on Hold Server. Если там ничего нет, то нужно перейти во вкладку Cisco Unified Serviceability – Tools – Service Activation и поставить галочку напротив пункта IP Voice Media Streaming Application для активации сервиса и после этого сервер будет автоматически создан. Теперь можно выбрать сервер и перейти на страницу его настроек. Для того чтобы выбрать поток Music on Hold на телефоне нужно перейти во вкладку Device – Phone, найти желаемый телефон и в строках User Hold MOH Audio Source и Network Hold MOH Audio Source выбрать созданный поток.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59