ARP доходит до PC1, о чем свидетельствует галочка на конверте. Теперь ему известен MAC-адрес и он пускает в ход ICMP.
Открываем пакет на коммутаторе и наблюдаем такую же картину. На канальном уровне кадр тегируется коммутатором. Так будет с каждым сообщением.
Видим, что пакет успешно доходит до PC7. Обратный путь я показывать не буду, так как он аналогичен. Если кому интересно, можно весь путь увидеть на анимации под спойлером ниже. А если охота самому поковырять эту топологию, прикладываю ссылку на лабораторку.
Логика работы VLAN
Вот в принципе самое популярное применение VLAN-ов. Независимо от физического расположения, можно логически объединять узлы в группы, там самым изолируя их от других. Очень удобно, когда сотрудники физически работают в разных местах, но должны быть объединены. И конечно с точки зрения безопасности VLAN не заменимы. Главное, чтобы к сетевым устройствам имели доступ ограниченный круг лиц, но это уже отдельная тема.
Добились ограничения на канальном уровне. Трафик теперь не гуляет где попало, а ходит строго по назначению. Но теперь встает вопрос в том, что отделам между собой нужно общаться. А так как они в разных канальных средах, то в дело вступает маршрутизация. Но перед началом, приведем топологию в порядок. Самое первое к чему приложим руку — это адресация узлов. Повторюсь, что каждый отдел должен находиться в своей подсети. Итого получаем:
Раз подсети определены, то сразу адресуем узлы.
Теперь про изменения в топологии. Видим, что добавился маршрутизатор. Он как раз и будет перекидывать трафик с одного VLAN на другой (иными словами маршрутизировать). Изначально соединения между ним и коммутатором нет, так как интерфейсы выключены.
У узлов добавился такой параметр, как адрес шлюза. Этот адрес они используют, когда надо отправить сообщение узлу, находящемуся в другой подсети. Соответственно у каждой подсети свой шлюз.
Осталось настроить маршрутизатор, и я открываю его CLI. По традиции дам осмысленное имя.
Router(config)#hostname Gateway
Gateway(config)#
Далее переходим к настройке интерфейсов.
Gateway(config)#interface fastEthernet 0/0 - переходим к требуемому интерфейсу.
Gateway(config-if)#no shutdown - включаем его.
%LINK-5-CHANGED: Interface FastEthernet0/0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
Теперь внимание! Мы включили интерфейс, но не повесили на него IP-адрес. Дело в том, что от физического интерфейса (fastethernet 0/0) нужен только линк или канал. Роль шлюзов будут выполнять виртуальные интерфейсы или сабинтерфейсы (англ. subinterface). На данный момент 3 типа VLAN. Значит и сабинтерфейсов будет 3. Приступаем к настройке.
Gateway(config)#interface fastEthernet 0/0.2
Gateway(config-if)#encapsulation dot1Q 2
Gateway(config-if)#ip address 192.168.1.1 255.255.255.0
Gateway(config)#interface fastEthernet 0/0.3
Gateway(config-if)#encapsulation dot1Q 3
Gateway(config-if)#ip address 192.168.2.1 255.255.255.0
Gateway(config)#interface fastEthernet 0/0.4
Gateway(config-if)#encapsulation dot1Q 4
Gateway(config-if)#ip address 192.168.3.1 255.255.255.0
Маршрутизатор настроен. Переходим к центральному коммутатору и настроим на нем транковый порт, чтобы он пропускал тегированные кадры на маршрутизатор.
CentrSW(config)#interface fastEthernet 0/24
CentrSW(config-if)#switchport mode trunk
CentrSW(config-if)#switchport trunk allowed vlan 2,3,4
Конфигурация закончена и переходим к практике. Отправляю ping с PC1 на PC6 (то есть на 192.168.3.3).
PC1 понятия не имеет, кто такой PC6 или 192.168.3.3, но знает, что они находятся в разных подсетях (как он это понимает описано в предыдущей статье). Поэтому он отправит сообщение через основной шлюз, адрес которого указан в его настройках. И хоть PC1 знает IP-адрес основного шлюза, для полного счастья не хватает MAC-адреса. И он пускает в ход ARP.
Обратите внимание. Как только кадр прибывает на CentrSW, коммутатор не рассылает его кому попало. Он рассылает только на те порты, где разрешен пропуск 2-го VLAN. То есть на маршрутизатор и на SW2 (там есть пользователь, сидящий во 2-ом VLAN).
Маршрутизатор узнает себя и отправляет ответ (показан стрелочкой). И обратите внимание на нижний кадр. Когда SW2 получил ARP от центрального коммутатора, он аналогично не стал рассылать его на все компьютеры, а отправил только PC7, который сидит во 2-ом VLAN. Но PC7 его отбрасывает, так как он не для него. Смотрим дальше.
Открываем пакет на коммутаторе и наблюдаем такую же картину. На канальном уровне кадр тегируется коммутатором. Так будет с каждым сообщением.
Видим, что пакет успешно доходит до PC7. Обратный путь я показывать не буду, так как он аналогичен. Если кому интересно, можно весь путь увидеть на анимации под спойлером ниже. А если охота самому поковырять эту топологию, прикладываю ссылку на лабораторку.
Логика работы VLAN
Вот в принципе самое популярное применение VLAN-ов. Независимо от физического расположения, можно логически объединять узлы в группы, там самым изолируя их от других. Очень удобно, когда сотрудники физически работают в разных местах, но должны быть объединены. И конечно с точки зрения безопасности VLAN не заменимы. Главное, чтобы к сетевым устройствам имели доступ ограниченный круг лиц, но это уже отдельная тема.
Добились ограничения на канальном уровне. Трафик теперь не гуляет где попало, а ходит строго по назначению. Но теперь встает вопрос в том, что отделам между собой нужно общаться. А так как они в разных канальных средах, то в дело вступает маршрутизация. Но перед началом, приведем топологию в порядок. Самое первое к чему приложим руку — это адресация узлов. Повторюсь, что каждый отдел должен находиться в своей подсети. Итого получаем:
- Дирекция — 192.168.1.0/24
- Бухгалтерия — 192.168.2.0/24
- Отдел кадров — 192.168.3.0/24
Раз подсети определены, то сразу адресуем узлы.
- PC1:
IP: 192.168.1.2
Маска: 255.255.255.0 или /24
Шлюз: 192.168.1.1 - PC2:
IP: 192.168.1.3
Маска: 255.255.255.0 или /24
Шлюз: 192.168.1.1 - PC3:
IP: 192.168.2.2
Маска: 255.255.255.0 или /24
Шлюз: 192.168.2.1 - PC4:
IP: 192.168.2.3
Маска: 255.255.255.0 или /24
Шлюз: 192.168.2.1 - PC5:
IP: 192.168.3.2
Маска: 255.255.255.0 или /24
Шлюз: 192.168.3.1 - PC6:
IP: 192.168.3.3
Маска: 255.255.255.0 или /24
Шлюз: 192.168.3.1 - PC7:
IP: 192.168.1.4
Маска: 255.255.255.0 или /24
Шлюз: 192.168.1.1
Теперь про изменения в топологии. Видим, что добавился маршрутизатор. Он как раз и будет перекидывать трафик с одного VLAN на другой (иными словами маршрутизировать). Изначально соединения между ним и коммутатором нет, так как интерфейсы выключены.
У узлов добавился такой параметр, как адрес шлюза. Этот адрес они используют, когда надо отправить сообщение узлу, находящемуся в другой подсети. Соответственно у каждой подсети свой шлюз.
Осталось настроить маршрутизатор, и я открываю его CLI. По традиции дам осмысленное имя.
Router(config)#hostname Gateway
Gateway(config)#
Далее переходим к настройке интерфейсов.
Gateway(config)#interface fastEthernet 0/0 - переходим к требуемому интерфейсу.
Gateway(config-if)#no shutdown - включаем его.
%LINK-5-CHANGED: Interface FastEthernet0/0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
Теперь внимание! Мы включили интерфейс, но не повесили на него IP-адрес. Дело в том, что от физического интерфейса (fastethernet 0/0) нужен только линк или канал. Роль шлюзов будут выполнять виртуальные интерфейсы или сабинтерфейсы (англ. subinterface). На данный момент 3 типа VLAN. Значит и сабинтерфейсов будет 3. Приступаем к настройке.
Gateway(config)#interface fastEthernet 0/0.2
Gateway(config-if)#encapsulation dot1Q 2
Gateway(config-if)#ip address 192.168.1.1 255.255.255.0
Gateway(config)#interface fastEthernet 0/0.3
Gateway(config-if)#encapsulation dot1Q 3
Gateway(config-if)#ip address 192.168.2.1 255.255.255.0
Gateway(config)#interface fastEthernet 0/0.4
Gateway(config-if)#encapsulation dot1Q 4
Gateway(config-if)#ip address 192.168.3.1 255.255.255.0
Маршрутизатор настроен. Переходим к центральному коммутатору и настроим на нем транковый порт, чтобы он пропускал тегированные кадры на маршрутизатор.
CentrSW(config)#interface fastEthernet 0/24
CentrSW(config-if)#switchport mode trunk
CentrSW(config-if)#switchport trunk allowed vlan 2,3,4
Конфигурация закончена и переходим к практике. Отправляю ping с PC1 на PC6 (то есть на 192.168.3.3).
PC1 понятия не имеет, кто такой PC6 или 192.168.3.3, но знает, что они находятся в разных подсетях (как он это понимает описано в предыдущей статье). Поэтому он отправит сообщение через основной шлюз, адрес которого указан в его настройках. И хоть PC1 знает IP-адрес основного шлюза, для полного счастья не хватает MAC-адреса. И он пускает в ход ARP.
Обратите внимание. Как только кадр прибывает на CentrSW, коммутатор не рассылает его кому попало. Он рассылает только на те порты, где разрешен пропуск 2-го VLAN. То есть на маршрутизатор и на SW2 (там есть пользователь, сидящий во 2-ом VLAN).
Маршрутизатор узнает себя и отправляет ответ (показан стрелочкой). И обратите внимание на нижний кадр. Когда SW2 получил ARP от центрального коммутатора, он аналогично не стал рассылать его на все компьютеры, а отправил только PC7, который сидит во 2-ом VLAN. Но PC7 его отбрасывает, так как он не для него. Смотрим дальше.