По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В предыдущих статьях были рассмотрены три обширные задачи, которые должна решать каждая плоскость управления для сети с коммутацией пакетов, и рассмотрен ряд решений для каждой из этих задач. Первой рассматриваемой задачей было определение топологии сети и ее доступности. Во-вторых, вычисление свободных от петель (и, в некоторых случаях, непересекающихся) путей через сеть. Последняя задача- это реакция на изменения топологии, на самом деле представляет собой набор задач, включая обнаружение и сообщение об изменениях в сети через плоскость управления.
В этой серии лекций мы объединим эти заждачи и решения путем изучения нескольких реализаций распределенных плоскостей управления, используемых для одноадресной пересылки в сетях с коммутацией пакетов. Реализации здесь выбраны не потому, что они широко используются, а потому, что они представляют собой ряд вариантов реализации среди решений, описанных в предыдущих лекциях. В каждом конкретном случае рассматривается базовая работа каждого протокола; в последующих статьях мы будем углубляться в вопросы сокрытия информации и другие более сложные темы в плоскостях управления, поэтому здесь они не рассматриваются.
Классификация плоскости управления
Плоскости управления обычно классифицируются по двум характеристикам. Во-первых, они разделяются в зависимости от того, где вычисляются loop-free пути, будь то на передающем устройстве или выключенном. Плоскости управления, в которых фактические коммутационные устройства непосредственно участвуют в расчете loop-free путей, затем разделяются на основе вида информации, которую они несут о сети. Классификация, основанная на алгоритме, используемом для вычисления loop-free путей, отсутствует, хотя это часто тесно связано с типом информации, передаваемой плоскостью управления.
В то время как централизованные плоскости управления часто связаны с несколькими (или одним, концептуально) контроллерами, собирающими информацию о достижимости и топологии от каждого коммутационного устройства, вычисляющими набор loop-free путей и загружающими полученную таблицу пересылки на коммутационные устройства, концепция гораздо менее строгая. Ц В более общем смысле централизованная плоскость управления означает просто вычисление некоторой части информации о пересылке где-нибудь, кроме фактического устройства пересылки. Это может означать отдельное устройство или набор устройств; это может означать набор процессов, запущенных на виртуальной машине; это может означать вычисление всей необходимой информации о пересылке или (возможно) большей ее части.
Плоскости распределенного управления обычно различаются тремя общими характеристиками:
Протокол, работающий на каждом устройстве и реализующий различные механизмы, необходимые для передачи информации о доступности и топологии между устройствами.
Набор алгоритмов, реализованных на каждом устройстве, используемый для вычисления набора loop-free путей к известным пунктам назначения.
Способность обнаруживать и реагировать на изменения доступности и топологии локально на каждом устройстве.
В распределенных плоскостях управления не только каждый прыжок (hop by hop) с коммутацией пакетов, но и каждый прыжок определяет набор loop-free путей для достижения любого конкретного пункта назначения локально. Плоскости распределенного управления обычно делятся на три широких класса протоколов: состояние канала, вектор расстояния и вектор пути.
В протоколах состояния канала каждое устройство объявляет состояние каждого подключенного канала, включая доступные пункты назначения и соседей, подключенных к каналу. Эта информация формирует базу данных топологии, содержащую каждое звено, каждый узел и каждый достижимый пункт назначения в сети, через который алгоритм, такой как Dijkstra или Suurballe, может быть использован для вычисления набора loop-free или непересекающихся путей. Протоколы состояния канала обычно заполняют свои базы данных, поэтому каждое устройство пересылки имеет копию, которая синхронизируется с каждым другим устройством пересылки.
В протоколах вектора расстояния каждое устройство объявляет набор расстояний до известных достижимых пунктов назначения. Эта информация о достижимости объявляется конкретным соседом, который предоставляет векторную информацию или, скорее, направление, через которое может быть достигнут пункт назначения. Протоколы вектора расстояния обычно реализуют либо алгоритм Bellman-Ford, либо алгоритм Garcia-Luna’s DUAL, либо аналогичный алгоритм для расчета маршрутов без петель в сети.
В протоколах вектора пути, путь к пункту назначения, записывается по мере того, как объявление о маршрутизации проходит через сеть, от узла к узлу. Другая информация, такая как показатели, может быть добавлена для выражения некоторой формы политики, но первичный, свободный от петель, характер каждого пути вычисляется на основе фактических путей, по которым объявления проходят через сеть.
На рисунке 1 показаны эти три типа распределенных плоскостей управления.
На рисунке 1:
В примере состояния связи- вверху каждое устройство объявляет, что оно может достичь любе друге устройство в сети. Следовательно, A объявляет достижимость B, C и D; в то же время D объявляет достижимость 2001:db8:3e8:100::/64 и C, B и A.
В примере вектора расстояния - в середине D объявляет достижимость до 2001:db8:3e8:100:: 24 до C с его локальной стоимостью, которая равна 1. C добавляет стоимость [D,C] и объявляет достижимость до 2001:db8:3e8:100::64 со стоимостью 2 до B.
В примере вектора пути - внизу D объявляет о достижимости до 2001:db8:3e8:100::/24 через себя. C получает это объявление и добавляет себя к [D,C].
Плоскости управления не всегда аккуратно вписываются в ту или иную категорию, особенно когда вы переходите к различным формам сокрытия информации. Некоторые протоколы состояния канала, например, используют принципы вектора расстояния с агрегированной информацией, а протоколы вектора пути часто используют некоторую форму расположения метрик вектора расстояния для увеличения пути при вычислении loop-free путей. Эти классификации - централизованный, вектор расстояния, состояние канала и вектор пути - важны для понимания и знакомства с миром сетевой инженерии.
До сих пор в этой серии статей примеры перераспределения маршрутов, над которыми мы работали, использовали один роутер, выполняющий перераспределение между нашими автономными системами. Однако с точки зрения проекта, глядя на этот роутер понимаем, что это единственная уязвимая точка, то есть точка отказа.
Для избыточности давайте подумаем о добавлении второго роутера для перераспределения между несколькими автономными системами. То, что мы, вероятно, не хотим, чтобы маршрут объявлялся, скажем, из AS1 в AS2, а затем AS2 объявлял тот же самый маршрут обратно в AS1, как показано на рисунке.
Хорошая новость заключается в том, что с настройками по умолчанию, скорее всего не будет проблем. Например, на приведенном выше рисунке роутер CTR2 узнал бы два способа добраться до Сети A. Один из способов — это через OSPF, к которому он подключен. Другой путь был бы через EIGRP AS, через роутер CTR1 и обратно в OSPF AS. Обычно, когда роутер знает, как добраться до сети через два протокола маршрутизации, он сравнивает значения административного расстояния (AD) протоколов маршрутизации и доверяет протоколу маршрутизации с более низким AD. В этом примере, хотя EIGRP AD обычно составляет 90, что более правдоподобно, чем OSPF AD 110, AD EIGRP External route (т. е. маршрута, который возник в другом AS) составляет 170. В результате OSPF-изученный маршрут CTR2 к сети A имеет более низкую AD (т. е. 110), чем AD (т. е. 170) EIGRP-изученного маршрута к сети A. Что в итоге? CTR2 отправляет трафик в Сеть A, отправляя этот трафик в OSPF AS, без необходимости передавать EIGRP AS.
Время от времени, однако, нам потребуется произвести настройки некоторых не дефолтных параметров AD, или же нам понадобятся creative metrics, применяемые к перераспределенным маршрутам. В таких случаях мы подвергаемся риску развития событий, описанных на предыдущем рисунке.
Давайте обсудим, как бороться с такой проблемой. Рассмотрим следующую топологию.
В этой топологии у нас есть две автономные системы, одна из которых работает под управлением OSPF, а другая- под управлением EIGRP. Роутеры CTR1 и CTR2 в настоящее время настроены для выполнения взаимного перераспределения маршрутов между OSPF и EIGRP. Давайте взглянем на таблицы IP-маршрутизации этих магистральных роутеров.
Обратите внимание, в приведенном выше примере, что с точки зрения роутера CTR2, лучший способ добраться до Сети 192.0.2.0 / 30 — это next-hop на следующий IP-адрес 192.0.2.5 (который является роутером OFF1). Это означает, что если бы роутер CTR2 хотел отправить трафик в сеть 192.0.2.0 /30, то этот трафик остался бы в пределах OSPF AS. Интересно, что процесс маршрутизации EIGRP, запущенный на роутере CTR2, также знает, как добраться до Сети 192.0.2.0 / 30 из-за того, что роутер CTR1 перераспределяет этот маршрут в Интересно, что процесс маршрутизации EIGRP, запущенный на роутере CTR2, также знает, как добраться до Сети 192.0.2.0 / 30 из-за того, что роутер CTR1 перераспределяет этот маршрут в EIGRP AS, но этот маршрут считается EIGRP External route. Поскольку EIGRP External route AD 170 больше, чем OSPF AD 110, в OSPF маршрут прописывается в таблице IP-маршрутизации роутера CTR2.
Именно так обычно работает Route redistribution, когда у нас есть несколько роутеров, выполняющих перераспределение маршрутов между двумя автономными системами. Однако, что мы можем сделать, если что-то идет не так, как ожидалось (или как мы хотели)? Как мы можем предотвратить перераспределение маршрута, перераспределенного в AS, из этого AS и обратно в исходное AS, например, в примере, показанном на следующем рисунке.
В приведенном выше примере роутер OFF1 объявляет сеть 192.168.1.0 / 24 роутеру CTR1, который перераспределяет этот маршрут из AS1 в AS2. Роутер OFF2 получает объявление маршрута от роутера CTR1 и отправляет объявление для этого маршрута вниз к роутеру CTR2. Роутер CTR2 затем берет этот недавно изученный маршрут и перераспределяет его от AS2 к AS1, откуда он пришел. Мы, скорее всего, не хотим, чтобы это произошло, потому что это создает неоптимальный маршрут.
Общий подход к решению такой проблемы заключается в использовании route map в сочетании с tag (тегом). В частности, когда маршрут перераспределяется из одного AS в другой, мы можем установить тег на этом маршруте. Затем мы можем настроить все роутеры, выполняющие перераспределение, чтобы блокировать маршрут с этим тегом от перераспределения обратно в его исходный AS, как показано на следующем рисунке.
Обратите внимание, что в приведенной выше топологии, когда маршрут перераспределяется от AS1 к AS2, он получает тег 10. Кроме того, роутер CTR2 имеет инструкцию (настроенную в карте маршрутов), чтобы не перераспределять любые маршруты из AS2 в AS1, которые имеют тег 10. В результате маршрут, первоначально объявленный роутером OFF1 в AS1, никогда не перераспределяется обратно в AS1, тем самым потенциально избегая неоптимального маршрута.
Далее давайте еще раз рассмотрим, как мы можем настроить этот подход к тегированию, используя следующую топологию. В частности, на роутерах CTR1 и CTR2 давайте установим тег 10 на любом маршруте, перераспределяемом из OSPF в EIGRP. Затем, на тех же самых роутерах, мы предотвратим любой маршрут с тегом 10 от перераспределения из EIGRP обратно в OSPF.
Для начала на роутере CTR1 мы создаем карту маршрутов, целью которой является присвоение тегу значения 10.
CTR1 # conf term
CTR1 (config) # route-map TAG10
CTR1 (config-route-map) # set tag 10
CTR1 (config-route-map) #exit
CTR1 (config) #
Обратите внимание, что мы не указали permit как часть инструкции route-map, и мы не указали порядковый номер. Причина в том, что permit — это действие по умолчанию, и карта маршрута TAG10 имела только одну запись.
Далее мы перейдем к роутеру CTR2 и создадим карту маршрутов, которая предотвратит перераспределение любых маршрутов с тегом 10 в OSPF. Кроме того, мы хотим, чтобы роутер CTR2 маркировал маршруты, которые он перераспределяет из OSPF в EIGRP со значением тега 10. Это означает, что мы хотим, чтобы роутер CTR1 предотвратил перераспределение этих маршрутов (со значением тега 10) обратно в OSPF. Итак, пока мы находимся здесь на роутере CTR1, давайте настроим route-map, которая предотвратит Route redistribution со значением тега 10 в OSPF.
CTR1 (config) # route-map DENYTAG10 deny 10
CTR1 (config-route-map) # match tag 10
CTR1 (config-route-map) # exit
CTR1 (config) # route-map DENYTAG10 permit 20
CTR1 (config-route-map) # end
CTR1 #
Эта недавно созданная route-map (DENYTAG10) использует ключевые слова permit и deny, и у нее есть порядковые номера. Порядковый номер 10 используется для запрещения маршрутов с тегом 10. Затем имеем следующий порядковый номер (который мы пронумеровали 20), чтобы разрешить перераспределение всех других маршрутов.
Теперь, когда мы создали наши две карты маршрутов, давайте применим TAG10 route map к команде EIGRP redistribute (к тегу routes, перераспределяемому в EIGRP со значением 10). Кроме того, мы хотим применить DENYTAG10 route map к команде OSPF redistribute (чтобы предотвратить перераспределение маршрутов, помеченных значением 10, обратно в OSPF AS).
CTR1 # conf term
CTR1 (config) # router eigrp 100
CTR1 (config-router) # redistribute ospf 1 route-map TAG10
CTR1 (config-router) # router ospf 1
CTR1 (config-router) # redistribute eigrp 100 subnets route-map DENYTAG10
CTR1 (config-router) # end
CTR1 #
Теперь нам нужно ввести зеркальную конфигурацию на роутере CTR2.
CTR2#conf term
CTR2(config)#route-map TAG10
CTR2(config-route-map) # set tag 10
CTR2(config-route-map) # exit
CTR2(config)#route-map DENYTAG10 deny 10
CTR2(config-route-map) # match tag 10
CTR2(config-route-map) # exit
CTR2(config) # route-map DENYTAG10 permit 20
CTR2(config-route-map) # exit
CTR2(config) # router eigrp 100
CTR2(config-router) # redistribute ospf 1 route-map TAG10
CTR2(config-router) # router ospf 1
CTR2(config-router) # redistribute eigrp 100 subnets route-map DENYTAG10
CTR2(config-router) # end
CTR2#
Просто чтобы убедиться, что наши маршруты помечены, давайте проверим таблицу топологии EIGRP роутера OFF2.
Обратите внимание, что все маршруты, перераспределенные в EIGRP из OSPF, теперь имеют тег 10, и мы сказали роутерам CTR1 и CTR2 не перераспределять эти маршруты обратно в OSPF. Именно так мы можем решить некоторые потенциальные проблемы, возникающие при перераспределении маршрутов.
Дело за малым - прочитайте нашу статью про route redistribution с помощью IPv6.
Мы продолжаем знакомить вас настойкой телефонов, и сегодня с IP-АТС Asterisk мы свяжем телефон Yealink SIP-T46S.
$dbName_ecom = "to-www_ecom";
$GoodID = "6355410825";
mysql_connect($hostname,$username,$password) OR DIE("Не могу создать соединение ");
mysql_select_db($dbName_ecom) or die(mysql_error());
$query_ecom = "SELECT `model`, `itemimage1`, `price`, `discount`, `url`, `preview115`, `vendor`, `vendorCode` FROM `items` WHERE itemid = '$GoodID';";
$res_ecom=mysql_query($query_ecom) or die(mysql_error());
$row_ecom = mysql_fetch_array($res_ecom);
echo 'Кстати, купить '.$row_ecom['vendor'].' '.$row_ecom['vendorCode'].' можно в нашем магазине Merion Shop по ссылке ниже. С настройкой поможем 🔧
Купить '.$row_ecom['model'].''.number_format(intval($row_ecom['price']) * (1 - (intval($row_ecom['discount'])) / 100), 0, ',', ' ').' ₽';
$dbName = "to-www_02";
mysql_connect($hostname,$username,$password) OR DIE("Не могу создать соединение ");
mysql_select_db($dbName) or die(mysql_error());
Настройка
Первым делом после подключения телефона к сети нам нужно зайти на его веб-интерфейс, для начала настройки. Там нас встретит входное меню авторизации. Для телефона Yealink SIP-T46S стандартный логин – admin, пароль – admin.
После ввода логина и пароля мы попадаем в меню Статус. Чтобы начать настройку нам нужно перейти в меню Аккаунт
Тут нужно выбрать какой из 16-ти SIP-аккаунтов мы будем использовать и заполнить следующие поля:
Аккаунт – Выбираем какой аккаунт нам нужно настроить
Аккаунт – Включено
Лейбл – Отображаемое название трубки
Отображаемое имя – Имя которое будет отображаться при вызове
Имя регистрации – Указываем наш внутренний номер
Имя пользователя – Указываем наш внутренний номер
Пароль – Пароль для выбранного номера
Адрес SIP-сервера – IP-адрес нашей IP-АТС
Порт – Указываем номер порта
После этого сохраняем и на этой же странице в строке Статус должна появиться надпись Зарегистрировано. Готово! Теперь телефон может звонить.
Для изменения основных сетевых настроек мы можем посетить меню Сеть.
А Если нужно назначить дополнительные программируемые DSS кнопки (например, BLF), то это можно сделать в меню DSS-кнопки.