По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Как правило, EIGRP-спикер роутер динамически обнаруживает своих соседей, отправляя multicast Hello сообщения. Однако есть возможность статически настроить этих соседей и общаться с ними с помощью unicast сообщений. Это делается крайне редко, но в таких случаях может оказаться полезным. Предыдущие статьи из цикла про EIGRP: Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка Часть 2. Про соседство и метрики EIGRP Часть 2.2. Установка K-значений в EIGRP Часть 3. Конвергенция EIGRP – настройка таймеров Часть 4. Пассивные интерфейсы в EIGRP Следующие статьи из цикла: Часть 6. EIGRP: идентификатор роутера и требования к соседству Рассмотрим для примера Frame Relay WAN. Представьте себе, что роутер А имеет интерфейс, настроенный на десять постоянных виртуальных каналов Frame Relay (PVC). На другом конце двух этих PVC каналов находятся EIGRP-спикер роутеры. Однако другие восемь PVC каналов не подключены к EIGRP-спикер роутерам. В данной топологии, если бы WAN-интерфейс роутера A участвовал в EIGRP, то роутер A должен был бы реплицировать свое приветственное сообщение EIGRP и отправить копию всем десяти PVC, что привело бы к увеличению нагрузки на роутер A и увеличило использование полосы пропускания на других восьми PVC, не подключающихся к EIGRP роутеру. Это ситуация, при которой выигрыш состоит в статической настройке соседей EIGRP, а не от использования процесса обнаружения на основе многоадресной рассылки. Давайте рассмотрим вариант конфигурации статического соседства EIGRP в этой статье. Статическая конфигурация соседства Команда neighbor ip_address outgoing_interface вводится в режиме конфигурации роутера EIGRP для статического указания соседства EIGRP. Обратите внимание, что эта настройка должна быть выполнена на обоих соседях. Кроме того, имейте в виду, что IP-адрес, указанный в команде neighbor, принадлежит той же подсети, что и указанный исходящий интерфейс. На основе топологии, показанной ниже, следующие примеры настроек показывают, как роутеры OFF1 и OFF2 статически указывают друг на друга, в отличие от использования динамического обнаружения. OFF1#conf term Enter configuration commands, one per line. End with CNTL/Z. OFF1(config)#router eigrp 1 OFF1(config-router)#neighbor 10.1.1.2 gig 0/1 OFF1(config-router)#end OFF1# OFF2#conf term Enter configuration commands, one per line. End with CNTL/Z. OFF2(config)#router eigrp 1 OFF2(config-router)#neighbor 10.1.1.1 gig 0/1 OFF2(config-router)#end OFF2# На роутере OFF1 команда neighbor 10.1.1.2 gig 0/1 введенная в режиме конфигурации роутера EIGRP, дает команду процессу EIGRP прекратить отправку многоадресных сообщений из интерфейса Gig 0/1 и вместо этого начать использовать одноадресные сообщения. Он также инструктирует процесс маршрутизации EIGRP попытаться установить соседство с EIGRP-спикер роутером, по IP-адресу 10.1.1.2 (то есть IP-адрес интерфейса Gig 0/1 роутера OFF2). Поскольку статическая конфигурация соседа должна выполняться на обоих концах канала, роутер OFF2 аналогично настроен для отправки одноадресных сообщений EIGRP со своего интерфейса Gig 0/1 и для установления соседства с EIGRP-спикер роутером с IP-адресом 10.1.1.1 (то есть IP-адресом интерфейса gig 0/1 роутера OFF1). Проверка статического соседства Чтобы определить, какие интерфейсы на роутере статически настроены с соседом EIGRP, можно использовать команду show ip eigrp neighbors detail. В приведенном ниже примере показано, что эта команда выполняется на роутере OFF1. Обратите внимание, что выходные данные идентифицируют 10.1.1.2 как статически настроенного соседа. Предостережение по применению статического соседства Рассмотрим роутер, который должен установить более чем одно соседство EIGRP с одного интерфейса, например роутер OFF2 на рисунке ниже. В этой топологии роутеры OFF1 и OFF2 динамически cформировали соседство EIGRP. Позже был добавлен роутер OFF4, и роутеры OFF2 и OFF4 были настроены как соседи EIGRP статически. Однако после того, как была сделана статическая настройка, роутер OFF2 потерял свое соседство с роутером OFF1. Причина заключается в том, что роутер OFF2 отправляет только одноадресные сообщения EIGRP со своего интерфейса Gig0/1 и хочет получать только одноадресные сообщения EIGRP, поступающие на этот интерфейс. Однако роутер OFF1 все еще настроен (с настройками по умолчанию) для отправки и ожидания многоадресных сообщений EIGRP на своем интерфейсе Gig0/1. Итак, мораль этой истории заключается в том, что если вы настраиваете интерфейс роутера для установления соседства EIGRP статически, убедитесь, что все соседи EIGRP вне этого интерфейса также настроены для соседства статически. Дело за малым - осталось последняя статья из цикла - EIGRP: идентификатор роутера и требования к соседству.
img
Сейчас вы точно прочувствуете важное команды screen. Бывало ли у вас такое, что вы выполняете (очень долго) команду в консоли - CLI на удаленной машине, будучи подключенным через SSH? Команда долго выполняется и близится к завершению как вдруг пропадает подключение, рвется SSH подключение и все, что вы делали - пропало? Прости, что напомнили. Знаем, это болезненно. Что же, вытрем слезы. Для этих ситуаций есть команда screen о которой мы и поговорим. Немножко теории Так называемый screen это терминальный мультиплексор (нас тоже пугает это слово). Другими словами, оно дает нам возможность внутри действующей сессии открыть сколько угодно много виртуальных окон/терминалов. Что важно - процесс, запущенный внутри сессии через screen, будет продолжаться даже тогда, когда вы отключитесь от самой первой сессии. Установка screen в Linux Вообще, пакет screen предустановлен на большинстве современных Linux - дистров. Проверить можно командой: screen --version Screen version 4.00.03 (FAU) 23-Oct-06 Если случилось так, что у вас его нет - это можно быстро исправить простой установкой. Установка screen в Ubuntu и Debian apt install screen Установка screen в CentOS и Fedora yum install screen Запуск screen в Linux Чтобы запустить screen в консоли, просто наберите screen. Что может быть проще, не правда ли? screen У вас откроется новая сессия в новом окне. Уже здесь вы можете вводить все нужные shell команды. Находясь в режиме скрина (screen) вы можете посмотреть список доступных вам команд управления этим режимом. Вот так: Ctrl+a и ? Если не получается нажать указанную выше комбинацию, можно поступить проще: нажмите отдельно Ctrl+a, отпустите, а затем в консоль наберите ? и нажмите Enter Сессия screen с именем Ну очень удобная фича. Если вы делаете несколько процессов параллельно, просто обзовите их так, чтобы потом понять, что и где выполняется. Синтаксис такой: screen -S имя_сессия_скрин Например, вы можете запустить ping - замер хоста с 1С и назвать сессию так: screen -S pings_towards_1C Всегда используйте скрин именно так. Будет значительно удобнее. Как правильно работать с окнами в Windows Как мы уже сказали, когда вы создаете новую screen - сессию, вы создадите новое окно с shell оболочкой внутри. И что интересно - внутри скрин сессии вы можете создать множество дополнительных окон. Чтобы это сделать, воспользуйтесь командой (внутри скрина) Ctrl+a и c. Новому окну будет назначен номер от 0 до 9 (первый свободный). Ниже мы собрали все команды, которые понадобятся вам для управления скринами: Ctrl+a и c - создать дополнительное окно ; Ctrl+a и " - показать список всех имеющихся окон; Ctrl+a и 0 - переключиться на окно с номером 0 (номер может быть иной); Ctrl+a и A - переименовать текущее окно; Ctrl+a и S - разделить окно по горизонтали на две области; Ctrl+a и | - разделить окно по вертикали на две области; Ctrl+a и tab - переключить рабочий фокус на следующую область разделенного окна; Ctrl+a и Ctrl+a - переключить рабочий фокус на предыдущую область разделенного окна; Ctrl+a и Q - закрыть все разделенные области кроме; Ctrl+a и X - закрыть текущую область; Выход из screen сессии Вы можете легко выйти из screen - сессии набрав: Ctrl+a и d Самое важное: запущенная вами в этот момент команда не остановится и будет продолжать свое выполнение. Возврат к screen сессии Чтобы вернуть к screen - сессии используйте команду: screen -r Если у вас запущено больше чем одна screen - сессия, то после ключа r нужно указать ее ID. Узнать его просто с помощью команды: screen -ls Вывод этой команды будет выглядеть вот так: screen -ls There are screens on: 32328.pings_towards_1C (Detached) 32482.wiki.merionet.ru_is_one_love (Detached) 2 Sockets in /var/run/screen/S-root. В выводе выше мы выделили ID - сессий. Например, чтобы вернуться к сессии 32328 (pings_towards_1C), дайте команду: screen -r 32328 Немножко кастомизации screen под вас Когда screen запускается, он считывает свои конфигурационные параметры из /etc/screenrc и ~/.screenrc, если файл присутствует. Так вот - мы можем легко перенастроить предпочтения использования screen и сделать это в файле .screenrc. Посмотрите пример с комментариями, как мы закастомили screen для себя: # Выключаем приветствие startup_message off # включаем визуальный звонок vbell off # буфер для сохраненных строк делаем 10000 defscrollback 10000 # кастомим строку состояния hardstatus alwayslastline hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %m-%d %{W}%c %{g}]' Типовой сценарий использования screen Общий случай, так сказать. Обычно он состоит из следующих шагов: После SSH подключения к серверу, набираем screen; Запускаем интересующую нас команду в режиме screen - сессии; Выполняем команду Ctrl + a и d, чтобы выйти из режима работы с экран-сессией Через какое-то время возвращаемся к запущенному ранее экрану командой screen -r Выводы Мы разобрались, как создавать screen сессии, управлять ими внутри, открывая новые окна, выходить из их режима управления (без прекращения выполнения команды), делить горизонтально и вертикально экраны. Ах да, ещё мы научились кастомизировать screen под себя. Профит!
img
Мы продолжим рассмотрение вопроса об устранении неполадок в объявлениях о маршрутах BGP. Все маршрутизаторы будут иметь рабочие соседние узлы BGP. Рекомендуем также почитать первую часть статьи по траблшутингу протокола BGP. Видео: Основы BGP за 7 минут Урок 1 Новый сценарий. R1 и R2 находятся в разных автономных системах. Мы пытаемся объявить сеть 1.1.1.0 / 24 от R1 до R2, но она не отображается на R2. Вот конфигурации: На первый взгляд, здесь все в порядке. Однако R2 не узнал никаких префиксов от R1 Может быть, используется distribute-list. Но нет, это не тот случай. Это означает, что нам придется проверять наши все команды network. Проблема заключается в команде network. Она настраивается по-разному для BGP и нашего IGP. Если мы применяем команду network для BGP, она должна быть полной. В этом случае забыли добавить маску подсети R1(config)#router bgp 1 R1(config-router)#network 1.1.1.0 mask 255.255.255.0 Мы должны убедиться, что ввели правильную маску подсети. Итак, видно, что мы узнали префикс, и R2 устанавливает его в таблицу маршрутизации ... проблема решена! Итог урока: введите правильную маску подсети ... BGP требователен! Урок 2 Давайте перейдем к следующей проблеме. Системный администратор из AS1 хочет объявить summary в AS 2. Системный администратор из AS 2 жалуется, однако, что он ничего не получает..., давайте, выясним, что происходит не так! Вот конфигурация. Вы можете увидеть команду aggregate-address на R1 для сети 172.16.0.0 / 16. Жаль ... префиксы не были получены R2. Здесь мы можем проверить две вещи: Проверьте, не блокирует ли distribute-list префиксы, как это мы сделали в предыдущем занятии. Посмотрите, что R1 имеет в своей таблице маршрутизации (Правило: "не могу объявлять то, чего у меня нет!"). Давайте начнем с таблицы маршрутизации R1. Из предыдущих уроков вы знаете, как выглядит distribute-list. Здесь нет ничего, что выглядело бы даже близко к 172.16.0.0 /16. Если мы хотим объявить summary, мы должны сначала поместить что-то в таблицу маршрутизации R1. Рассмотрим различные варианты: R1(config)#interface loopback 0 R1(config-if)#ip address 172.16.0.1 255.255.255.0 R1(config-if)#exit R1(config)#router bgp 1 R1(config-router)#network 172.16.0.0 mask 255.255.255.0 Это вариант 1. Создам интерфейс loopback0 и настроим IP-адрес, который попадает в диапазон команды aggregate-address. Теперь мы видим summary в таблице маршрутизации R2. По умолчанию он все равно будет объявлять другие префиксы. Если вы не хотите этого, вам нужно использовать команду aggregate-address summaryonly! Второй вариант объявления summary: R1(config)#ip route 172.16.0.0 255.255.0.0 null 0 R1(config)#router bgp 1 R1(config-router)#network 172.16.0.0 mask 255.255.0.0 Сначала мы поместим сеть 172.16.0.0 / 16 в таблицу маршрутизации, создав статический маршрут и указав его на интерфейсе null0. Во-вторых, будем использовать команду network для BGP для объявления этой сети. Итог урока: Вы не можете объявлять то, чего у вас нет. Создайте статический маршрут и укажите его на интерфейсе null0, чтобы создать loopback интерфейс с префиксом, который попадает в диапазон суммарных адресов. Урок 3 Следующая проблема. Вы работаете системным администратором в AS 1, и однажды получаете телефонный звонок от системного администратора AS 2, который интересуется у вас, почему вы публикуете сводку для 1.0.0.0 / 8. Вы понятия не имеете, о чем, он говорит, поэтому решаете проверить свой роутер. Это то, что видит системный администратор на R2. Мы видим, что у нас есть сеть 1.0.0.0 / 8 в таблице BGP на R1. Давайте проверим его таблицу маршрутизации. Сеть 1.1.1.0 / 24 настроена на loopback интерфейс, но она находится в таблице BGP как 1.0.0.0 / 8. Это может означать только одну вещь ... суммирование. Беглый взгляд на выводы команды show ip protocols показывает, что автоматическое суммирование включено. Отключим это: R1(config)#router bgp 1 R1(config-router)#no auto-summary Мы отключим его на R1. Теперь мы видим 1.1.1.0 / 24 на R2 ... проблема решена! Итог урока: если вы видите classful сети в своей таблице BGP, возможно, вы включили автоматическое суммирование. Некоторые из проблем, которые были рассмотрены, можно легко решить, просто посмотрев и/или сравнив результаты команды "show run". И это правда, но имейте в виду, что у вас не всегда есть доступ ко ВСЕМ маршрутизаторам в сети, поэтому, возможно, нет способа сравнить конфигурации. Между устройствами, на которых вы пытаетесь устранить неисправности или которые вызывают проблемы, может быть коммутатор или другой маршрутизатор. Использование соответствующих команд show и debug покажет вам, что именно делает ваш маршрутизатор и что он сообщает другим маршрутизаторам. Урок 4 Та же топология, другая проблема. Персонал из AS 2 жалуются, что они ничего не получают от AS 1. Для усложнения проблемы, конфигурация не будет показана. Для начала, мы видим, что R2 не получает никаких префиксов. Так же можем убедиться, что R1 не имеет каких-либо distribute-lists. Мы видим, что R1 действительно имеет сеть 1.1.1.0 /24 в своей таблице маршрутизации, так почему же он не объявляет ее в R2? Давайте посмотрим, может на R1 есть какие-то особенные настройки для своего соседа R2: Будем использовать команду show ip bgp neighbors, чтобы увидеть подробную информацию о R2. Мы видим, что route-map была применена к R2 и называется "NEIGHBORS". Имейте в виду, что помимо distribute-lists мы можем использовать также route-map для фильтрации BGP. Существует только оператор соответствия для prefix-list "PREFIXES". Вот наш нарушитель спокойствия ... он запрещает сеть 1.1.1.0 / 24! R1(config)#router bgp 1 R1(config-router)#no neighbor 192.168.12.2 route-map NEIGHBORS out Удалим route-map И наконец R2 узнал об этом префиксе ... проблема решена! Итог урока: убедитесь, что нет route-map, блокирующих объявление префиксов. BGP иногда может быть очень медленным, особенно когда вы ждете результатов, когда вы работаете на тестовом или лабораторном оборудовании. "Clear ip bgp *" - это хороший способ ускорить его ... просто не делайте этого на маршрутизаторах в производственной сети) Урок 5 Наконец, третий участник выходит на арену, чтобы продемонстрировать новую проблему. R1-это объявляемая сеть 1.1.1.0 / 24, но R3 не изучает эту сеть. Здесь представлены конфигураций: Соседство настроено, R1 - объявляемая сеть 1.1.1.0 / 24. R3#show ip route bgp Мы можем видеть сеть 1.1.1.0 / 24 в таблице маршрутизации R2, но она не отображается на R3. Технически проблем нет. Если вы внимательно посмотрите на конфигурацию BGP всех трех маршрутизаторов, то увидите, что существует только соседство BGP между R1 и R2 и между R2 и R3. Из-за split horizon IBGP R2 не пересылает сеть 1.1.1.0 / 24 в направлении R3. Чтобы это исправить, нам нужно настроить R1 и R3, чтобы они стали соседями. R1(config)#ip route 192.168.23.3 255.255.255.255 192.168.12.2 R3(config)#ip route 192.168.12.1 255.255.255.255 192.168.23.2 Если мы собираемся настроить соседство BGP между R1 и R3, нам нужно убедиться, что они могут достигать друг друга. Мы можем использовать статическую маршрутизацию или IGP ... чтобы упростить задачу, на этот раз мы будем использовать статический маршрут. R1(config)#router bgp 1 R1(config-router)#neighbor 192.168.23.3 remote-as 1 R3(config)#router bgp 1 R3(config-router)#neighbor 192.168.12.1 remote-as 1 Примените правильные настройки команды neighbor BGP. И R3 имеет доступ к сети 1.1.1.0 / 24! Итог урока: соседство по IBGP должно быть полным циклом! Другим решением было бы использование route-reflector или confederation. Урок 6 Очередная проблема. R3 является объявляемой сетью 3.3.3.0 / 24 через EBGP, а R2 устанавливает ее в таблицу маршрутизации. R1, однако, не имеет этой сети в своей таблице маршрутизации. Вот конфигурации: Вот конфигурации. Для простоты мы используем IP-адреса физического интерфейса для настройки соседей BGP. Мы можем проверить, что сеть 3.3.3.0 / 24 находится в таблице маршрутизации R2. R1#show ip route bgp Однако в таблице маршрутизации R1 ничего нет. Первое, что мы должны проверить - это таблицу BGP. Мы видим, что он находится в таблице BGP, и * указывает, что это допустимый маршрут. Однако мы не видим символа >, который указывает лучший путь. По какой-то причине BGP не может установить эту запись в таблице маршрутизации. Внимательно посмотрите на следующий IP-адрес прыжка (192.168.23.3). Доступен ли этот IP-адрес? R1 понятия не имеет, как достичь 192.168.23.3, поэтому наш следующий прыжок недостижим. Есть два способа, как мы можем справиться с этой проблемой: Используйте статический маршрут или IGP, чтобы сделать этот next hop IP-адрес доступным. Измените next hop IP-адрес. Мы изменим IP-адрес следующего прыжка, так как мы достаточно изучили применение статических маршрутов и IGPs. R2(config)#router bgp 1 R2(config-router)#neighbor 192.168.12.1 next-hop-self Эта команда изменит IP-адрес следующего перехода на IP-адрес R2. Теперь мы видим символ >, который указывает, что этот путь был выбран как лучший. IP-адрес следующего перехода теперь 192.168.12.2. Ура! Теперь он есть в таблице маршрутизации. Мы уже закончили? Если наша цель состояла в том, чтобы она отобразилась в таблице маршрутизации, то мы закончили...однако есть еще одна проблема. Наш пинг не удался. R1 и R2 оба имеют сеть 3.3.3.0 / 24 в своей таблице маршрутизации, поэтому мы знаем, что они знают, куда пересылать IP-пакеты. Давайте взглянем на R3: R3 получит IP-пакет с пунктом назначения 3.3.3.3 и источником 192.168.12.1. Из таблицы маршрутизации видно, что она не знает, куда отправлять IP-пакеты, предназначенные для 192.168.12.1. Исправим это: R2(config)#router bgp 1 R2(config-router)#network 192.168.12.0 mask 255.255.255.0 Мы будем объявлять сеть 192.168.12.0 / 24 на R2. Теперь R3 знает, куда отправлять трафик для 192.168.12.0 / 24. Проблема устранена! Итог урока: убедитесь, что IP-адрес следующего перехода доступен, чтобы маршруты могли быть установлены в таблице маршрутизации, и чтобы все необходимые сети были достижимы.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59