По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Данная статья будет посвящена монтажу и проектированию структурированной кабельной системы (СКС). СКС представляет собой совокупность кабельных соединительных линий, коммутационного оборудования и методику их эксплуатирования, позволяющую создавать масштабируемую структуру связи в сетях различного назначения.
На сегодняшний день проектирование и монтаж СКС регламентируется тремя основными стандартами, описывающие основные характеристики и параметры для кабельных систем общего назначения:
TIA/EIA-568B Commercial Building Telecommunications Wiring Standard (американский стандарт)
ISO/IEC IS 11801-2002 Information Technology. Generic cabling for customer premises (международный стандарт)
CENELEC EN 50173 Information Technology. Generic cabling systems (европейский стандарт)
СКС является фундаментом корпоративной сети передачи данных, а именно обеспечивает физическую среду для распространения сигнала, поэтому при планировке офисного пространства следует уделить особое внимание данному фактору. В дальнейшем, СКС необходима для реконфигурации, модифицирования или масштабирования корпоративной сети. Например, если требуется разместить новых сотрудников компании.
К проектированию СКС следует подходить в несколько этапов. Обычно СКС имеет магистральную и горизонтальную подсистемы. Магистральная подсистема нужна для связи между распределительными пунктами зданий и этажей. В состав магистрально подсистемы входят линии, соединяющие между собой коммутационные центры (кроссы). Данные центры служат для распределения телекоммуникационной нагрузки (передача данных, голоса, видео и так далее).
Горизонтальная подсистема объединяет пользователей в общую сеть для доступа к магистральным ресурсам. В данную подсистему входят соединительные линии, соединяющие розетки на рабочих местах с горизонтальным кроссом. Следует проектировать горизонтальную подсистему с техническим запасом на случай масштабирования сети и появления нового активного оборудования.
Для увеличения срока службы СКС закладывают резерв по пропускной способности. Такой подход неизбежно увеличивает цену проектирования, однако повышается избыточность проектируемой системы, и, как следствие, уменьшаются эксплуатационные издержки.
Проектирование СКС следует начинать с предпроектного обследования ландшафта, по средствам визуального осмотра и изучения технической документации. Необходимо учесть все особенности архитектуры здания, положение рабочих мест, толщину и материал стен, высоту потолков, дверных проемов, окон и т.д.
Предпроектное обследование обеспечивает высокое качество внедрения
Эта проектирования
На этапе разработки проекта по данным, полученным по результатам предпроектного обследования, составляю схемы и чертежи будущей СКС. Основными являются:
Структурная схема
На структурной схеме СКС показывают основные функциональные элементы Структурированной Кабельной Системы (СКС) и связи между ними.
Функциональная схема
Отображает качественно-количественные параметры функциональных элементов СКС
Рабочая документация
Содержит в себе правила эксплуатирования СКС, параметры всех установленных каналов связи, а также маркировку и расположение всех элементов проектируемой инфраструктуры
Этап проектирования завершается согласованием всех выше упомянутых документов с заказчиком.
Монтажные работы
После того как разработан проект СКС можно приступать к монтажным работам, которые также следует проводить в несколько этапов.
Подготовка объекта
Включает в себя работы по сверлению стен под кабельные трассы
Монтаж кабельных коробок, лотков и труб
Включает в себя работы по установке сооружений, в которых будет проложен кабель
Укладка проводов
Выполняется, когда установлены все лотки и кабельные коробки
Установка розеток
Включает в себя работы по установке розеток в короб или на стену
Кроссирование и тестирование патч-панелей
Включает в себя установку и заделку кабелей в коммутационные панели, а также проверку на правильность разводки, кроссировки и отсутствие наводок от силовых сетей.
На сегодняшний день СКС стала неотъемлемой частью любой современной компании. От того насколько грамотно и правильно она спроектирована будет зависеть не только удобство, но и эффективность работы в Вашем офисе.
Специалисты нашей компании предлагают полный спектр услуг по проектированию и монтажу СКС от составления проектной документации до внедрения и обслуживания.
До сих пор в этой серии статей примеры перераспределения маршрутов, над которыми мы работали, использовали один роутер, выполняющий перераспределение между нашими автономными системами. Однако с точки зрения проекта, глядя на этот роутер понимаем, что это единственная уязвимая точка, то есть точка отказа.
Для избыточности давайте подумаем о добавлении второго роутера для перераспределения между несколькими автономными системами. То, что мы, вероятно, не хотим, чтобы маршрут объявлялся, скажем, из 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.
В этой статье мы рассмотрим протокол маршрутизации Cisco EIGRP. EIGRP (Enhanced Interior Gateway Routing Protocol) - это протокол расширенной векторной маршрутизации, который должен устанавливать отношения соседства перед отправкой обновлений. Из-за этого первое, что нам нужно сделать, это проверить, правильно ли работает соседство. Если это так, мы можем продолжить, проверив, объявляются сети или нет. В этой статье рассмотрим все, что может пойти не так с EIGRP, как это исправить и в каком порядке. Давайте начнем с проверки соседства!
Существует ряд элементов, которые вызывают проблемы соседства EIGRP:
Неизвестная подсеть: соседи EIGRP с IP-адресами, которые не находятся в одной подсети.
Несоответствие значений K: по умолчанию пропускная способность и задержка включены для расчета метрики. Мы можем включить нагрузку и надежность, но мы должны сделать это на всех маршрутизаторах EIGRP.
Несоответствие AS: номер автономной системы должен совпадать на обоих маршрутизаторах EIGRP, чтобы сформировать соседство.
Проблемы уровня 2: EIGRP работает на уровне 3 модели OSI. Если уровни 1 и 2 не работают должным образом, у нас будут проблемы с формированием соседства.
Проблемы со списком доступа: возможно, кто-то создал список доступа, который отфильтровывает многоадресный трафик. EIGRP по умолчанию использует 224.0.0.10 для связи с другими соседями EIGRP.
NBMA: по умолчанию Non Broadcast Multi Access сети, такие как Frame Relay, не разрешают широковещательный или многоадресный трафик. Это может препятствовать тому, чтобы EIGRP формировал соседние отношения EIGRP.
OFF1(config)#int f0/0
OFF1(config-if)#ip address 192.168.12.1 255.255.255.0
OFF1(config-if)#router eigrp 12
OFF1(config-router)#network 192.168.12.0
OFF2(config)#int f0/0
OFF2(config-if)#ip address 192.168.21.2 255.255.255.0
OFF2(config)#router eigrp 12
OFF2(config-router)#network 192.168.21.0
Ошибку неверной подсети легко обнаружить. В приведенном выше примере у нас есть 2 маршрутизатора, и вы можете видеть, что были настроены разные подсети на каждом интерфейсе.
После включения EIGRP всплывают следующие ошибки:
Оба маршрутизатора жалуются, что находятся не в одной подсети.
OFF2(config-router)#int f0/0
OFF2(config-if)#ip address 192.168.12.2 255.25
OFF2(config)#router eigrp 12
OFF2(config-router)#no network 192.168.21.0
OFF2(config-router)#network 192.168.12.0
Мы изменили IP-адрес на OFF2 и убедились, что для EIGRP правильно настроена команда network.
Вуаля! Теперь у нас есть соседство EIGRP.
Проверим это с помощью команды show ip eigrp neighbors.
Извлеченный урок: убедитесь, что оба маршрутизатора находятся в одной подсети.
Case #2
На этот раз IP-адреса верны, но мы используем разные значения K с обеих сторон. OFF1 включил пропускную способность, задержку, нагрузку и надежность. OFF2 использует только пропускную способность и задержку.
Эту ошибку легко обнаружить, поскольку сообщение в консоли гласит "Несоответствие K-значений" на обоих маршрутизаторах.
Мы можем проверить нашу конфигурацию, посмотрев ее на обоих маршрутизаторах. Как вы видите, что значения K были изменены на OFF1.
OFF2(config)#router eigrp 12
OFF2(config-router)#metric weights 0 1 1 1 1 0
Давайте убедимся, что значения K одинаковы на обоих маршрутизаторах, так как мы изменили их на OFF2.
После изменения значений K у нас появилось соседство EIGRP-соседей.
Еще одна проблема решена!
Извлеченный урок: убедитесь, что значения K одинаковы на всех маршрутизаторах EIGRP в одной и той же автономной системе.
Case #3
Давайте продолжим со следующей ошибкой ...
Вот еще один пример типичной проблемы. Несоответствие номера AS. Когда мы настраиваем EIGRP, мы должны ввести номер AS. В отличие от OSPF (который использует ID процесса) этот номер должен быть одинаковым на обоих маршрутизаторах.
В отличие от других неверных настроек конфигурации EIGRP, эта проблема не выдает сообщение об ошибке. Используем команду show ip eigrp neighbors и видим, что соседей нет. Внимательно изучите выходные данные, чтобы обнаружить различия, и вы увидите, что маршрутизаторы используют разные номера AS.
Если посмотреть на работающую конфигурацию, и мы увидим то же самое.
Давайте изменим номер AS на OFF2.
После смены номера AS все заработало как положено.
Извлеченный урок: убедитесь, что номера AS одинаковые, если вы хотите соседства EIGRP.
Case #4
И последнее, но не менее важное: если вы проверили номер AS, значения K, IP-адреса и у вас все еще нет работающего соседства EIGRP, вам следует подумать о безопасности. Возможно, access-list блокирует EIGRP и/или многоадресный трафик.
Следующая ситуация: опять два маршрутизатора EIGRP и отсутствие соседства. Что здесь происходит?
Мы видим, что нет соседей ...
Если вы посмотрите на вывод команды show ip protocols, то увидите, что сеть была объявлена правильно. Если вы посмотрите внимательно на OFF2, вы увидите, что у нас есть пассивный интерфейс.
Удалим настройки пассивного интерфейса!
OFF2(config)#router eigrp 12
OFF2(config-router)#no passive-interface fastEthernet 0/0
Еще одна неправильная настройка создала нам проблемы, но мы ее решили.
Задача решена!
Извлеченный урок: не включайте пассивный интерфейс, если вы хотите установить соседство EIGRP.
Case #5
В приведенном выше примере у нас есть те же 2 маршрутизатора, но на этот раз кто-то решил, что было бы неплохо настроить список доступа на OFF2, который блокирует весь входящий многоадресный трафик.
Здесь можно запутаться. На OFF1 мы видим, что он считает, что установил соседство EIGRP с OFF2. Это происходит потому, что мы все еще получаем пакеты EIGRP от OFF2.
Используем команду debug eigrp neighbors, чтобы посмотреть, что происходит. Очевидно, что OFF1 не получает ответ от своих hello messages, holdtime истекает, и это отбрасывает установление соседства EIGRP.
Быстрый способ проверить подключение - отправить эхо-запрос по адресу многоадресной рассылки 224.0.0.10, который использует EIGRP. МЫ видим, что мы ответа нет от этого запроса. Рекомендуется проверить, есть ли в сети списки доступа.
Так, так! Мы нашли что-то ...
Этот список доступа блокирует весь многоадресный трафик. Давайте сделаем настройку, которая разрешит EIGRP.
OFF2(config)#ip access-list extended BLOCKMULTICAST
OFF2(config-ext-nacl)#5 permit ip any host 224.0.0.10
Мы создаем специальное правило, которое будет разрешать трафик EIGRP.
Как мы видим, что трафик EIGRP разрешен - это соответствует правилу, которое мы выше создали.
Оба маршрутизатора теперь показывают рабочее соседство EIGRP.
Эхо-запрос, который мы только что отправили, теперь работает.
Извлеченный урок: не блокируйте пакеты EIGRP!
Case #6
Рассмотрим очередную ситуацию, в которой нет соседства EIGRP. На картинке выше мы имеем сеть Frame Relay и один канал PVC между OFF1 и OFF2. Вот соответствующая конфигурация:
Оба маршрутизатора настроены для Frame Relay, а EIGRP настроен.
Видно, что нет соседей ... это не хорошо! Можем ли мы пропинговать другую сторону?
Пинг проходит, поэтому мы можем предположить, что PVC Frame Relay работает. EIGRP, однако, использует многоадресную передачу, а Frame Relay по умолчанию - NBMA. Можем ли мы пропинговать адрес многоадресной рассылки EIGRP 224.0.0.10?
Здесь нет ответа на наш вопрос, по крайней мере, теперь мы знаем, что unicast трафик работает, а multicast не работает. Frame Relay может быть настроен для point-to-point или point-to-multipoint соединения. Физический интерфейс всегда является интерфейсом frame-relay point-tomultipoint, и для него требуются frame-relay maps, давайте проверим это:
Мы видим, что оба маршрутизатора имеют DLCI-to-IP карты, поэтому они знают, как связаться друг с другом. Видим, что они используют ключевое слово "статический", а это говорит о том, что это сопоставление было кем-то настроено и не изучено с помощью Inverse ARP (в противном случае вы увидите "динамический"). Мы не видим ключевое слово "broadcast", которое требуется для пересылки широковещательного или многоадресного трафика. На данный момент у нас есть 2 варианта решения этой проблемы:
Настроить EIGRP для использования одноадресного трафика вместо многоадресного.
Проверить конфигурацию Frame Relay и убедится, что многоадресный трафик не перенаправляется.
Давайте сначала сделаем unicast настройку EIGRP:
OFF1(config)#router eigrp 12
OFF1(config-router)#neighbor 192.168.12.2 serial 0/0
OFF2(config)#router eigrp 12
OFF2(config-router)#neighbor 192.168.12.1 serial 0/0
Нам нужна команда neighbor для конфигурации EIGRP. Как только вы введете эту команду и нажмете enter, вы увидите это:
Задача решена! Теперь давайте попробуем другое решение, где мы отправляем multicast трафик по PVC Frame Relay:
OFF1(config)#router eigrp 12
OFF1(config-router)#no neighbor 192.168.12.2 serial 0/0
OFF2(config)#router eigrp 12
OFF2(config-router)#no neighbor 192.168.12.1 serial 0/0
Если это не работает ... не исправляйте это... , но не в этот раз! Пришло время сбросить соседство EIGRP.
OFF1(config)#interface serial 0/0
OFF1(config-if)#frame-relay map ip 192.168.12.2 102 broadcast
OFF2(config)#interface serial 0/0
OFF2(config-if)#frame-relay map ip 192.168.12.1 201 broadcast
Broadcast - это ключевое волшебное слово здесь. Это разрешит широковещательный и многоадресный трафик.
После изменения конфигурации frame-relay map появляется соседство EIGRP! Это все, что нужно сделать.
Извлеченный урок: проверьте, поддерживает ли ваша сеть Frame Relay broadcast или нет. Настройте EIGRP для использования unicast передачи или измените конфигурацию Frame Relay для поддержки широковещательного трафика.
Продолжение цикла про поиск и устранение неисправностей протокола EIGRP можно почитать тут.