По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Пока не начали, ознакомьтесь с материалом про обнаружение соседей в сетях.
Реактивное распределение достижимости
Возвращаясь к рисунку 9 в качестве справки, предположим, что развернута реактивная плоскость управления, и B хотел бы начать обмен потоками данных с G. Как C может разработать информацию о пересылке, необходимую для правильного переключения этого трафика?
Маршрутизатор может отправить запрос по сети или отправить запрос контроллеру, чтобы обнаружить путь к месту назначения. Например:
Когда B впервые подключается к сети, и C узнает об этом вновь подключенном хосте, C может отправить информацию о B в качестве достижимого пункта назначения на контроллер, подключенный к сети.
Точно так же, когда G подключается к сети и D узнает об этом вновь подключенном хосте, D может отправить информацию о G как о достижимом пункте назначения контроллеру, подключенному к сети.
Поскольку контроллер узнает о каждом хосте (или достижимом месте назначения), подключенном к сети (а в некоторых системах, также обо всей топологии сети), когда C необходимо узнать, как достичь хоста G, маршрутизатор может запросить контроллер, который может предоставить эту информацию.
Примечание. Концепция централизованного контроллера подразумевает, что один контроллер предоставляет информацию для всей сети, но это не то, как термин централизованная плоскость управления обычно используется в мире сетевой инженерии. Однако идея централизации в сетевой инженерии довольно расплывчата. Вместо того, чтобы указывать на отдельное устройство, термин "централизованный" обычно используется для обозначения непереносимых скачков по сети и не вычисляемых каждым сетевым устройством независимо.
Маршрутизатор (или хост) может отправить пакет проводника, который записывает маршрут от источника к месту назначения и сообщает эту информацию источнику проводника, который затем используется как исходный маршрут. Рисунок 10 иллюстрирует это.
Используя рисунок 10 и предполагая исходную маршрутизацию на основе хоста:
Хосту A необходимо отправить пакет H, но у него нет пути.
A отправляет explorer на свой шлюз по умолчанию, маршрутизатор C.
C не имеет маршрута к месту назначения, поэтому он пересылает explorer пакет по всем каналам, кроме того, по которому он получил пакет; следовательно, к B, D и E.
B является хостом, не имеет дополнительных интерфейсов и не является целью explorer, поэтому он игнорирует explorer пакет.
Ни у D, ни у E нет пути к H, поэтому они оба перенаправляют explorer на все интерфейсы, кроме того, на котором они получили пакет; следовательно, на канал с множественным доступом, совместно используемый между ними и F.
F получает две копии одного и того же explorer пакета; он выбирает один на основе некоторых локальных критериев (таких как первый полученный или некоторая политика плоскости управления) и пересылает его на все интерфейсы, на которых он не получил пакет, к G.
G получает пакет и, учитывая, что у него нет пути к H, пересылает его на единственное другое соединение, которое у него есть, что ведет к H.
H принимает explorer и отвечает.
В этой схеме каждое устройство на пути добавляет себя в список пройденных узлов перед пересылкой explorer пакета на все интерфейсы, кроме того, на котором он был получен. Таким образом, когда H получает explorer пакет (который в конечном итоге направлен на поиск пути к H), пакет теперь описывает полный путь от A до H. Когда H отвечает explorer, он помещает этот путь в тело пакета; когда A получит ответ, у него теперь будет полный путь от A до H.
Примечание. В некоторых реализациях A не будет ни генерировать, ни получать ответ на пакет explorer. А с первого роутера, может выполнять эти функции. Точно так же сам H может не отвечать на эти пакеты explorer, а скорее G или любое другое сетевое устройство вдоль пути, имеющее информацию о том, как добраться до G. Однако в этих случаях общая концепция и обработка остаются теми же.
Затем, чтобы отправить пакеты в H, A вставляет этот путь в заголовок пакета в виде исходного маршрута, содержащего путь [A, C, D, F, G, H]. Когда каждый маршрутизатор получает этот пакет, он проверяет исходный маршрут в заголовке, чтобы определить, на какой маршрутизатор перенаправить трафик следующему. Например, C проверит информацию о маршруте от источника в заголовке пакета и определит, что пакет должен быть отправлен в D следующим, в то время как D изучит эту информацию и определит, что ему нужно отправить пакет F.
Примечание. В некоторых реализациях каждый explorer фактически отправляется в пункт назначения, который затем определяет, по какому пути должен идти трафик. На самом деле существует несколько различных способов реализации исходной маршрутизации; процесс, приведенный здесь, является лишь одним примером, объясняющим общую идею исходной маршрутизации.
Упреждающее распределение доступности
Проактивные плоскости управления, в отличие от реактивных плоскостей управления, распределяют информацию о достижимости и топологии по всей сети, когда информация становится доступной, а не тогда, когда она необходима для пересылки пакетов. Основная проблема, с которой сталкиваются плоскости упреждающего управления, заключается в обеспечении надежной передачи информации о доступности и топологии между узлами в сети, в результате чего все устройства имеют одинаковую информацию о доступности.
Удаление информации о плоскости управления может привести к возникновению постоянных петель маршрутизации или к созданию черных дыр маршрутизации (так называемых, потому что они потребляют трафик, передаваемый в пункты назначения без следа), и то и другое серьезно снижает полезность сети для приложений. Существует несколько широко используемых механизмов для обеспечения надежной передачи информации плоскости управления по сети.
Плоскость управления может периодически передавать информацию, задерживая более старую информацию. Это похоже на формирование соседей, поскольку каждый маршрутизатор в сети будет передавать имеющуюся информацию о доступности всем соседям (или на всех интерфейсах, в зависимости от плоскости управления) на основе таймера, обычно называемого таймером обновления или объявления. Информация о доступности, однажды полученная, хранится в локальной таблице и истекает по таймауту в течение некоторого периода времени, часто называемого таймером удержания (опять же, как при обнаружении соседа).
Остальные описанные здесь механизмы полагаются на существующую систему обнаружения соседей, чтобы гарантировать надежную доставку - и постоянную надежность - информации о доступности. Во всех этих системах:
Список соседей используется не только для управления передачей новой информации о доступности, но и для проверки правильности получения информации о доступности.
Список соседей используется не только для управления передачей новой информации о доступности, но и для проверки правильности получения информации о доступности.
В контексте распределения достижимости на основе соседей существует несколько обычно используемых механизмов для передачи определенной информации о доступности с устройства на устройство; часто любая заданная плоскость управления будет использовать более одного из описанных здесь методов.
Плоскость управления может использовать порядковые номера (или какой-либо другой механизм) для обеспечения правильной репликации. Порядковые номера могут фактически использоваться для описания отдельных пакетов и больших блоков информации о доступности; Рисунок 11 иллюстрирует это.
Получив пакет, получатель может отправить подтверждение получения пакета, отметив порядковые номера, которые он получил. Отдельный порядковый номер может использоваться для описания достижимости отдельного сетевого уровня.
Информация (NLRI), передаваемая по сети. Информация NLRI, распределенная по нескольким пакетам, затем может быть описана с использованием одного порядкового номера.
Плоскость управления может описывать базу данных для обеспечения правильной репликации. Например, плоскость управления может описывать информацию в базе данных как:
Список порядковых номеров, соответствующих отдельным записям, содержащий информацию о доступности, содержащуюся в базе данных.
Группы смежных порядковых номеров, содержащиеся в базе данных (несколько более компактный способ представления всех порядковых номеров)
Набор порядковых номеров в паре с хешами информации в каждой записи информации о доступности; это имеет то преимущество, что не только описывает записи в базе данных, но также дает возможность получателю проверять содержимое каждой записи, но без переноса всей базы данных для выполнения проверки.
Хэш по блокам записей о достижимости, содержащихся в базе данных, который может быть вычислен получателем для тех же записей и напрямую сравнен, чтобы определить, отсутствуют ли записи.
Эти типы дескрипторов баз данных могут передаваться периодически, или только при наличии изменений, или даже в других конкретных ситуациях, чтобы не только обеспечить синхронизацию баз данных сетевыми устройствами, но и определить, что отсутствует или находится в ошибке, поэтому дополнительная информация может быть запрошена.
Каждая из этих схем имеет преимущества и недостатки. Как правило, протоколы реализуют схему, которая позволяет реализации не только проверять отсутствующую информацию, но также информацию, которая была случайно повреждена либо в памяти, либо во время передачи.
Как следует из названий, проприетарный протокол компании Cisco System EIGRP (Enhanced Interior Gateway Routing Protocol), это протокол «внутреннего шлюза». EIGRP имеет множество преимуществ по сравнению с протоколом RIP (Routing Information Protocol) и своим непосредственным предшественником, протоколом IGRP (Interior Gateway Routing Protocol). По существу, EIGRP это расширенная версия протокола IGRP. Как и RIP, IGRP известен как дистанционно – векторный протокол, но по сравнению с ним он имеет улучшенные характеристики алгоритма расчета оптимального пути до пункта назначения. Метрики IGRP основываются на таких параметрах как полоса пропускания и задержка, в тоже время для протокола RIP важным является длинна маршрута, выраженная в «хопах», то есть количестве узлов на пути следования.
Протокол EIGRP включает в себя алгоритмы, которые часто встречаются в продвинутых протокол маршрутизации, которые работают по принципу «состояния канала». EIGRP использует оптимизированный по сравнению с RIP и IGRP метод предотвращения петель в сети, обеспечивая 100 – процентную гарантию отсутствия петель.
Важное преимущество EIGRP – это высокий показатель масштабируемости и высокая скорость сходимости сети. Итак, давайте разберем конкретные преимущества EIGRP по сравнению с IGRP:
Быстрая сходимость
Поддержка CIDR (бесклассовая адресация) и VLSM (маска подсети переменной длины)
Использует более совершенный алгоритм DUAL (Diffusing Update Algorithm), для определения качества того или иного маршрута.
Может использовать маршруты других протоколов маршрутизации.
Протокол совместим с IGRP и может выполнять маршрутизацию таких протоколов как IPX и Apple AppleTalk
EIGRP представляется как гибридный протокол, который содержит в себе как функционал дистанционно – векторного протокола маршрутизации, так и «состояния канала». Перечислим следующие характеристики:
EIGRP использует множество метрик для определения качества маршрута в добавок к «дистанции»:
Полоса пропускания и задержка (метрики по умолчанию)
Надежность, загрузка, MTU (опциональные метрики)
Оценка качества маршрута с помощью DUAL2
EIGRP, как и протокол OSPF, отправляет сообщения об изменении маршрутизации только тогда, когда в сети случаются какие-либо изменения (для сравнения, RIP и IGRP обновляет широковещательные сообщения периодически)
Протокол EIGRP в рамках сходимости, обменивается только «Hello» сообщениями с соседними маршрутизаторами.
EIGRP не поддерживается на маршрутизаторах других компаний, кроме Cisco.
EIGRP использует следующие административные значения для маршрутов:
Значение 90, для маршрутов полученных по EIGRP
Значение 170, для маршрутов полученных в рамках других протоколов маршрутизации
Компоненты EIGRP
Протокол EIGRP (Enhanced Interior Gateway Routing Protocol) состоит из 4 – х важных компонентов:
Обнаружение соседей
Речь пойдет о технологии, которую используют маршрутизаторы Cisco чтобы обнаружить присутствие напрямую подключенных маршрутизаторов соседей. Процесс обнаружения, позволяет маршрутизаторам использовать небольшие пакеты с маленькой нагрузкой, в рамках которых они передают сообщения «Hello». Отправка подобных пакетов позволяет определить, нормально ли функционирует сосед, или же он недоступен. Маршрутизатор отвечает на эти сообщения, и только после этого маршрутизаторы начинают работу. В случае не ответа, маршрутизатор считается неактивным и процесса коммуникаций не происходит.
Reliable Transport Protocol (RTP)
Или другими словами, надежный транспортный протокол. Обеспечивает надежную и гарантированную доставку юникаст или мультикаст сообщения соседям маршрутизаторам. В рамках эффективного использования RTP, маршрутизаторы используют его только по необходимости.
DUAL алгоритм
Алгоритм маршрутизации, который используется EIGRP для расчета, определения и отслеживания маршрутов без петель. DUAL использует метрики для определения наиболее оптимального маршрута основываясь на «feasible successor» (или «возможный приемник»,о котором мы расскажем во второй части статьи).
Дополнительные модули протокола
Независимые модули, которые используются протоколом EIGRP в рамках сетевого уровня модели OSI для отправки и получения сообщений. Модуль IP для протокола EIGRP носит название IP-EIGRP и предназначен для отправки и получения EIGRP пакетов инкапсулированных в IP – пакеты. IP-EIGRP взаимодействует с DUAL для вычисления маршрутов, которые в дальнейшем хранятся в таблицах маршрутизации.
Во второй части статьи мы продолжим рассказ о таблицах маршрутизации EIGRP
Данная статья посвящена монтированию и демонтированию файловых систем в Linux. Под этим понятием понимается подключение разделов жестких дисков, различных носителей и прочих файловых систем, которые могут находится на различных носителях информации. Получение к ним доступа, отключение автоматически и в ручном режиме. В статье будут рассмотрены следующие вопросы:
Подключение и отключение файловых систем вручную.
Управление автоматическим монтированием файловых систем.
Подключение съемных носителей информации.
Основные команды, которые позволяют решать вопросы указанные выше:
mount устройство точка_монтирования
umount устройство или umount точка_монтирования.
/etc/fstab: устройство точка монтирования тип файловой системы параметры dump pass
Данный файл – это файл настройки автоматического подключения файловых систем. Точкой монтирования, является пустой каталог на нашей файловой системе.
К виртуальной машине подключен диск, определяемый операционной системой /dev/sdc, а на нем создан раздел /dev/sdc1 с файловой системой ext4. Мы можем посмотреть, что на нем ls –l /dev/sdc1.
Для того, чтобы посмотреть, что есть на этом диске необходимо создать точку монтирования. Для этой цели подойдет любая папка. Если мы посмотрим корневые папки командой ls /, то увидим следующую картину.
Правилом хорошего тона является монтирование файловых систем в папки mnt и media. Обычно папку mnt используют для монтирования разделов, а папку media для монтирования съемных носителей информации. Т.е папка mnt пустая и туда у нас ничего не монтируется, можно создать внутри папку mkdir /mnt/hard. Теперь мы можем смонтировать в данную папку наш жесткий диск, подключенный к виртуальной машине. Монтирование осуществляется следующим образом mount /dev/sdc1 /mnt/hard или mount –t ext4 /dev/sdc1 /mnt/hard. Linux очень хорошо самостоятельно определяет тип файловой системы и в написании команд можно данную опцию опустить.
Как мы видим все смонтировалось и так как файловая система журналируемая появилась папочка lost+found.
Вообще в линуксе вся файловая система –это такое иерархическое дерево с файлами и папками, подпапками. Все эти файлы и папки вообще могут находится на разных устройствах, в том числе и на сетевых устройствах. Это может быть даже сетевая папка, подключенная к нашей системе. Мы подключили /dev/sdc1 в папку /mnt/hard.
Мы можем выполнить команду mount, которая покажет нам, что и куда смонтированно.
Мы видим все файловые системы смонтированные. В том числе только, что примонтированный жесткий диск. Так же мы можем увидеть виртуальные файловые системы, типа proc.
Виртуальная файловая система proc содержит все запущенные процессы и смонтирована в папку /proc. Как мы видим из скриншота их достаточно много. Помимо тех файловых систем, которые созданы на носителях, примонтированно много виртуальных файловых систем. Можно увидеть, что они смонтированы в разные папки согласно их предназначению.
Отмонтировать можно командой umount /dev/sdc1. Следовательно мы можем увидеть ls /mnt/hard, что папка пустая. Иногда при выполнении команды на отмонтирование система ругается, это происходит если мы данную файловую систему, каким-нибудь образом используем, например, если открыт файл с данной папки или подпапки. Следовательно, необходимо завершить все операции, после этого система нам даст отмонтировать.
Чтобы вот так вручную не подключать или не отключать разделы, есть файлик /etc/fstab. В нем находятся настройки автоматического монтирования файловых систем.
Если в данном файлике не сделать запись, то после перезагрузки система не подключит подмонтированную файловую систему, автоматически. Что касается настройки: в файле мы указываем устройство с файловой системой, затем точку монтирования, тип файловой системы, опции и пара настроек. Dump – говорит нам о том, сохранять ли файлы автоматом на данной файловой системе при отключении системы. Т.е если у нас пропало питание или идет завершение работы. Принимаемые значения 1 - файлики будут сохранятся, 0 не будет сохранятся. Параметр Pass указывает порядок проверки файловых систем. Обычно 1 у корневой файловой системы, у всех последующих 2, у съемных носителей 0. Операционная система Linux обычно позволяет смонтировать файловую систему по UUID. Т.е устройство можно указывать не только в явном виде, но и по метке, и по идентификатору. Указывать по идентификатору надежнее мы можем переименовать устройство или переставить жесткие диски и тогда загрузочный раздел окажется не /dev/sda1, а например /dev/sdc1. Чтобы подобного не произошло, лучше файловые системы прописывать с помощью идентификатора. Потому, что идентификаторы прописаны жестко к каждому разделу и изменить мы их не можем. И это будет более стабильная работа. В нашем же случае мы видим, что основной раздел смонтирован. Имеет файловую систему ext4 . Про опции монтирования можно прочитать в мануале к файлу fstab.
Ну и как можно увидеть примонтирован еще один раздел без точки монтирования – это раздел подкачки swap.
Можно еще одну интересную вещь заметить, при попытке нового монтирования файловой системы от обычного пользователя операционная система ругнется, что только пользователь root может это сделать, но как только мы пропишем данное монтирование в файл /etc/fstab и скажем, что пользователь обычный имеет право монтировать данную файловую систему, то система совершенно спокойно даст примонтировать без повышения привилегий. Соответственно редактировать данный файл совершенно просто. Открываем его любым редактором в режиме суперпользователя и добавляем данные по монтируемой файловой системе. Если при монтировании вы не знаете какой тип файловой системы, можно просто указать auto и операционная система автоматически ее определит тип файловой системы при монтировании. Далее интересная вещь – это опции при монтировании можно указать defaults (чтение (ro), запись (rw), выполнение (execute), nouser). Параметр user- т.е любой пользователь может монтировать и демонтировать данную файловую систему, если данные параметр не указать, тогда только суперпользователь сможет выполнять данные действия. Параметр auto – т.е данный параметр будет автоматически подключать данную файловую систему при старте компьютера или сервера. Параметр noexec - данный параметр запрещает запуск исполняемых файлов на данной файловой системе. После добавления записи в файл /etc/fstab , мы можем примонтировать файловую систему командой от обычного пользователя mount /mnt/hard. Система обратится к файлу /etc/fstab проверит запись и опции, если есть указанная точка монтирования и в опциях запись user система успешно подмонтирует файловую систему. Аналогично можно провести обратную операцию размонтирования unmount /mnt/hard.
Есть хорошая команда, которой приходится пользоваться, особенно если создаем raid массивы – это blkid. Данная команда позволяет посмотреть блочные устройства. Работает от суперпользователя sudo blkid /dev/sdc1.
Команда показывает, какой uuid имеется у устройства. И мы можем в файле /etc/fstab, можем указать не имя устройства, а UUID = a783a365-3758-47bd-9f2d-1f5b4155f4ca. И это будет надежнее указание UUID, чем имена дисков, потому что имена дисков могут меняться.
Раньше в файле /etc/fstab так же прописывалось монтирование съемных носителей USB флешки, CD-ROM и т.д создавалась запись для файловой системы с правами read-only и что при необходимости смонтировать могут любые пользователи, автоматически флопик и CD-ROM не монтировались. Современные дистрибутивы, включаю Ubuntu последних версий, в том числе пользовательские, с красивыми оболочками Gnome и KDE есть файловый менеджер Nautilus. У данного файлового менеджера есть свои настройки, которые позволяют автоматически монтировать, все что мы подключаем.
В случае если мы работаем на серверной операционной системе, например, Ubuntu или CentOS, то понятно в дефолтной конфигурации у нас нету авто монтирования и прочих радостей десктопной версии. Поэтому делаем простую вещь. Вставляем носитель с файловой системой, второй шаг blkid находим наше устройство и третий шаг монтируем, командой mount.
Правилом хорошего тона является монтирование всех устройств в папку /media. Здесь обычно располагаются папки cdrom, можно создать папки floppy или usb. И последний нюанс, после того, как вы поработали с флешкой и от монтировали, необходимо корректно ее вытащить. Даем команду eject.