• XSS.stack #1 – первый литературный журнал от юзеров форума

Доки по сетям

Отслеживать

AKella

(L2) cache
Пользователь
Регистрация
30.12.2004
Сообщения
410
Реакции
15
[mod] В общем вижу что уже есть несколько постов со статьями/книгами => чтобы не засорять раздел, такие темы создавать только здесь(нарушители будут наказаны). Кидаем сюда книги и статьи с комментариями. Очень большая просьба не кидать сюда все, что под руку попадется. P.S. не оффтопим.[/mod]
Вашему вниманию предлогается книга "Локальные сети для начинающих".
Свои коммунтарии оставляем ниже.
:zns5: Скачать|Download
 
Системы сетевого/системного управления: принципы создания
Михаил Федотов


В настоящее время в связи с интеграцией корпоративных сетей передачи данных все более остро встает проблема управления распределенными гетерогенными сетями, состоящими из множества локальных сетей, функционирующих на основе различных стандартов и протоколов. Поставленная в заголовке статьи цель — создание системы интегрированного сетевого управления — требует решения целого ряда задач. В их число входят:

традиционные задачи сетевого управления (управление конфигурацией, управление производительностью, управление сбоями, управление безопасностью, учет использования ресурсов);
управление распределенными приложениями в гетерогенных сетях;
мониторинг текущего состояния системно-технического обеспечения организации (ведение визуализированной базы данных, содержащей полную информацию как о технических, так и об учетных параметрах всего технического и программного обеспечения, имеющегося в той или иной организации);
поддержка принятия решений по модернизации технического и программного обеспечения с учетом текущего состояния технического прогресса, информации о производителях и поставщиках технических и программных средств и о сравнительных характеристиках этих продуктов;
управление модернизацией (контроль и управление установкой нового технического и программного обеспечения, включая оптимизацию этого процесса);
моделирование работы существующих сетей (включая анализ нагрузок на отдельные их участки и поддержку принятия решений по перепланированию).
Следует заметить, что ни один из имеющихся на сегодняшний день на рынке программного обеспечения продуктов не решает целиком ни одной из перечисленных задач. Поэтому наиболее целесообразным решением в данном случае является либо разработка такой интегрированной системы самостоятельно, либо заказ на ее разработку фирме — системному интегратору.

Далее мы рассмотрим существующие в настоящее время продукты, ориентированные на решение перечисленных выше задач, и опишем возможный путь их интеграции в единую платформу сетевого/системного управления.

Обзор задач
Сетевое управление
Напомним, что в настоящее время под собственно сетевым управлением обычно подразумевают совокупность пяти взаимосвязанных задач, в число которых входят:

Управление конфигурацией (Configuration Management), включающее:

регистрацию устройств сети, их сетевых адресов и идентификаторов;
определение конфигурации элементов сети;
определение параметров сетевой операционной системы;
описание протоколов сетевых взаимодействий;
построение топологической карты физических соединений сети.
Управление безопасностью (Security Management) подразумевает поддержку служб и отчетов обеспечения защиты информации, что предполагает:

управление доступом и полномочиями пользователей;
контроль и управление межсетевыми взаимодействиями;
защиту от несанкционированного доступа извне;
обнаружение и устранение вирусов.
Управление сбоями (Fault & Problem Management), в которое входит:

наблюдение за трафиком;
обнаружение чрезмерного числа конфликтов и повторных передач данных;
предупреждение и профилактика ошибок путем анализа работы сети;
наблюдение за кабельной системой и состоянием сетевых устройств;
мониторинг удаленных сегментов и межсетевых связей.
Учет использования ресурсов (Accounting Management) предполагает слежение за использованием и оплатой сетевых услуг, в том числе:

регистрацию и учет использования сетевых ресурсов;
регистрацию лицензий и учет использования программных средств;
управление приоритетами пользователей и приложений.
Управление производительностью (Performance Management) — это оценка состояния ресурсов и эффективности их использования, что предполагает:

сбор и анализ статистических данных о функционировании сети;
анализ трафика;
планирование и оценку эффективности использования ресурсов сети;
выявление узких мест сети;
анализ сетевых протоколов;
планирование развития сети.
К продуктам, в той или иной степени реализующим все пять задач сетевого управления, на сегодняшний день относятся:

OpenView от Hewlett-Packard;
NetView (Tivoli) от IBM;
Spectrum от Cabletron;
Solstice от SunSoft (Sun планирует уход с этого рынка);
CA Unicenter от Computer Associates.
Следует заметить, что, во-первых, все эти системы по своим функциональным возможностям примерно одинаковы, и, во-вторых, ни один из перечисленных продуктов не реализует все пять задач в полной мере. Стоимость подобных систем составляет от 5 до 100 тысяч долларов, в зависимости от комплектации.

Кроме перечисленных пяти интегрированных продуктов, существует множество решений от сравнительно небольших фирм, в которых реализованы отдельные функции, причем обычно далеко не в полном объеме. При этом продукты третьих фирм не обладают средствами интеграции друг с другом и обычно не поддерживают разработку дополнительных модулей (add-on’s) сторонними разработчиками, не имеют средств работы с внешними базами данных (Oracle, Informix, Ingres) и поддерживают ограниченный спектр сетевых устройств.

Управление распределенными приложениями
Под управлением распределенными приложениями мы будем понимать мониторинг использования приложениями сетевых и локальных ресурсов и возможность изменения управляемых параметров работы этих приложений для достижения наиболее эффективной эксплуатации имеющихся ресурсов.

Следует заметить, что при подобной постановке задачи подходящих готовых средств на современном рынке программного обеспечения просто не существует. Основная причина этого в том, что в настоящее время не существует общего стандарта на протокол обмена информацией с распределенными приложениями. Если для технических устройств есть SNMP, CMIP и RMON, то соответствующий стандарт для ПО еще не принят. Вследствие этого существующие решения не охватывают всего спектра ПО.

Основным подходом к решению проблемы в настоящее время является разработка MIB (Management Information Base) для приложений, что позволяет при наличии соответствующих программ-агентов работать с этими приложениями так же, как с физическими сетевыми устройствами. При этом приложения становятся SNMP-управляемыми. Подобный подход применяет, в частности, фирма Microsoft для своих DHCP- и WINS-серверов, входящих в состав операционной системы Windows NT. Недостатком данного метода является то, что фактически в этом случае возможно управление только серверной частью распределенного приложения, а учет использования сетевых ресурсов для всех компонентов системы невозможен.

Другим подходом к данной задаче является концепция Web-управления, при котором те же функции, что и в случае с SNMP, выполняются через стандартные браузеры (например, Netscape Navigator или Microsoft Internet Explorer). В таком случае, однако, приходится интегрировать в приложение, которым предполагается управлять, Web-сервер, что является достаточно нетривиальной задачей. Кроме того, отмеченные выше недостатки при этом сохраняются.

В любом из перечисленных случаев управление существующими приложениями, особенно если они создавались несколько лет назад, становится практически нереализуемой задачей.

Мониторинг технического и программного обеспечения
Может показаться, что данная задача является повторением задачи номер 1, однако это не совсем так. Сетевое управление хоть и подразумевает ведение базы устройств, однако во всех перечисленных продуктах чисто сетевого управления поддерживаются только технические параметры, причем далеко не все и не для всех устройств. Кроме того, средств добавления интересующих пользователя параметров в базу устройств просто нет.

Некоторые функции мониторинга обеспечивают такие платформы системного управления, как Microsoft System Management Server, который позволяет создавать и поддерживать в актуальном состоянии визуализированную базу данных, содержащую информацию как о техническом, так и о программном обеспечении, имеющемся в организации, однако возможности представления и анализа имеющейся информации в подобных системах довольно ограничены.

В качестве другого подхода к решению данной задачи можно предложить применение СУБД, таких как Informix или Oracle, в которых существуют мощные возможности хранения и выборки интересующей пользователя информации о тех или иных устройствах и программном обеспечении. Недостатком такого подхода, однако, является, во-первых, необходимость поддержания информации в актуальном состоянии, и, во-вторых, отсутствие развитых средств визуализации топологии сети.

Поддержка принятия решений по модернизации комплекса технических и программных средств
Как известно, темпы развития современных технических и программных средств настолько высоки, что время морального устаревания той или иной технологии измеряется не десятилетиями, как в большинстве областей человеческой деятельности, а месяцами. С другой стороны, в любой достаточно крупной организации существует проблема, связанная с постоянным увеличением числа решаемых задач и объемов обрабатываемой информации.

Данные факторы приводят к необходимости создания системы, которая обеспечивала бы поддержку принятия решений по модернизации существующего технического и программного обеспечения для эффективного осуществления предприятием своей основной деятельности. Данная система должна учитывать:

состав технических и программных средств, имеющихся в организации;
текущее состояние рынка технических и программных средств;
информацию о производителях ПО и средств вычислительной техники и их номенклатуре;
сравнительные характеристики однотипных технических и программных средств;
сведения о поставщиках технических средств и ПО (номенклатура, уровень цен, надежность, уровень сервиса и т.п.).
Для решения поставленной задачи с учетом всей необходимой информации в настоящий момент пригодны только экспертные системы, к ведущим производителям которых относятся фирмы Gensym (продукт G2), Talarian (RTWorks), COGSYS. Данные фирмы предлагают не готовые экспертные системы для решения данной задачи, а развитые инструментарии их создания, поддерживающие как традиционные парадигмы (графический интерфейс пользователя, объектная ориентированность, управление по событиям), так и парадигмы искусственного интеллекта (продукционные правила, механизмы прямого и обратного вывода и т.п.).

Управление модернизацией
Данная задача очень тесно смыкается с предыдущей, так как после принятия решения по модернизации и осуществления закупки технического и/или программного средства требуется внедрить его в существующую инфраструктуру предприятия, не прерывая технологического процесса.

Некоторые функции управления модернизацией выполняют платформы системного/сетевого управления (например, уже упоминавшийся Microsoft System Management Server или CA Unicenter), поддерживающие некоторые функции централизованной установки программного обеспечения, или специализированные пакеты распространения программных средств (Seagate SoftwareInstall и ему подобные). Недостатком всех этих продуктов является то, что они работают только с ПО, не решая при этом никаких оптимизационных задач.

Для адекватного подхода к управлению модернизацией требуется наличие модели, представляющей текущее состояние технических и программных средств и позволяющей анализировать последствия того или иного изменения этого состояния. Практически единственным подходом в этом случае остается, опять-таки, использование экспертных систем.

Моделирование сетей
Моделирование сетей обычно используется для обоснования принимаемых решений по их модернизации, но иногда может являться вполне самостоятельной задачей.

Модель сети должна обеспечивать:

визуализацию топологии сети и распределения нагрузок по отдельным сегментам;
возможность варьирования нагрузок в соответствии с требованиями пользователя, которые определяются спектром решаемых задач;
отображение работы сети с заданными нагрузками и получение количественных характеристик (длины очередей в буферах, задержки при передаче данных, использование полосы пропускания линий связи и т.п.);
формирование вариантов модификации как топологии сети, так и устройств, ее составляющих.
Как видно, для анализа работы сети требуется информация, которую можно получать из систем сетевого управления. Результаты моделирования, в свою очередь, используются при принятии решений по модернизации сетей.

В настоящее время на рынке, насколько нам известно, не существует ни одного универсального продукта, пригодного для полномасштабного моделирования работы сети. Это связано с тем, что точное количественное моделирование сколько-нибудь сложной сети (более 100 узлов) требует огромных вычислительных затрат и при современном состоянии вычислительной техники чрезвычайно трудоемко.

Альтернативой точному количественному моделированию сетей может служить имитационное моделирование, позволяющее отслеживать тенденции и выявлять проблемы, связанные с пропускной способностью сегментов сети. Для решения данной задачи средствами имитационного моделирования можно применять и такие средства, как GPSS, но целесообразнее это делать с помощью экспертных систем реального времени, которые зачастую имеют свой собственный планировщик событий и подсистему моделирования.

Использование экспертных систем для решения задачи моделирования позволяет получать обобщенные оценки параметров сети и вариантов ее модернизации; детальное же описание в экспертных системах общего назначения сетевых устройств и протоколов, которые они используют, требует очень больших трудозатрат. Далее можно применить один из специализированных продуктов сетевого моделирования, обеспечивающий поддержку множества реальных сетевых устройств, каналов связи и протоколов взаимодействия. К таким продуктам относятся:

семейство продуктов Comnet фирмы CACI Products Company;
OPNET от MIL3;
SimuNet от Telenix и другие.
Используя эти продукты, можно выработать точный план модернизации сетевого комплекса с учетом текущих нагрузок на сеть и перспектив ее развития.

Предлагаемое решение
Итак, рассмотрев основные задачи сетевого/системного управления, можно сделать вывод, что универсального решения всего комплекса указанных задач не существует. Однако приемлемое решение создать можно. В качестве такого решения предлагается система, состоящая из следующих компонентов:

ядро системы — экспертная система реального времени;
платформа сетевого управления — HP OpenView или IBM NetView;
подсистема моделирования — Comnet III;
СУБД — Oracle или Informix.
При этом экспертная система (ЭС) является центральным звеном интегрированной среды управления. Она использует информацию из платформы сетевого управления и, в свою очередь, хранит свои данные и результаты работы во внешних СУБД типа Informix или Oracle. Кроме того, ЭС обеспечивает двухсторонний интерфейс с подсистемой точного моделирования сети. В такой конфигурации ЭС выполняет функции мониторинга текущего состояния технического и программного обеспечения, принятия решений по их модернизации и управления процессом модернизации. И, наконец, ЭС объединяет все эти функции в единой распределенной среде с общим интерфейсом.

Одним из возможных кандидатов на создание такой экспертной системы на сегодняшний день является система G2 фирмы Gensym — оболочка, ориентированная на создание экспертных систем реального времени. Эта система обеспечивает:

средства работы в реальном времени, внутреннее планирование, параллельные рассуждения;
структурированный управляемый посредством меню естественно-языковый интерфейс с автоматической проверкой синтаксиса;
общие правила, уравнения и динамические модели, применимые к классам объектов;
обратный и прямой вывод, сканирование, фокусирование, использование метазнаний;
средства управления доступом с помощью механизма авторизации пользователя и обеспечение желаемого “взгляда” на приложение;
интерфейс оператора, включающий графики, диаграммы, шкалы, кнопки, редактор многослойных пиктограмм;
взаимодействие с приложениями по сетевым протоколам TCP/IP и DECnet;
интерфейсы с источниками данных, обеспечивающие эффективную связь с внешними системами, в том числе с СУБД;
многоплатформность и переносимость создаваемых приложений.
Кроме того, в настоящее время существует несколько проблемно-ориентированных средств — надстроек над G2, предназначенных для выполнения специфических операций. К ним относятся:

Fault Expert — средство для разработки интеллектуального ПО сетевого управления, интегрируемого с традиционными платформами, значительно расширяющее их функциональность;
ReThink — средство имитационного моделирования сложных систем;
Neuro-On-Line — средство создания и расчета нейронных сетей, применимых для решения задач, которые практически невозможно решить другими средствами. В частности, нейронные сети можно применять к задаче управления безопасностью, обучив сеть на типичных моделях поведения пользователей различных категорий. После обучения нейронная сеть сможет эффективно распознавать отклонения в поведении и автоматически сигнализировать об этом.
При написании статьи использованы материалы компании “Аргуссофт”, имеющей опыт создания интегрированных систем сетевого управления для крупных организаций.
 
ну допустим статья мне не понравилась слишком много умных слов если ее начнет читать чайник он ниче не поймет :bang: а так сносно более менее доступно... и про соединение кабелем ведомый ведуший.. это для чайников уже слишком...
 
Если кому-то вдруг какие-то термины станут не понятными, я выложил словарь, который также лежит в этом разделе. Так что качайте и читайте.
 
Блин, я уж думал это тема новая - Локальный сети на основе коммуникаторов
а это опечатка всего лишь
там должно быть - Локальные сети на основе коммутаторов
 
Темы объединил, флейм&оффтоп почистил. Больше не сорите здесь.
 
Бродил по просторам интернета, наткнулся на статью Sticty по быстрому поднятию SSL на Apache. Всем админам и не только посвящается=)))

Автор: Stricty
E-mail: me [at] strict [dot] spb [dot] ru
URL: http://strict.spb.ru/


Эта небольшая практическая заметка о том, как быстро создать сертификаты для установки связи по SSL c помощью OpenSSL и быстро настроить веб-сервер Apache+mod_ssl под FreeBSD для установки защищенного соединения.

Введение

Пытаясь настроить кодированное соединение по https-протоколу, чтобы просто не гонять пароли открытым текстом, столкнулась с проблемой — развитие документации, проработка удобства, и чарующая простота не являются свойствами этой технологии. Хотя, вроде все просто — есть дерево подписей и подписанный сертификат (грубо говоря — визитка сервера, с которым происходит соединение). Вы смотрите дерево подписей и сами думаете, доверяете вы этим подписям или нет. Или же у вас есть копия сертификата и вы сравниваете. В конце концов (и это требуется чаще всего) вам хочется не очень светиться эксклюзивными данными и вам все равно, какие там визитки. Эту простую задачу превратили в монстроидальный набор крючочков и ручечек. Мне понадобилась неделя чтобы, используя иногда по 3 статьи на разных языках одновременно, дойти до решения вопроса (у меня была задача номер три из моего списка :)

Задача

Создать конфигурацию виртуального сервера с возможностью подключения по HTTPS-протоколу для более менее безопасной передачи эксклюзиных данных (трафик будет шифроваться). Вопрос начального обмена ключами, который может повлиять на безопасность соединения я оставлю для самостоятельного изучения, как проблему выходящую за рамки этой статьи.

Используемые инструменты


FreeBSD-4.7
OpenSSL 0.9.6g
Apache/1.3.26 + mod_perl/1.27


Настройка конфигурации OpenSSL

В файлике /etc/ssl/openssl.cnf надо проделать следующие изменения:

[ CA_default ]

dir = . # Это каталог для работы с ssl
certs = $dir/ssl.crt # Это где будут лежать сертификаты
crl_dir = $dir/ssl.crl # Это где будут листы "отзывов подписей"
database = $dir/index.txt # Здесь index file для индексирования запросов на подпись
new_certs_dir = $dir/ssl.crt # Сюда будут писать новые сертификаты

certificate = $dir/nemesida-ca.pem # Корневой сертификат
serial = $dir/serial # Серийный номер запроса
crl = $dir/ssl.crl/nemesida.pem # Текущий лист отзывов подписей
private_key = $dir/ssl.key/nemesida-ca.key# Секретный ключ для основного сертификата
RANDFILE = $dir/ssl.key/.rand #

Я так и не нашла, как обойти эти вещи заданием ключей, так что придется править конфиг.

Создаем «корневой» сертификат

Для удобства, перейдем в каталог с конфигурацией Apache, где у меня располагаются подкаталоги с искомыми сертификатами:
# cd /usr/local/etc/apache

Корневой сертификат является корнем дерева подписей и является, как бы, самой ГЛАВНОЙ подписью. Секретный ключ (он нужен для того, чтобы можно было воспользоваться вашим корневым сертификатом для подписи остальных) и сертификат создаются одной командой:
# openssl req -config /etc/ssl/openssl.cnf -new -x509 -keyout ssl.key/nemesida-ca.pem -out nemesida-ca.pem -days 3650

Вас спросят пароль — введите и запомните его. Все остальные поля заполняйте так, как вам подскажет сердце. Снимите пароль с ключа:
# openssl rsa -in ssl.key/nemesida-ca.pem -out nemesida-ca.key

Если вы не сможете спасти этот ключ от посягательств, то и пароль вам не поможет.
Что делает эта строка, я затрудняюсь ответить точно, но так сделать рекомендуют:
# openssl x509 -in nemesida-ca.pem -out nemesida-ca.crt

Вот и все — главная подпись, т.е. корневой сертификат, у вас есть. Он подписан сам собой.

Подготавливаем площадку

Следующие действия, которые надо не забыть совершить, вызывают у меня бурный восторг. Следует создать два файла с некоторой индексной информацией, создать которые openssl не может, равно как и выдать разумное сообщение по этому поводу. Создадим индексный файл (ключевое слово database из openssl.cnf):
# touch index.txt

Создадим файл серийных номеров (ключевое слово serial из openssl.cnf):
# echo '01' > serial

Этот файл должен содержать две цифры (обязательно). Если вы ещё не создавали никаких сертификатов кроме корневого, файл должен содержать 01.

Создаем сертификат сервера

Создание сертификатов сервера состоит из процедуры создания запроса на попись, а затем подписания этого запроса в отличии от создания самоподписанного корневого сертификата. Создаем запрос на подпись нового сертификата и создаем секретный ключ к нему:
# openssl req -config /etc/ssl/openssl.cnf -new -keyout ssl.key/nemesida.pem -out ssl.csr/nemesida.pem

Вводя даные, учтите, что поле Common Name должно содержать полностью определенное доменное имя (FQDN) того сайта, где вы будете использовать https-протокол, чтобы броузеры не выдавали предупреждения о неверности имени. Снимите пароль с ключа:
# openssl rsa -in ssl.key/nemesida.pem -out nemesida.key

Подпишите запрос (подписка запроса и есть создание нового сертификата) своим корневым сертификатом:
# openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything -out ssl.crt/nemesida.pem -infiles ssl.csr/nemesida.pem

Подготовьте сертификат к использованию:
# openssl x509 -in ssl.crt/nemesida.pem -out ssl.crt/nemesida.crt

Списки запросов

Создайте на всякий случай список запросов (там будут храниться и данные по отзывам подписей, если вам это когда-либо понадобится):
# openssl ca -gencrl -out ssl.crl/nemesida.pem

Настройка Apache

В файле httpd.conf (сами найдите ваш файл конфигурации) прописываем:

NameVirtualHost *:443

DocumentRoot "/home/nemesida/www"
ServerName nemesida.ru
ScriptAlias /cgi-bin/ /home/nemesida/cgi-bin/
SSLEngine on
SSLCertificateFile /usr/local/etc/apache/ssl.rt/nemesida.crt
SSLCertificateKeyFile /usr/local/etc/apache/ssl.key/nemesida.key
SSLCACertificateFile /usr/local/etc/apache/nemesida-ca.crt
SSLCARevocationFile /usr/local/etc/apache/ssl.crl/nemesida.crl

SSLOptions +StdEnvVars


SSLOptions +StdEnvVars

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

Вот собственно и все. Запускаете Apache и проверяете.

Замечания


Пока вы не разберетесь в работе SSL, нельзя считать соединение безопасным. В данном случае представлен быстрый вариант настройки, не дающий никаких гарантий. Практически — это защита от дурака, которой тоже пренебрегать не следует.
Берегите секретные ключи — иначе вся эта мышиная возня не имеет смысла.
* Поддержка виртуальных хостов «name based» возможна не в полном варианте — сертификат вы не сможете сделать различными для разных «name based» виртуальных хостов. Это связано с тем, что сначала устанавливается SSL-туннель, а затем по нему идет обмен данными, что определяет выбор сертификатов до получения HTTP-запроса.
 
Вообще люди читайте Таненбаума...
 
нашел интересную вещь
Некоторые секреты IP-протокола


Пожалуй, в последние годы ни о чем так много не писали в области сетевых технологий, как о протоколе IP. Однако, несмотря на такое внимание к данной теме, до сих пор почти ничего не сказано о базовых функциях IP, а именно о том, как маршрутизаторы и коммутаторы третьего уровня работают с IP-информацией и перемещают пакеты данных по сетям.

Напомним, что IP относится к группе протоколов TCP/IP. Протокол TCP реализует транспортные функции модели OSI (Open Systems Interconnection), ее четвертого уровня. Его основная обязанность - обеспечение надежной связи между начальной и конечной точками пересылки данных. IP располагается в OSI на сетевом, или третьем, уровне; он должен поддерживать передачу маршрутизаторам адресов отправителя и получателя каждого пакета на всем пути его следования. Маршрутизаторы и коммутаторы третьего уровня считывают записанную в пакетах по правилам IP и других протоколов третьего уровня информацию и используют ее совместно с таблицами маршрутизации и некоторыми другими интеллектуальными средствами поддержки работы сети, пересылая данные по сетям TCP/IP любого масштаба - от "комнатной" до глобальной, охватывающей всю планету.

Процесс маршрутизации начинается с определения IP-адреса, уникального для станции-отправителя (адреса источника), который может быть постоянным или динамическим. Каждый пакет содержит такой адрес, длина которого, в соответствии с современной спецификацией IPv4, составляет 32 бита.

Кроме того, в заголовке пакета записан IP-адрес его места назначения. Если отправляющая станция определяет, что адрес доставки не локальный, пакет направляется маршрутизатору первого сетевого сегмента. Этот маршрутизатор определяет IP-адрес пакета и проверяет по своей таблице, не расположена ли станция получателя в локальной физически подключенной к нему сети, которая называется IP-подсетью (обычно она назначается для всех сетевых интерфейсов маршрутизатора). Если же выясняется, что IP-адрес получателя локальный, маршрутизатор начинает искать внутреннее хранилище IP- и MAC-адресов локальных устройств - ARP-кэш (Adress Resolution Protocol), позволяющий сопоставлять IP- и MAC-адреса.

При обнаружении нужного MAC-адреса маршрутизатор помещает его в заголовок пакета (удаляя собственный MAC-адрес, который больше не нужен) и направляет пакет по месту назначения. Если MAC-адрес получателя не найден в ARP-кэше, маршрутизатор пересылает ARP-запрос в подсеть, соответствующую IP-адресу получателя пакета, где конечная станция с этим IP-адресом передает ответ на запрос, содержащий необходимый MAC-адрес. Затем маршрутизатор обновляет содержимое кэша, устанавливает новый MAC-адрес в заголовке пакета и отправляет его. Если пакет не предназначен для локальной подсети, маршрутизатор направляет его на маршрутизатор следующего сегмента по MAC-адресу последнего.

Процесс построения и обновления таблиц маршрутизации практически непрерывен. Он осуществляется средствами, использующими интеллектуальные протоколы обнаружения, например RIP или OSPF. В таблице каждого маршрутизатора указан оптимальный маршрут до адреса назначения или до маршрутизатора следующего сегмента (если адрес не принадлежит локальной подсети). Последовательно просматривая собственные таблицы маршрутизации, соответствующие устройства передают пакет "по этапу", запрашивая, при необходимости, MAC-адрес конечной станции. Этот процесс продолжается до тех пор, пока пакет не доберется до пункта назначения.

Однако при пересылке пакета через множество сетевых сегментов существует опасность образования "петель": неправильно сконфигурированный маршрутизатор постоянно возвращает пакет тому маршрутизатору, через который данный пакет уже проходил. Во избежание этого в IP предусмотрена TTL-функция (time-to-live), позволяющая задать предел времени путешествия пакета по сети. Значение TTL устанавливается заранее и уменьшается на единицу при каждом прохождении любого сегмента. Если величина TTL становится равной нулю, пакет удаляется, а маршрутизатор отсылает отправителю сообщение ICMP.
 
нашел интересную вещь
Некоторые секреты IP-протокола
А где секреты??? Это просто краткое изложение малой части rfc по протоколу ip на русском. Советую читать rfc. Есть вроде бы перевод на русский язык...
 
Оптоволоконные сети (может кто не знает че это пригодиться надеюсь)

Оптоволоконные сети, безусловно, являются одним из самых перспективных направлений в области связи. Пропускные способности оптических каналов на порядки выше, чем у информационных линий на основе медного кабеля. Кроме того, оптоволокно невосприимчиво к электромагнитным полям, что снимает некоторые типичные проблемы медных систем связи, такие как грозы и электрические наводки.
Оптические сети способны передавать сигнал на большие расстояния с меньшими потерями. Несмотря на то, что эта технология все еще остается дорогостоящей, цены на оптические компоненты постоянно падают, в то время как возможности медных линий приближаются к своим предельным значениям и требуются все больших затрат на дальнейшее развитие этого направления. В силу дороговизны оптический кабель пока используется для построения внешних магистралей, в пределах здания по прежнему используются медные провода.
В основе оптоволоконных технологий лежит принцип использования света, как основного источника информации. Отправитель преобразовывает информацию в световую волну, а адресат, получая последнюю, в свою очередь интерпретирует свет как информацию.
Свет гораздо проще передать на дальнее расстояние с меньшими потерями, нежели электрический ток. Кроме того, он не подвержен воздействию электромагнитных полей и способен передавать на порядки большее количество информации. С другой стороны оптические технологии во многом являются более тонкими, поэтому качественная реализация оптоволоконного проекта требует детального понимания механизма передачи света и применяемых законов оптики.
Преимущества ВОЛС
Передача информации по ВОЛС имеет целый ряд достоинств перед передачей по медному кабелю. Стремительное внедрение в информационные сети оптических линий связи является следствием преимуществ, вытекающих из особенностей распространения сигнала в оптическом волокне.
Широкая полоса пропускания

- обусловлена чрезвычайно высокой частотой несущей 1014Гц. Это дает потенциальную возможность передачи по одному оптическому волокну потока информации в несколько терабит в секунду. Большая полоса пропускания - это одно из наиболее важных преимуществ оптического волокна над медной или любой другой средой передачи информации.
Высокая помехозащищенность
Поскольку волокно изготовлено из диэлектрического материала, оно невосприимчиво к электромагнитным помехам со стороны окружающих медных кабельных систем и электрического оборудования, способного индуцировать электромагнитное излучение (линии электропередачи, электродвигательные установки и т.д.). В многоволоконных кабелях также не возникает проблемы перекрестного влияния электромагнитного излучения, присущей многопарным медным кабелям.
Высокая защищенность от несанкционированного доступа
Поскольку ВОК практически не излучает в радиодиапазоне, то передаваемую по нему информацию трудно подслушать, не нарушая приема-передачи. Системы мониторинга (непрерывного контроля) целостности оптической линии связи, используя свойства высокой чувствительности волокна, могут мгновенно отключить "взламываемый" канал связи и подать сигнал тревоги.
Сенсорные системы, использующие интерференционные эффекты распространяемых световых сигналов (как по разным волокнам, так и разной поляризации) имеют очень высокую чувствительность к колебаниям, к небольшим перепадам давления. Такие системы особенно необходимы при создании линий связи в правительственных, банковских и некоторых других специальных службах, предъявляющих повышенные требования к защите данных.
Гальваническая развязка элементов сети
Данное преимущество оптического волокна заключается в его изолирующем свойстве. Волокно помогает избежать электрических "земельных" петель, которые могут возникать, когда два сетевых устройства неизолированной вычислительной сети, связанные медным кабелем, имеют заземления в разных точках здания, например на разных этажах. При этом может возникнуть большая разность потенциалов, что способно повредить сетевое оборудование. Для волокна этой проблемы просто нет.
Длительный срок эксплуатации
Со временем волокно испытывает деградацию. Это означает, что затухание в проложенном кабеле постепенно возрастает. Однако, благодаря совершенству современных технологий производства оптических волокон, этот процесс значительно замедлен, и срок службы ВОК составляет примерно 25 лет.
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх