По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
У всех профессионалов есть набор инструментов, который ежедневно помогает ему в работе. Независимо от того, проектируете ли вы сеть, диагностируете и устраняете проблему или отслеживаете среду, ваш пакет сетевых инструментов должен быть полным, удобным и надежным. Вот почему мы собрали список некоторых из основных бесплатны инструментов для сетевых администраторов, и оставили ссылки на скачивание. Некоторые будут вам знакомы, некоторые будут новыми, но в любом случае эта информация не будет лишней. Давайте начнем!
Анализаторы
Wireshark / Tshark
Wireshark - это не имеющий аналогов анализатор сетевых протоколов, и, честно говоря, один из лучших бесплатных сетевых инструментов, когда-либо созданных. Когда вы решаете сетевую проблему и вам действительно нужно погрузиться глубже, внутрь пакетов – Wireshark будет вашим микроскопом.
Если вы ищете что-то для захвата командной стоки или, возможно, вы хотите программно инициировать захват пакетов, не забудьте проверить TShark. Он включен в Wireshark, работает аналогично Tcpdump и совершенно потрясающий.
iPerf / JPerf
Между любыми двумя узлами находится сеть - огромная или маленькая. Простой пинг между двумя узлами хорош только для проверки общей достижимости и понимания времени кругового обхода для небольших пакетов. Если вы хотите измерить реально достижимую пропускную способность, вам нужен другой инструмент, такой как iPerf.
iPerf3 - последняя версия этого инструмента. Вы запускаете клиент на двух концах сети, настраивая параметры, необходимые для измерения производительности. Он поддерживает настройку многих параметров, связанных с синхронизацией, буферами и протоколами (TCP, UDP, SCTP с IPv4 и IPv6). После выполнения он активно измеряет и сообщает о пропускной способности, потерях, задержке, джиттере и т. д. Вы можете инициировать несколько одновременных подключений, чтобы действительно имитировать нагрузку в сети. Очень удобный инструмент!
Если вы больше предпочитаете графический интерфейс, то посмотрите Jperf. Он возрасте, но все еще работает как часы.
Nmap / Zenmap
Nmap (Network Mapper) - это сканер безопасности, используемый для обнаружения хостов и сервисов в компьютерной сети, который создает таким образом «карту» сети. Для достижения своей цели Nmap отправляет специально созданные пакеты целевому хосту, а затем анализирует ответы.
Nmap предоставляет невероятное количество функций для исследования сетей, включая обнаружение узлов, обнаружение служб и детектирование операционной системы.
Эти функции расширяются с помощью сценариев, которые обеспечивают более расширенное обнаружение служб, обнаружение уязвимостей и другие функции. Фактически, Nmap используется в бэкэнде для различных инструментов оценки безопасности, таких как Nexpose.
Опять же, если вы являетесь большим поклонником графического интерфейса, обязательно загрузите пакет с Zenmap.
Paessler SNMP Tester
SNMP может быть сложным. Вот почему вам нужен хороший тестер, например Paessler SNMP Tester.
Идея этой программы состоит в том, чтобы иметь инструмент, который позволяет пользователю отлаживать действия SNMP, чтобы находить проблемы со связью или с данными в конфигурациях мониторинга SNMP. Ваши устройства настроены правильно? Вы используете правильные ключи? Используйте этот инструмент, чтобы проверить, будет ли ваша конфигурация SNMP работать с такими программами, как PRTG Network Monitor.
Angry IP Scanner
Angry IP Scanner - это многопоточный сканер IP-адресов и портов с открытым исходным кодом. Подобный Nmap, используемый миллионами, он стал стандартным инструментом для сетевых администраторов. Angry IP Scanner сначала быстро пингует, затем проверяет состояние порта, затем начинает резолвить имена хостов, собирать MAC-адреса, операционные системы и все, что он может различить на основе собранных данных. Он может собирать информацию NetBIOS, такую как имена рабочих групп и доменов, а также зарегистрированных пользователей, если у вас есть привилегированные права для получения этой информации. Как и Nmap, он расширяется с помощью плагинов. Результаты сканирования могут быть сохранены в CSV, TXT, XML или файлы списка IP-портов. Работает на Windows, Mac и Linux.
Netcat
Netcat, часто описываемый как «швейцарский нож», чрезвычайно полезен для всего, что касается отправки или получения информации о сетевых портах. Это многофункциональный инструмент для отладки и исследования сети, поскольку он может создавать практически любые виды соединений, которые вам понадобятся.
Мониторинг и логирование
Nagios
Nagios - это программное решение для сетевого мониторинга. Фактически это набор решений для мониторинга доступности сети, анализа потоков данных и безопасности, а также сбора журналов для аудита. Это полностью открытый исходный код и имеет энергичное сообщество единомышленников разработчиков и администраторов.
С
В этой статье мы расскажем как решить проблему с блокировкой файлов в ESXi.
Проблема
Появляется ошибка при добавлении диска имеющейся виртуальной машины (VMDK) к виртуальной машине, которая не включается:
Failed to add disk scsi0:1. Failed to power on scsi0:1
Включение виртуальной машины зависает на 95%.
Не удается включить виртуальную машину после развертывания ее из шаблона.
Включение виртуальной машины выдает ошибки доступа к файлам, конфигурации виртуальной машины, или файла подкачки:
Unable to open Swap File
Unable to access a file since it is locked
Unable to access a file [filename] since it is locked
Unable to access Virtual machine configuration
В записях журнала появляются похожие записи:
WARNING: World: VM xxxx: xxx: Failed to open swap file [path]: Lock was not free
WARNING: World: VM xxxx: xxx: Failed to initialize swap file [path]
При открытии консоли для виртуальной машины может возникнуть ошибка:
Error connecting to [path][virtual machine].vmx because the VMX is not started
Виртуальная машина сообщает о конфликтных состояниях питания между центральным сервером управления vCenter Server и пользовательским интерфейсом ESXi хост.
При открытии файла .vmx с помощью текстового редактора (например, cat или vi) появляются похожие записи:
cat: can't open '[name of vm].vmx': Invalid argument
Решение
Цель блокировки файлов
Для предотвращения непредвиденных изменений в ценные системные файлы и файлы виртуальной машины, их необходимо заблокировать. В определенных обстоятельствах блокировка сохраняется, даже с выключенной виртуальной машиной. Таким образом, другие ESXi хосты не смогут получить доступ к заблокированным файлам, даже если виртуальная машина не запускается.
Файлы виртуальной машины, заблокированные во время выполнения, включают в себя:
VMNAME.vswp
DISKNAME-flat.vmdk
DISKNAME-ITERATION-delta.vmdk
VMNAME.vmx
VMNAME.vmxf
vmware.log
Быстрый первичный тест
Поставьте DRS (Планировщик Распределения Ресурсов) в режим обслуживания. С его помощью вы сможете выбрать хост, пока вы включаете виртуальную машину. Если DRS не используется, передайте ВМ другому хосту.
Если это не удается, попробуйте включить питание виртуальной машины на других узлах кластера.
Машина должна включиться, когда она окажется на узле, который заблокировал файлы.
Если ВМ по-прежнему не включается, рассмотрите действия, предложенные ниже.
Действия по устранению неполадок: поиск хоста заблокированного файла
Чтобы определить заблокированный файл, попробуйте включить виртуальную машину. Во время включения питания ошибка может отображаться или записываться в журналы виртуальной машины. Ошибка и запись в журнале идентифицируют виртуальную машину и файлы:
Чтобы найти блокирующий узел, запустите утилиту vmfsfilelockinfo с узла, который не может открыть заблокированный файл.
Чтобы узнать IP-адрес хоста, который заблокировал файлы, необходимо запустить утилиту vmfsfilelockinfo для файла VMDK flat, delta или sesparse для VMFS или для файла .UUID. lck для vSAN. Утилита vmfsfilelockinfo потребует следующий материал:
Заблокированный файл
Имя пользователя и пароль для доступа к VMware vCenter Server (при отслеживании MAC-адреса хостом ESX.)
Например:
Запустите команду:
~ # vmfsfilelockinfo -p /vmfs/volumes/iscsi-lefthand-2/VM1/VM1_1-000001-delta.vmdk -v 192.168.1.10 -u administrator@vsphere.local
Результат будет приблизительно такой:
vmfsflelockinfo Version 1.0
Looking for lock owners on "VM1_1-000001-delta.vmdk"
"VM1_1-000001-delta.vmdk" is locked in Exclusive mode by host having mac address ['xx:xx:xx:xx:xx:xx']
Trying to make use of Fault Domain Manager
----------------------------------------------------------------------
Found 0 ESX hosts using Fault Domain Manager.
----------------------------------------------------------------------
Could not get information from Fault domain manager
Connecting to 192.168.1.10 with user administrator@vsphere.local
Password: xXxXxXxXxXx
----------------------------------------------------------------------
Found 3 ESX hosts from Virtual Center Server.
----------------------------------------------------------------------
Searching on Host 192.168.1.178
Searching on Host 192.168.1.179
Searching on Host 192.168.1.180
MAC Address : xx:xx:xx:xx:xx:xx
Host owning the lock on the vmdk is 192.168.1.180, lockMode : Exclusive
Total time taken : 0.27 seconds.
Примечание: в течение жизненного цикла работающей виртуальной машины ее файлы могут менять тип блокировки. Вид блокировки (mode) обозначает тип блокировки на файле. Список видов блокировки:
mode 0 = отсутствие блокировки
mode 1 = эксклюзивная блокировка (файл vmx работающей виртуальной машины, использует VMDK-диск (flat or delta), *vswp и т.д.)
mode 2 = блокировка «только для чтения» (read-only). (Например, для файла данных flat.vmdk работающей машины со снапшотами)
mode 3 = блокировка для одновременной записи с нескольких хостов (например, используется для кластеров MSCS или FTVMs)
Чтобы узнать название процесса, который заблокировал файл, запустите команду lsof на хосте, заблокировавшем файл, и укажите название нужного файла:
~ # lsof | egrep 'Cartel|VM1_1-000001-delta.vmdk'
Результат будет приблизительно такой:
Cartel | World name | Type | fd | Description
36202 vmx FILE 80 /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/VM1/VM1_1-000001-delta.vmdk
Из результата вы узнаете Cartel ID заблокировавшей машины – например, 36202. Теперь, с помощью следующей команды, выведете на экран список активных Cartel ID:
~ # esxcli vm process list
Информация активных виртуальных машин сгруппирована по названиям машин. Формат приблизительно такой:
Alternate_VM27
World ID: 36205
Process ID: 0
VMX Cartel ID: 36202
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a9 dc 9f bf
Display Name: Alternate_VM27
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM27/Alternate_VM27.vmx
………
Найдя нужный вам VMX Cartel ID, вы узнаете название машины, заблокировавшей ваш файл. Если никакие процессы не отображаются, можете найти виртуальные машины с подключенным vmdk. Замените VMDKS_TO_LOOK_FOR на необходимый vmdk. В результате будет список всех зарегистрированных виртуальных машин, и VMDK отобразится под виртуальной машиной, которая заблокировала файл:
for i in $(vim-cmd vmsvc/getallvms | grep -v Vmid | awk -F "/" '{print $2}' | awk '{print $1}'); do echo $i && find ./ -iname $i | xargs grep vmdk | grep -Ei VMDKS_TO_LOOK_FOR ; done
Снятие блокировки
Машину, которая не включается, переместите на заблокировавший хост и снова попробуйте включить ее.
Чтобы снять блокировку, извлеките VMDK-диск или выключите машину, которая удерживает блокировку.
Перезагрузите хост, который заблокировал файл.
Обратитесь к VMware storage team, vSAN team или разработчику NFS за дальнейшей помощью, так как проблемы с метаданными могут мешать управлению блокировками.
Снятие блокировки .lck file (только для NFS)
Файлы на виртуальной машине могут быть заблокированы через NFS storage. Такие файлы заканчиваются на .lck-#### (где #### - значение поля fileid, которое можно получить из запроса GETATTR для заблокированного файла).
Внимание: для безопасного извлечения файлов машина должна быть выключена.
Примечание: Тома VMFS не имеют .lck файлов. Механизм блокировки для томов VMFS расположен в метаданных тома VMFS.
Проверка целостности файла конфигурации виртуальной машины (.vmx)
Если виртуальная машина не включается, причина может быть в наличие двух дисков в файле .vmx. Извлеките один из дисков и попробуйте включить машину снова.
Команда touch *, которая раньше использовалась для устранения неполадок с заблокированными снапшотами vmdk, теперь записывает время последнего изменения файла, который должен быть остановлен и запущен с помощью vmkfstools-D или chmod-s * или vmfsfilelockinfo * для идентификации блокировки.
Пока не создан единый протокол маршрутизации, управляющий остальными, существует необходимость в том, чтобы несколько протоколов маршрутизации мирно сосуществовали в одной сети. К примеру, одна компания работает с OSPF, а другая компания работает с EIGRP, и эти две компании слились в одно целое предприятие. Пока вновь образованный ИТ-персонал не перейдет для использования на единый протокол маршрутизации (возможно они когда-нибудь это сделают), маршруты, известные протоколу OSPF, необходимо объявить в часть сети, работающей под управлением EIGRP, и наоборот.
Упомянутый выше сценарий возможен благодаря Route redistribution, и именно этому посвящена данная статья. Другие причины, по которым вам потребуется выполнить Route redistribution, это: различные части сети конкретной компании находятся под различным административным контролем; если необходимо объявить маршруты своему поставщику услуг через BGP, или, возможно, необходимо подключиться к сети делового партнера.
Рассмотрим следующую базовую топологию.
В простой топологии, показанной выше, мы хотим, чтобы OSPF и EIGRP объявляли друг другу маршруты, о которых они знают. Эта концепция называется взаимным перераспределением маршрутов. Поскольку роутер CENTR имеет один интерфейс в автономной системе OSPF (AS) и один интерфейс в EIGRP AS, он несет ответственность за выполнение Route redistribution.
Seed Metrics
Основная проблема, с которой мы сталкиваемся при Route redistribution между различными протоколами маршрутизации, заключается в разнообразных подходах, применяемых протоколами маршрутизации для измерения своих метрик. Например, OSPF использует cost-метрику, которая основана на bandwidth, в то время как EIGRP использует метрику, основанную на bandwidth и delay, но также может учитывать надежность или (и) нагрузку (и даже использовать Maximum Transmission Unit (MTU) в качестве прерывания связи). Итак, что же нам делать?
Мы, как администраторы, можем настроить метрику, назначенную маршрутам, поступающим из одной AS, которые перераспределяются в другую AS. Если нам лень вручную настраивать метрику, которая будет использоваться для Route redistribution, то используется seed metric. В следующей таблице показаны seed metrics, используемые различными протоколами маршрутизации.
Основываясь на приведенной выше таблице, мы видим, что, маршрутам, которые перераспределяются в OSPF по дефолту будет назначена метрика 20, если же маршруты, перераспределяются в протокол OSPF от протокола BGP, то им будет присвоено значение метрики 1. Интересно, что и RIP, и EIGRP по умолчанию имеют seed metrics бесконечности. Это означает, что любой маршрут, перераспределенный в эти протоколы маршрутизации, будет считаться недостижимым по умолчанию и поэтому не объявляются никаким другим роутерам. BGP, однако, перераспределяет маршрут, полученный из протокола внутреннего шлюза (IGP), используя исходную метрику этого маршрута.
Пример базовой настройки
Конечно, есть еще много вопросов, связанных с перераспределением маршрутов, таких как циклы маршрутизации, которые могут возникнуть, когда у нас есть несколько роутеров, соединяющих наши автономные системы, или выборочная фильтрация определенных маршрутов от перераспределения. Но мы вернемся ко всему этому в следующих статьях. А пока давайте разберемся, как выполнить базовую настройку Route redistribution (перераспределения маршрутов). Рассмотрим предыдущую топологию, на этот раз с добавлением информации о сети и интерфейсе:
В этой топологии роутер CENTR изучает маршруты от OFF1 через OSPF и от OFF2 через EIGRP. Это видно в выходных данных команды show ip route, отображенной на CENTR:
Однако ни роутер OFF1, ни роутер OFF2 не изучили никаких маршрутов, потому что роутер CENTR еще не выполняет Route redistribution. Об этом свидетельствует вывод команды show ip route, отображенной на OFF1 и OFF2:
Теперь давайте добавим конфигурацию Route redistribution к роутеру CENTR. Чтобы подтвердить предыдущее утверждение о том, что seed metric для маршрутов, перераспределяемых в EIGRP, является бесконечностью, мы изначально не будем настраивать какие-либо метрики и позволим seed metric вступить в силу.
CENTR# conf term
Enter configuration commands, one per line. End with CNTL/ Z
CENTR(config)#router ospf 1
CENTR(config-router)#redistribute eigrp 1
CENTR(config-router)#exit
CENTR(config)#router eigrp 1
CENTR(config-router)# redistribute ospf 1
CENTR(config-router)#end
CENTR#
Команда redistribute применена в режиме конфигурации роутера для каждого протокола маршрутизации, и метрика не была указана. Важно, что, когда мы ввели команду redistribute eigrp 1 выше, мы не включили ключевое слово subnets в команду, которая заставляет как классовые, так и бесклассовые сети перераспределяться в OSPF. Однако, как видно из приведенных ниже выходных данных, ключевое слово subnets было автоматически добавлено для нас:
Данное поведение автоматического добавления ключевого слова subnets наблюдается в последних версиях Cisco IOS. Некоторые, более старые версии Cisco IOS, не включают автоматически ключевое слово subnets, и вам может потребоваться вручную добавить его в команду redistribute. Давайте теперь взглянем на таблицы IP-маршрутизации на роутерах OFF1 и OFF2, чтобы увидеть, какие маршруты они изучили (и не изучили).
Приведенные выше выходные данные показывают нам, что роутер CENTR успешно перераспределил маршруты, известные EIGRP в OSPF, которые затем были изучены роутером OFF1. Обратите внимание, что перераспределенные маршруты, известные роутеру OFF1, имеют метрику 20, которая является seed metrics OSPF. Однако роутер OFF2 не изучал никаких новых маршрутов, потому что, когда роутер CENTR перераспределял маршруты в EIGRP, он использовал seed metrics EIGRP бесконечность (что означает недостижимость). В результате эти маршруты не были объявлены роутеру OFF2.
Чтобы решить эту проблему, нам нужно назначить метрику маршрутам, перераспределяемым в EIGRP. Существует три основных способа присвоения не дефолтных метрик маршрутам, перераспределяемым в протокол маршрутизации..
Установите метрику по умолчанию для всех протоколов маршрутизации, перераспределяемых в определенный протокол маршрутизации.
Установите метрику как часть команды redistribute.
Установите метрику используя route-map
Чтобы проиллюстрировать первый вариант, давайте настроим метрику для назначения всем маршрутам, перераспределяемым в EIGRP.
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR (config)#router eigrp 1
CENTR (config-router)#default-metric ?
1-4294967295 Bandwidth in Kbits per second
CENTR (config-router)#default-metric 1000000 ?
0-4294967295 delay metric in 10 microsecond units
CENTR(config-router)#default-metric 1000000 1 ?
0-255 Reliability metric where 255 is 100% reliable
CENTR (config-router)#default-metric 1000000 1 255 ?
1-255 Effective bandwidth metric (Loading) where 255 is 100% loaded
CENTR (config-router)#default-metric 1000000 1 255 1 ?
1-65535 Maximum Transmission Unit metric of thenpath
CENTR (config-router)#default-metric 1000000 1 255 1 1500
CENTR (config-router)#end
CENTR#
Контекстно-зависимая справка была использована в приведенном выше примере для отображения каждого компонента метрики, назначаемого маршрутам, перераспределяемым в EIGRP. Однако последняя команда была default-metric 1000000 1 255 1 1500. Если бы мы устанавливали default-metric для OSPF, мы могли бы использовать такую команду, как default-metric 30, чтобы назначить стоимость 30 OSPF маршрутам, перераспределяемым в OSPF. Однако в этом примере мы указали только default-metric для EIGRP. Давайте теперь проверим таблицу IP-маршрутизации на роутере OFF2, чтобы увидеть, были ли маршруты OSPF успешно объявлены в EIGRP.
Прекрасно! Роутер OFF2 изучил маршруты, происходящие из OSPF AS. Мы знаем, что маршруты первоначально пришли из-за пределов EIGRP, из-за кода EX, появляющегося в каждом из этих маршрутов.
Второй вариант установки метрики на Route Redistribution состоял в том, чтобы назначить метрику как часть команды redistribute, которая позволяет нам указать различные метрики для различных протоколов маршрутизации, перераспределяемых в процесс маршрутизации. Чтобы проиллюстрировать этот подход, давайте удалим предыдущие команды default-metric и redistribute из роутера CENTR и введем команду redistribute, которая определяет метрику, которая будет назначена.
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR(config)#router eigrp 1
CENTR(config-router)#no default-metric 1000000 1 255 1 1500
CENTR(config-router)#no redistribute ospf 1
CENTR(config-router)#redistribute ospf 1 ?
Match Redistribution of OSPF routes
metric Metric for redistributed routes
route-map Route map reference
cr
CENTR(config-router)#redistribute ospf 1 metric 1000000 1 255 1 1500
CENTR(config-router)#end
CENTR#
Если мы сейчас вернемся к роутеру OFF2, то получим тот же результат, что и раньше:
Третьим вариантом установки метрики для Route Redistribution использовании маршрутной карты (route-map). Маршрутные карты являются супермощными и могут быть использованы для различных конфигураций. По сути, они могут соответствовать определенному трафику и устанавливать один или несколько параметров (например, IP-адрес следующего прыжка) для этого трафика. Однако в нашем контексте мы просто будем использовать route-map для указания значения метрики, а затем применим ее к команде redistribute. В следующем примере показано, как мы можем удалить нашу предыдущую команду redistribute из роутера CENTR, создать route-map, а затем ввести новую команду redistribute, которая ссылается на нашу карту маршрута (route-map):
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR(config)#router eigrp 1
CENTR(config-router)#no redistribute ospf 1 metric 1000000 1 255 1 1500
CENTR(config-router)#exit
CENTR(config)#route-map SET-МETRIC-DEMO
CENTR(config-route-map)#set metric 1000000 1 255 1 1500
CENTR(config-route-map)#exit
CENTR(config)#router eigrp 1
CENTR(config-router)#redistribute ospf 1 route-map SET-МETRIC-DEMO
CENTR(config-router)#end
CENTR#
В приведенном выше примере, после удаления нашей команды redistribute, мы создали карту маршрута с именем SET-METRIC-DEMO. Это был очень простой route-map, которая не должна была соответствовать никакому траффику. Он был просто использован для установки метрики. Однако в следующей статье мы увидим, что route-map может быть использована, чтобы дать нам больше контроля над нашим перераспределением маршрутов. В нашем текущем примере карта маршрута была затем применена к нашей новой команде redistribute. Опять же, это дает нам тот же результат с точки зрения таблицы IP-маршрутизации роутера OFF2:
OSPF E1 или E2 Routes
Прежде чем мы закончим эту статью в нашей серии Route redistribution, давайте еще раз рассмотрим таблицу IP-маршрутизации на роутере OFF1:
Обратите внимание, что каждый из маршрутов, перераспределенных в OSPF, отображается в таблице IP-маршрутизации роутера OFF1 с кодом E2. Однако наблюдаются также код E1, оба указывающих, что маршрут возник из-за пределов OSPF AS роутера. Итак, в чем же разница между этими двумя кодами?
Код E2 указывает, что маршрут несет метрику, назначенную роутером, выполняющим перераспределение, который известен как автономный системный пограничный роутер (ASBR). Это означает, что независимо от того, сколько дополнительных роутеров в OSPF мы должны пересечь, чтобы вернуться к ASBR, метрика остается такой же, какой она была, когда ASBR перераспределил ее. Когда мы перераспределяем маршруты в OSPF, эти маршруты, по дефолту, являются этими External Type 2 (E2).
Код E1 указывает, что метрика маршрута состоит из первоначальной стоимости, назначенной ASBR, плюс стоимость, необходимая для достижения ASBR. Это говорит о том, что маршрут Е1, как правило, более точен, и на самом деле это так. Хотя наличие кода E1 не дает нам никакого преимущества в простой топологии, как у нас, где роутер OFF1 имеет только один путь для достижения ASBR (т. е. CENTR), и где есть только один способ для маршрутов EIGRP быть введенными в наш OSPF AS (т. е. через роутер CENTR).
Если мы хотим перераспределить маршруты E1 в OSPF вместо маршрутов E2, то это можно сделать с помощью команды redistribute. В следующем примере мы удаляем нашу команду redistribute для процесса маршрутизации OSPF на роутере CENTR, а затем повторно применяем команду redistribute, указывающую, что мы хотим, чтобы External Type 1 (E1) применялись к перераспределенным маршрутам.
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR(config)#router ospf 1
CENTR(config-router)#no redistribute eigrp 1 subnets
CENTR(config-router)#redistribute eigrp 1 metric-type ?
1 Set OSPF External Туре 1 metrics
2 Set OSPF External Туре 2 metrics
CENTR(config-router)#redistribute eigrp 1 metric-type 1
CENTR(config-router)#end
CENTR#show
Давайте проверим таблицу IP-маршрутизации на роутере OFF1, чтобы увидеть, изменились ли параметры на основе этой новой команды redistribute, введенной на роутере CENTR.
В приведенных выше выходных данных обратите внимание, что маршруты, перераспределенные в OSPF, имеют код E1, а не дефолтный код E2. Кроме того, обратите внимание, что это приводит к тому, что метрика этих маршрутов будет немного выше. В частности, роутер CENTR перераспределил EIGRP-изученные маршруты в OSPF, используя начальную метрику OSPF 20.
Однако существует стоимость OSPF 1, чтобы добраться от роутера OFF1 до роутера CENTR. Таким образом, поскольку перераспределенные маршруты были сконфигурированы как маршруты E1, стоимость этих маршрутов с точки зрения роутера OFF1 является стоимостью, первоначально назначенной роутером OFF1, которая составляла 20, плюс стоимость для OFF1, чтобы добраться до CENTR, который равен 1, итого общей стоимости 21.
Отлично, теперь вы знаете, как делать перераспределение маршрутов. Теперь почитайте, как сделать Фильтрацию маршрутов с помощью карт маршрутов.