По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Конфигурация вашей сети Cisco хранится в двух основных местах: одно находится в ОЗУ, а другое - в текущей конфигурации (running configuration). Когда вы вводите команды, они активируются немедленно и сохраняются в текущей конфигурации, которая хранится в ОЗУ.
Поэтому при выключении питания конфигурация теряется. Чтобы сохранить эту конфигурацию, скопируйте ее в загрузочную конфигурацию (startup-configuration), что означает, что она хранится в энергонезависимой ОЗУ (NVRAM), чтобы конфигурация сохранялась при выключении питания.
Вы можете использовать две команды для сохранения вашей конфигурации: команду записи или команду копирования. Команда записи устарела, но будет выглядеть так:
Router#write memory
Building configuration...
[OK]
Более новая версия команды - это команда копирования, которая выглядит как:
Router#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Команда копирования предлагает больше гибкости и возможностей. Вы можете не только скопировать данные текущей конфигурации в файл начальной конфигурации, но и скопировать их в файл на флэш-памяти или на TFTP-сервер в вашей сети.
Для любой команды вам нужно набрать столько букв, сколько требуется IOS для однозначной идентификации команды. Например:
copy run sta
В больших корпоративных сетях могут использоваться несколько протоколов внутренней маршрутизации. Такая практика часто встречается при слиянии двух компаний. Чтобы компьютеры в одном домене маршрутизации (далее просто «домен») видели хосты в другом домене применятся так называемая редистрибуция. Эта функция позволяет маршрутизатору выбрать маршрут, выученный через один протокол маршрутизации, например, EIGRP и добавить в его в список анонсируемых сетей в другой, например, OSPF. Эта операция выполняется на маршрутизаторах, который смотрят в обе сети и называются точкой редистрибуции (Redistirbution Point). Маршрутизаторы, которые занимаются анонсированием сетей из одного домена в другой используют для этого таблицу маршрутизации. Другими словами, если маршрутизатор не найдет путь до какой-то сети в своей таблице, то он не будет анонсировать его в другой домен.
Схема сети
Для построения отказоустойчивой сети обычно применяются два или более маршрутизатора, которые занимаются перебросом маршрутной информации с одного домена в другой. В такой ситуации может образоваться так называемая петля маршрутизации. Поясним на рисунке:
В данном случае пакеты из маршрутизатор 2, чтобы добраться до сети Х, которая находится в том же домене делает круг через RD1 > R1 > RD2 > Subnet X. Это происходит потому, что маршрут, объявленный RD1 в Домен маршрутизации 2, имеет меньшее административное расстояние (Administrative Distance, AD), чем маршруты, объявленные роутерами из того же домена. Далее рассмотрим в каких случаях возможно такое.
Как избежать петель?
Один из самых лёгких методов для избегания петель маршрутизации это при добавлении маршрутов из одного домена в другой более высокой метрики.
В данном случае маршрутизаторы RD1 и RD2 при анонсировании маршрутов, выученных протоколом RIP в домен OSPF, назначают им метрику 500. И наоборот, из домена OSPF в домен RIP маршруты анонсируются с метрикой 5.
Второй способ – это административное расстояние. Любой маршрут, который добавляется в таблицу маршрутизации роутера, сопоставляется с административным расстоянием. Если роутер получил несколько маршрутов в одну и ту же сеть с одной и той же длиной префикса, то в таблицу попадают маршруты с меньшим AD. Маршрутизатор не учитывает метрику. Вместе с этим, AD – это локальное значение для каждого роутера и не объявляется соседним маршрутизаторам. В таблице ниже приведены административные расстояния для всех типов маршрутов на роутерах Cisco.
Тип маршрутаАдминистративное расстояниеConnected (подключённый)0Static (Статический)1EIGRP Summary route5eBGP (external BGP)20EIGRP (internal)90IGRP100OSPF110IS-IS115RIP120EIGRP (external)170iBGP (internal BGP)200
Настройки AD по умолчанию для протокола EIGRP при анонсировании маршрутов в OSPF и RIP предотвращают образование петель маршрутизации.
На рисунке выше подсеть 172.16.35.0/24 анонсируется через RD1 в домен OSPF. Маршрутизатор R2 в свою очередь анонсирует выученную через external OSPF сеть роутеру RD2. Но RD2 уже выучил маршрут до сети 35.0 через EIGRP, у которого административное расстояние равно 90, что меньше чем AD OSFP, которое равно 110. Таким образом RD2 не добавит маршрут, полученный у R2 с AD 110 в таблицу маршрутизации и соответственно не будет редистрибутировать обратно в EIGRP. Таким образом логику работы маршрутизатора RD2 можно сформулировать следующим образом:
RD2 считает маршрут, полученный по EIGRP лучшим, так как у него меньшее административное расстояние, и добавляет его в таблицу маршрутизации.
RD2 не будет анонсировать маршрут, полученный через OSPF, так как его нет в таблице маршрутизации.
В силу своей специфик, протокол EIGRP также предотвращает образование петель маршрутизации при редистрибуции из OSPF и RIP. Как было указано на таблице выше, внешние маршруты в EIGRP имеют административное расстояние равным 170.
В данном случае маршрутизатор RD2 выучил два маршрута в сеть 192.168.11.0/24. Один через R2 в домене OSPF с AD равным 110, второй через R1 в домене EIGRP с административным расстоянием равным 170-ти. Действуя по указанной выше логике, RD2 добавит в таблицу маршрутизации сеть 11.0 выученный у роутера R2 предотвращая таким образом образование петли.
Если в случае EIGRP-OSPF, EIGRP-RIP нам удалось без особых усилий предотвратить петлю маршрутизации, то в случае OSPF-RIP всё немного сложнее. Так как OSPF для всех типов маршрутов использует один показатель AD – 110, то при редистрибуции между RIP и OSPF избежать петель удается только изменение административного расстояния протоколов маршрутизации. Делается это командой distance. Для изменения показателя AD для внешних маршрутов, в интерфейсе настройки OSPF прописываем команду distance external ad-value. Значение, указанное параметром должно быть больше, чем у RIP (120).
Но не редки случаи, когда в сети работают более двух протоколов маршрутизации. В таких случаях значения AD по умолчанию не помогают. На рисунке ниже сеть 172.20.0.0/16 выучена протоколом EIGRP как внешний через RIP с АР (Административное Расстояние) равным 170. В свою очередь RD1 анонсирует данную сеть в домен OSPF с АР равным 110. RD2 же вместо маршрута с АР 170, полученного из домена EIGRP в таблицу добавляет маршрут с АР 110, полученный из домена OSPF. При таком раскладе маршрутизатор R4 получает два маршрута в одну и ту же сеть с одним и тем же АР. И в случае если метрика RD2 лучше, то R4 отправке пакетов в сеть 172.20 будет использовать более длинный путь. Нужно заметить, что это только в том случае, когда домены расположены именно в указанном порядке.
В таких случаях применяется настройка административного расстояния в зависимости от маршрута. Как было указано выше, для изменения АР используется команда distance. Эта команда принимает несколько параметров:
distance distance ip-adv-router wc-mask [ acl-number-or-name ]
В данной команде обязательным параметром является IP соседнего маршрутизатора. Если IP адрес анонсирующего маршрутизатора совпадёт с указанными в команде, то для маршрутов, полученных от этого соседа данный роутер назначит указанный в команде АР.
Рассмотрим указанный случай на практике. Детальная топология сети, показанная выше, указана на рисунке, а конфигурацию можете скачать по ссылке ниже:
Скачать файлы конфигрурации
Для начала просмотрим с каким АР RD1 выучил маршрут до сети 172.20:
Как видим, RD1 добавил в таблицу маршрутизации маршрут, выученный через OSPF, вместо EIGRP, так как АР у OSPF меньше. Теперь изменим поведение маршрутизатора и посмотрим, как это повлияет на таблицу маршрутизации.
ip access-list standard match-172-20
permit host 172.20.0.0
router ospf 2
distance 171 1.1.1.1 0.0.0.0 match-172-20
P.S. В GNS скорее всего придётся выключить, затем включить интерфейс, смотрящий в OSPF домен, чтобы изменения применились. В реальной сети всё работает правильно.
Поясним, что мы написали выше. Со стандартным списком доступа всё понятно. Команде distance параметром задали 171 – административное расстояние. Затем идет router id маршрутизатора, который анонсирует сеть 172.20. В нашем случае это маршрутизатор RD1. Таким образом, OSPF посмотрит полученный LSA и, если там увидит идентификатор маршрутизатора RD1, а также сеть, которая указана разрешённой в списке доступа, то применит этому маршруту расстояние 171.
Отметим, что указанную конфигурацию нужно сделать на всех роутерах, которые занимается распределением маршрутов и для всех сетей их третьего домена.
Привет, дорогой друг! На днях на AstriCon 2018 в Орландо, компания Sangoma (которая разрабатывает FreePBX) и компания Digium (которая разрабатывает Asterisk), которую, кстати, ранее приобрела компания Sangoma, сделали совместное заявление, в котором сообщили о выходе мажорных версий своих продуктов - Asterisk 16 и FreePBX 15.
Теперь они – Sang*ma
Asterisk 16 действительно доступен на сайте разработчика, а вот если Вы хотите попробовать FreePBX 15, то в привычном месте, где лежат актуальные версии Distro, Вы его не найдёте. Почему так получилось и как всё-таки попробовать 15 версию FreePBX – мы сейчас расскажем!
Дело в том, что FreePBX 15 c 29.08.18 находится в стадии альфа-тестирования. Это когда продукт отлаживают квалифицированные специалисты, которые обладают соответствующими навыками и знанием методик в области тестирования. После этапа альфа-тестирования, наступает этап бэта-тестирования, когда продукт почти готов для конечных пользователей. Обычно, такую версию делают доступной для всех желающих, чтобы простые пользователи могли дать фидбэк по доработкам. После этого идёт этап RC (Release Candidate), это такой период, когда продукт считается готовым к финальному релизу, только если за это время не будет найден какой-нибудь серьёзный баг. И, наконец – финальная версия, полностью отлаженная и готовая к массовому использованию.
Однако, это альфа-тестирование абсолютно открытое и каждый желающий может принять в нём участие. Важно понимать, что на данном этапе продукт ещё полон багов и недоработок, поэтому его ни в коем случае нельзя использовать для продакшен систем!.
Итак, чтобы «попробовать» FreePBX 15, нужно найти на форуме пост от разработчика FreePBX Andrew Nagy от 29.08.18 – вот он и следовать описанным в нём инструкциям.
Суть заключается в том, что необходимо вручную скачать модуль для FreePBX, который позволит нам обновиться до 15 версии. Перед началом данного процесса, у нас установлен FreePBX 14 из Distro SNG7-PBX-64bit-1805-1.
Внимание! Не повторяйте данный метод на инсталляциях, которые используются в продакшне! В настоящий момент FreePBX 15 ещё не готов для боевой эксплуатации! Создайте отдельный тестовый сервер, прежде чем продолжать.
Откройте вэб-интерфейс FreePBX Admin → Module Admin
Выберите в поле Type опцию Download (From Web) и вставьте следующую ссылку http://mirror1.freepbx.org/modules/packages/versionupgrade/versionupgrade-14.0.1.1.tgz в поле Download Remote Module
Нажмите Download (From Web)
Вернитесь к списку модулей, нажав Manage local modules
В пункте Admin найдите и настройте модуль PBX Upgrader. В поле Action выберите опцию Install, затем нажмите кнопку Process в самом низу
В открывшейся вкладке подтвердите установку кнопкой Confirm
По завершению установки во вкладке Admin появится новый модуль 14 to 15 Upgrade Tool, зайдите в него
В открывшемся окне нажмите Check the Requirements
Убедитесь, что система соответствует всем требованиям перед обновлением.
У нас не соответствует, нам необходимо:
Зарегистрировать и активировать систему
Обновить локальные модули
Обновить коммерческие модули
О том, как обновлять модули, читайте в нашей статье
Когда все требования выполнены, снова откройте 14 to 15 Upgrade Tool там должна появиться кнопка Proceed to upgrade process
В открывшемся окне выберите свой дистрибутив
На втором шаге у нас возникла ошибка, нам предложили ввести команду amportal && fwconsole ma upgradeall через CLI. Вводите именно команду fwconsole ma upgradeall, amportal он не поймёт.
После того, как мы ввели команду fwconsole ma upgradeall, мы ещё раз запустили Proceed to upgrade process и обновление продолжилось.
Дождитесь завершения установки и нажмите клавишу Refresh
Поздравляем, Вы успешно установили АЛЬФА версию FreePBX 15, Вы – удивительны!
Ещё раз напоминаем, что данную версию ни в коем случае нельзя использовать в качестве боевой АТС, а вот тестировать и делиться фидбэками – Welcome!