Назад | Перейти на главную страницу

Маршрутизаторы против коммутаторов

Я знаю разницу между маршрутизатором и коммутатором, но в моем понимании есть несколько нечетких пятен.

  1. Когда вы подключаете один коммутатор к другому, они разделяют таблицы MAC-адресов? Или это специфическая функция производителя? Если они не делятся друг с другом, как они обрабатывают пакеты, адресованные Mac, которые они не контролируют напрямую?

  2. Какое наибольшее пространство IP-адресов можно эффективно обрабатывать, используя только коммутируемую сеть, и в какой момент следует рассмотреть возможность разбиения сети на несколько сегментов, соединенных маршрутизатором?

  3. Что более разумно с точки зрения архитектуры: один базовый маршрутизатор, соединяющий множество подсетей с Интернетом, или иерархия маршрутизаторов (по одному на отдел, соединяющийся с ядром)? Или лучше всего дать каждому отделу маршрутизатор, а затем объединить их в мини-интернет?

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

________     1________2      2________1     ________
|Host A|-----|Switch 1|------|Switch 2|-----|Host B|
--------     ----------      ----------     --------

Хост А связан с Переключатель 1, Порт 1. Хост B связан с Переключатель 2, Порт 1. Два переключателя соединены между собой через Порт 2 на обоих.

Предположим, что вначале таблицы подключения обоих коммутаторов пусты. Хост А хочет отправить кадр Хост B. (Чтобы упростить ситуацию, мы предположим, что хост A и хост B имеют статические записи ARP друг для друга, поэтому нет необходимости в ARP для MAC-адресов).

  1. Хост А отправить кадр Хост B. MAC-адрес источника кадра AA: AA: AA: AA: AA: AA, MAC-адрес назначения BB: BB: BB: BB: BB: BB.
  2. Переключатель 1 в настоящее время имеет пустую таблицу мостов. При получении кадра он делает две вещи:
    1. Он создает новую запись в своей таблице мостов, которая AA: AA: AA: AA: AA: AA существует на Порт 1.
    2. Как не знает где BB: BB: BB: BB: BB: BB есть, он заливает фрейм в каждый порт Кроме тот, из которого изначально было слышно (Порт 1).
  3. Коммутатор 2 получает залитый фрейм на своем Порт 2. Опять же, поскольку его таблица мостов изначально пуста, он следует тому же процессу:
    1. Новая запись: AA: AA: AA: AA: AA: AA существует на Порт 2 (напомним, что это на коммутаторе 2, у которого есть независимая таблица мостов от коммутатора 1)
    2. Кадр рассылается из всех портов, кроме того, на котором он был получен.

С этой точки зрения, Хост B получает кадр. когда Хост B отправляет ответ, происходит следующее.

  1. Хост B отправить кадр Хост А. MAC-адрес источника кадра BB: BB: BB: BB: BB: BB, MAC-адрес назначения AA: AA: AA: AA: AA: AA.
  2. Коммутатор 2 в настоящее время имеет одну запись в своей таблице моста (AA: AA: AA: AA: AA: AA -> Порт 2). При получении кадра он делает две вещи:
    1. Он создает запись в своей таблице мостов, которая BB: BB: BB: BB: BB: BB существует вне порт 1.
    2. Поскольку у него есть конкретная запись в таблице мостов для MAC-адреса назначения (AA: AA: AA: AA: AA: AA), он выдвигает кадр из порт 2 только, а не флуд, как раньше.
  3. Коммутатор 1 получает переадресованный кадр на свой порт 2. Опять же, он следует тому же процессу:
    1. Новая запись: BB: BB: BB: BB: BB: BB существует вне порт 2
    2. Есть конкретная запись в таблице мостов (AA: AA: AA: AA: AA: AA -> порт 1), поэтому кадр пересылается только из этого порта.

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

Относительно вашего второго и третьего вопросов:

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

3) Это во многом зависит от масштаба вашей сети и от того, какой объем интрасети по сравнению с интернет-трафиком вы ожидаете увидеть. Если между отделами будет много сообщений, возможно, имеет смысл создать иерархию маршрутизаторов, чтобы чистый внутренний трафик не влиял на доступ в Интернет для всех остальных. Если, с другой стороны, вы ожидаете, что каждый будет иметь доступ только к общему набору служб (AD, электронная почта) и Интернет, тогда может быть достаточно одноядерного маршрутизатора (или пары для резервирования).

С точки зрения предоставления каждому отделу маршрутизатора и объединения их в сеть, как следует администрировать эту сеть? Если будет один административный ИТ-орган, просто создайте иерархическую сеть; наличие пользователей, обслуживаемых общими маршрутизаторами, не будет проблемой. Если каждый отдел собирается содержать свой собственный ИТ-персонал, тогда может потребоваться маршрутизатор для каждого отдела и внутренний пиринг, но это, скорее всего, усложнит структуру вашей сети.

Постараюсь максимально четко ответить на все ваши вопросы.

  1. Насколько я знаю, совместного использования таблиц адресов Mac нет, потому что в этом нет необходимости. Коммутатор будет следить за сетевой активностью, исходящей от другого коммутатора, и записывать записи в свою таблицу Mac-адресов. Он также будет следить за запросами ARP. Заполнение таблицы MAC-адресов займет совсем немного времени.

Отвечая на вопрос о компьютерах Mac, которые они не контролируют напрямую, я думаю, вы имеете в виду компьютеры Mac, которые напрямую не подключены к своим портам. Что ж, возьмем, к примеру, ПК A на моем коммутаторе и ПК B на вашем коммутаторе. Оба коммутатора подключены через стандартный восходящий канал. Когда я прихожу и подключаю свой коммутатор, ваши компьютеры и коммутатор оказываются одни в сетевом мире. ПК на моем коммутаторе будет нуждаться в MAC-адресе вашего ПК, и для этого ему нужно будет отправить широковещательное сообщение ARP (широковещательное сообщение уровня 2, но одноадресное сообщение уровня 3, поскольку оно имеет IP-адрес вашего компьютера). Мой коммутатор будет транслировать его на каждый из своих портов. Затем приходит на ваш коммутатор, кто будет делать то же самое. Тогда ваш компьютер ответит на мой компьютер, и они оба будут знать MAC-адреса друг друга. В процессе оба коммутатора запишут неизвестные им MAC-адреса.

  1. Помните, что сети только с коммутатором работают на уровне 2, поэтому они (теоретически) не зависят от уровня 3. Скажем так, выход за пределы / 8 (255.0.0.0) не очень разумен и приведет к выходу из частного IP-пространства.

  2. Я бы определенно назвал иерархию маршрутизаторов, потому что она позволяет вам иметь более четкую конфигурацию и применять политики для каждого отдела. Cisco согласна со мной в CCNA :-)

Ваш вопрос длинный, я собираюсь обратиться к этой части.

Что более разумно с точки зрения архитектуры: один базовый маршрутизатор, соединяющий множество подсетей с Интернетом, или иерархия маршрутизаторов (по одному на отдел, соединяющийся с ядром)? Или лучше всего дать каждому отделу маршрутизатор, а затем объединить их в мини-интернет?

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

Какое наибольшее пространство IP-адресов можно эффективно обрабатывать, используя только коммутируемую сеть, и в какой момент следует рассмотреть возможность разбиения сети на несколько сегментов, соединенных маршрутизатором?

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

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


Цитата за ограничение на 1024 устройства.

Ethernet: полное руководство 3.6 Домен коллизий (ссылка на книги Google)

В данном Ethernet, состоящем из нескольких сегментов, связанных с повторителями, все станции участвуют в одном домене коллизий. Алгоритм коллизии ограничен 1024 различными временами отсрочки передачи. Следовательно, максимальное количество станций, разрешенное стандартом для многосегментной локальной сети, связанной с повторителями, составляет 1024. Однако это не ограничивает ваш сайт 1024 станциями, поскольку Ethernet-сети могут быть подключены вместе с устройствами коммутации пакетов, такими как коммутаторы. или роутеры.

Когда вы подключаете один коммутатор к другому, они разделяют таблицы MAC-адресов? Или это специфическая функция производителя? Если они не делятся друг с другом, как они обрабатывают пакеты, адресованные Mac, которые они не контролируют напрямую?

Обычно стеки разделяют таблицу между участниками (например, «Виртуальное шасси Juniper»), поскольку они часто имеют избыточные пути, и стандартная таблица не может работать.

В противном случае каждому коммутатору нужна собственная таблица, хотя с помощью таких протоколов, как CDP и LLDP, они могут получить больше информации от своего соседа.

Какое наибольшее пространство IP-адресов можно эффективно обрабатывать, используя только коммутируемую сеть, и в какой момент следует рассмотреть возможность разбиения сети на несколько сегментов, соединенных маршрутизатором?

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

Что более разумно с точки зрения архитектуры: один базовый маршрутизатор, соединяющий множество подсетей с Интернетом, или иерархия маршрутизаторов (по одному на отдел, соединяющийся с ядром)? Или лучше всего дать каждому отделу маршрутизатор, а затем объединить их в мини-интернет?

Оба являются допустимыми представлениями, однако в наши дни коммутаторов уровня 3, работающих под управлением OSPF, я склоняюсь ко второму.