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

По этим причинам наиболее гибким подходом является комбинирование виртуальных сетей на основе стандартов 802.1 Q/p с последующим их отображением на "традиционные сети" в коммутаторах 3-го уровня или маршрутизаторах. Для этого коммутаторы третьего уровня и маршрутизаторы должны понимать метки стандарта 802.1 Q.

Агент ретрансляции DHCP(dhcp-relay) позволяет ретранслировать DHCP и BOOTP запросы из подсети, в которой нет DHCP сервера в другую, или в несколько других подсетей, имеющих DHCP сервера.

Коммутатор может быть сконфигурирован как агент DHCP Relay. В этом случае расширяются возможности применения DHCP-серверов в сети, поскольку уже не нужно использовать несколько DHCP-серверов, по одному в каждой подсети. Коммутатор просто перенаправляет DHCP-запрос от клиента в локальной подсети на удалённый DHCP-сервер.

Option 82 используется для передачи дополнительной информации в DHCP-запросе. Причём эту информацию добавляет сам коммутатор. Эта информация может быть использована для применения политик для увеличения уровня безопасности и эффективности. Для простоты эти пакеты содержат информацию BOOTP, т.е. DHCP-запросы обрабатываются коммутатором также как BOOTP-запросы.

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

Формат поля DHCP option 82 для DES-35XX:

Формат поля опции с Circuit ID - в ней указывается порт коммутатора, за которым находится клиент и VID соответствующего VLAN:

1. Тип опции

2. Длина

3. Тип Circuit ID

4. Длина

5. VLAN: VLAN ID DHCP-запроса клиента

6. Module: Для автономного коммутатора, поле Module всегда 0; для стекируемого коммутатора, Module = Unit ID.

7. Port: Порт коммутатора, с которого получен DHCP-запрос (начинается с 1) port

Формат поля опции с Remote ID - в ней указывается MAC-адрес коммутатора, являющегося агентом DHCP Relay:

1. Тип опции

2. Длина

3. Тип Remote ID type

4. Длина

5. MAC address: MAC-адрес коммутатора.

Пример настройки:

Оборудование:

1. DHCP-сервер 10.51.8.1 в подсети 10.0.0.0/8

2. Маршрутизатор или коммутатор L3, выступающий в роли шлюза для 2-ух подсетей

3. 10.51.8.11 для подсети 10.0.0.0/8

4. 30.51.8.11 для подсети 30.0.0.0/8

5. Коммутатор L2 (DES-3526/DES-3550) в роли агента DHCP Relay

6. 30.51.8.12 в подсети 30.0.0.0/8

7. MAC-адрес: 00-80-C8-35-26-0A

8. 2 ноутбука в качестве DHCP - клиентов, подсоединённые к портам 9 и 10 коммутатора L2 соответственно

Схема сети:

Рисунок 1.13

Задача:

1. DHCP-сервер использует диапазон адресов 30.51.8.100 - 30.51.8.200 для выдачи DHCP-клиенту, запросы которого перенаправляются агентом DHCP Relay 30.51.8.12 (коммутатор L2)
- Обычный режим DHCP

2. Как только какой-либо клиент DHCP подключается к порту 9 коммутатора L2, DHCP-сервер выдаст ему IP-адрес 30.51.8.161; если к порту 10 - то 30.51.8.162. - Функция DHCP option 82

Команды для настройки коммутатора L2 (DES-3526/DES-3550):

1. create iproute default 30.51.8.11

2. config dhcp_relay add ipif System 10.51.8.1

3. config dhcp_relay option_82 state enable

4. enable dhcp_relay

Настройка DHCP-сервера:

В этом примере используется 30-ти дневная версия haneWIN DHCP server 2.1, которую вы можете взять с сайта

1. В пункте Option -> Preferences -> DHCP взведите галочку Accept Relay Agent Information (Option 82)

2. Сконфигурируйте Option -> Default Client Profile -> Basic Profile Relay IP: 30.51.8.12 Dynamic IP Addresses: От 30.51.8.100 до 30.51.8.200 Subnet mask: 255.0.0.0 Gateway Address: 30.51.8.11

3. Сконфигурируйте DHCP option 82

4. a) Задайте IP-адрес 30.51.8.161 для DHCP-клиента A, подключённого к порту 9 коммутатора L2

5. "Add static entries"

6. Взведите галочки "Circuit Identifier" и "Remote Identifier"

7. Hardware Address: 00040001000900060080c835260a

8. IP Address: 30.51.8.161

9. b) Задайте IP-адрес 30.51.8.162 для DHCP-клиента B, подключённого

10. к порту 10 коммутатора L2

11. "Add static entries"

12. Взведите галочки "Circuit Identifier" и "Remote Identifier"

13. Hardware Address: 00040001000a00060080c835260a

14. IP Address: 30.51.8.162

RIP -- так называемый дистанционно-векторный протокол, который оперирует хопами в качестве метрики маршрутизации. Максимальное количество хопов, разрешенное в RIP -- 15 (метрика 16 означает «бесконечно большую метрику»). Каждый RIP-маршрутизатор по умолчанию вещает в сеть свою полную таблицу маршрутизации раз в 30 секунд, генерируя довольно много трафика на низкоскоростных линиях связи. RIP работает на прикладном уровне стека TCP/IP, используя UDP порт 520.

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

OSPF (англ. Open Shortest Path First) -- протокол динамической маршрутизации в сетях IPv4 и IPv6.

OSPF был разработан для больших и развивающихся сетей. Основанный на технологии отслеживания состояния канала (link-state technology), протокол выполняет две основные функции, присущие любому алгоритму маршрутизации:

· Выбор пути

· Коммутация по выбранному пути

Протокол OSPF был разработан IETF в 1988 году. Последняя версия протокола представлена в RFC 2328. Протокол OSPF представляет собой протокол внутреннего шлюза (Interior Gateway Protocol -- IGP).

Протокол OSPF распространяет информацию о доступных маршрутах между маршрутизаторами одной автономной системы.

OSPF предлагает решение следующих задач:

· Увеличение скорости сходимости

· Поддержка сетевых масок переменной длины (VLSM)

· Достижимость сети

· Использование пропускной способности

· Метод выбора пути

Многоадресная рассылка

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

Многоадресная рассылка предполагает отправку сообщений или данных на IP-адрес группы многоадресной рассылки. У этой группы нет физических или географических ограничений: узлы могут находиться в любой точке мира. Узлы, которые заинтересованы в получении данных для определенной группы, должны присоединиться к этой группе (подписаться на рассылку) при помощи протокола IGMP. После этого пакеты многоадресной рассылки IP, содержащие групповой адрес в поле назначения заголовка, будут поступать на этот узел и обрабатываться.

Адресация многоадресной рассылки

Групповые адреса определяют произвольную группу IP-узлов, присоединившихся к этой группе и желающих получать адресованный ей трафик. Назначением групповых адресов управляет IANA (Internet Assigned Numbers Authority, Агентство по выделению имен и уникальных параметров протоколов Интернет). Оно выделило для групповой IP-адресации старые адреса класса D. Это означает, что область многоадресной рассылки охватывает адреса с 224.0.0.0 до 239.255.255.255.

IANA зарезервировало область многоадресной рассылки IP 224.0.0.0-224.0.0.255 для сетевых протоколов сегментов локальных сетей. Пакеты с такими адресами никогда не выходят за пределы локальной сети. Вторая группа адресов в диапазоне 224.0.1.0-224.0.1.255 - это глобальные адреса, которые могут использоваться для многоадресной передачи данных в

Интернет.

Подписка и обслуживание групп

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

Протокол IGMP (Internet Group Management Protocol, межсетевой протокол управления группами) используется для динамической регистрации отдельных узлов в многоадресной группе локальной сети. Узлы сети определяют принадлежность к группе, посылая IGMP сообщения на свой локальный многоадресный маршрутизатор. По протоколу IGMP маршрутизаторы получают IGMP-сообщения и периодически посылают запросы, чтобы определить, какие группы активны или неактивны в данной сети.

Протокол IGMP v1

В версии 1 протокола IGMP существуют два типа IGMP-сообщений:

?? Запрос о принадлежности к группе;

?? Ответ о принадлежности к группе.

Узлы отсылают IGMP-ответы, которые соответствуют u1086 определенной многоадресной группе, чтобы подтвердить свое желание присоединиться к этой группе. Маршрутизатор периодически отправляет IGMP-запрос, чтобы убедиться, что хотя бы один узел в подсети еще

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

Протокол IGMP v2

В версии 2 протокола IGMP существуют четыре типа IGMP-сообщений:

?? Запрос о принадлежности к группе;

?? Ответ о принадлежности к группе по версии 1;

?? Ответ о принадлежности к группе по версии 2;

?? Покинуть группу.

В основном работа IGMP 2 не отличается от IGMP 1. Разница заключается в наличие сообщений о выходе из группы. Теперь узлы сами могут сообщить локальному многоадресному маршрутизатору о намерении покинуть группу. В ответ маршрутизатор отсылает группе специальный запрос, чтобы определить, остались ли в ней еще узлы, желающие получать данный трафик. Если ответа не поступит, маршрутизатор отключает группу и прекращает передачу трафика. Это может значительно сократить задержки, связанные с прекращением членства в группе, по сравнению с IGMP 1. Нежелательный и ненужный трафик может быть прекращен гораздо быстрее.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9