ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Метки статьи: ‘Networks’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Участились вопросы по сабжу.

Случается, что сетевая карта в серваке на FreeBSD ну никак не хочет подниматься и вязаться со свичем. Или случаются ситуации когда на порту свича full-duplex, а на сетевой карте FreeBSD его нет и соответственно работает half-duplex, что приводит к ошибкам и потерям. Для исправления ситуации можно попробовать жестко задать скорость и дуплекс.

Рассмотрим метод ручного задания режимов, что приведет к отключению autoselect режима.

Все выполняется командой ifconfig с использованием опций:

  • media — задает скорость
  • mediaopt — задает дуплекс

Посмотрим состояние сетевой карты em0 ДО изменений:

/sbin/ifconfig em0

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 00:02:a5:4e:92:48
inet 172.16.10.14 netmask 0xffffff00 broadcast 172.16.10.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active

Видим что на карте, по умолчанию, работает autoselect.

Принудительно поставим 100baseTX и full-duplex на сетевой карте с именем em0:

/sbin/ifconfig em0 media 100baseTX mediaopt full-duplex

Посмотрим что получилось:

/sbin/ifconfig em0

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 00:02:a5:4e:92:48
inet 172.16.10.14 netmask 0xffffff00 broadcast 172.16.10.255
media:  Ethernet 100baseTX <full-duplex>
status: active

Видим, что теперь жестко выставлено 100baseTX и full-duplex.

В случае с гигабитными линками команда ессно та же, но скорость другая:

/sbin/ifconfig em0 media 1000baseTX mediaopt full-duplex

Для того, чтобы после ребута выставленная руками скорость и дуплекс оставались, необходимо внести это в /etc/rc.conf:

ifconfig_em0=»inet 172.16.10.14 netmask 255.255.255.0 media 100baseTX mediaopt full-duplex»

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 3, среднее: 5,00 из 5)
Loading...Loading...
Отправить на почту Отправить на почту

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

PPPoE (Point-to-point protocol over Ethernet) — сетевой протокол передачи кадров PPP через Ethernet. Предоставляет дополнительные возможности (аутентификация, сжатие, шифрование).

PPPoE — это туннелирующий протокол (tunneling protocol), который позволяет настраивать (или инкапсулировать) IP, или другие протоколы, которые наслаиваются на PPP, через соединения Ethernet, но с программными возможностями PPP соединений, и поэтому используется для виртуальных «звонков» на соседнюю Ethernet-машину и устанавливает соединение точка-точка, которое используется для транспортировки IP-пакетов, работающее с возможностями PPP.

PPPoE – это метод передачи PPP поверх Ethernet. Пакеты PPP инкапсулируются (включаются) в Ethernet фреймы.

Действующими лицами являются с одной стороны Access Concentrator (AC) – это сервер доступа, а с другой клиент PPPoE. Клиент и сервер должны быть соединены с использованием любых Ethernet устройств (повторители, коммутаторы).

Для именования сервера доступа используется Access Concentrator Name. В свою очередь, Access Concentrator может предоставлять некоторое количество PPPoE сервисов, называемых Service Name.

Парадигма PPPoE включает две стадии: Discovery stage и PPP Session stage.

Клиент, желающий установить PPPoE соединение, сначала должен пройти Discovery stage. При этом между ним и сервером передаются Ethernet фреймы с Ether_type=0x8863.

Наблюдать можно следующим образом:

tcpdump –n –e -i fxp0 ether proto 0x8863

В свою очередь, Discovery stage подразделяется на: initiation, offer, request, and session confirmation.

Сначала клиент должен инициировать PPPoE сессию (initiation). Для этого он посылает специальный пакет Active Discovery Initiation (PADI). Данный пакет посылается на broadcast Ethernet адрес (ff:ff:ff:ff:ff:ff), что логично, так как клиент пока не знает адреса сервера доступа. Опционно пакет может содержать запрашиваемый клиентом Service Name (и только, хотя многие считают, что здесь может быть и Access Concentrator Name).

Пример PADI-пакета:

Frame 1 (44 bytes on wire, 44 bytes captured)
Ethernet II, Src: 00:50:da:42:d7:df, Dst: ff:ff:ff:ff:ff:ff
PPP-over-Ethernet Discovery
  Version: 1
  Type 1
  Code Active Discovery Initiation (PADI)
  Session ID: 0000
  Payload Length: 24
PPPoE Tags
  Tag: Service-Name
  Tag: Host-Uniq
    Binary Data: (16 bytes)

Src. (=source) представляет MAC-адрес машины, пославшей PADI.
Dst. (=destination) является широковещательным Ethernet-адресом.
PADI-пакет может быть получен более чем одним AC.

Сервер доступа отвечает пакетом Active Discovery Offer (PADO), в который включает свое название Access Concentrator Name и название предоставляемого сервиса Service Name. Данный пакет уже юникастовый и содержит мак адрес конкретного сервера.

Вот пример PADO-пакета:

Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0e:40:7b:f3:8a, Dst: 00:50:da:42:d7:df
PPP-over-Ethernet Discovery
  Version: 1
  Type 1
  Code Active Discovery Offer (PADO)
  Session ID: 0000 Payload Length: 36
PPPoE Tags
  Tag: Service-Name
  Tag: AC-Name
    String Data: IpzbrOOl
  Tag: Host-Uniq
    Binary Data: (16 bytes)

AC-Name — String Data представляет строковое AC имя, в данном случае «Ipzbr001»
Src. представляет MAC-адрес AC.

Теперь клиент может выбрать нужное (Service Name и Access Concentrator Name) из возможно нескольких предложений (PADO пакетов) и ответить уже конкретному серверу пакетом Active Discovery Request (PADR).

Согласный на предоставление связи сервер посылает клиенту Active Discovery Session-confirmation (PADS) пакет, включающий уникальный идентификатор сессии (SID), необходимый для дальнейшего взаимодействия. На этом Discovery stage заканчивается и начинается PPP session stage.

PPP session stage начинается с использованием уже обозначенного идентификатора (SID) и Service Name и включает стандартные PPP процедуры: link control, network layer control, authentication. При этом согласуются различные параметры связи и, самое главное, происходит аутентификация.

На данном этапе (и далее, вплоть до отключения) между клиентом и сервером передаются Ethernet фреймы с Ether_type=0x8864.

Наблюдать можно следующим образом:

tcpdump –n –e -i fxp0 ether proto 0x8864

В итоге устанавливается PPPoE соединение и передаются данные.

Для окончания соединения PPPoE клиент (или сервер, что реже) посылает пакет Active Discovery Terminate (PADT).

Типичный обмен пакетами между участниками PPPoE выглядит так (mac сервера s:s:s:s:s:s, mac клиента c:c:c:c:c:c):

подключение клиента:

c:c:c:c:c:c ff:ff:ff:ff:ff:ff 8863 60: PPPoE PADI [Host-Uniq UTF8]
s:s:s:s:s:s c:c:c:c:c:c 8863 49: PPPoE PADO [AC-Name «Provider»] [Service-Name] [Host-Uniq UTF8] [AC-Cookie UTF8]

c:c:c:c:c:c s:s:s:s:s:s 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name » Provider «]

s:s:s:s:s:s c:c:c:c:c:c 8863 49: PPPoE PADS [ses 0x15] [AC-Name » Provider «] [Service-Name] [Host-Uniq UTF8] [AC-Cookie UTF8]

обмен данными

отключение клиента

c:c:c:c:c:c s:s:s:s:s:s 8863 60: PPPoE PADT [ses 0x1a]

Более подробное описание PPPoE содержится в RFC 2516

Ссылки:

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 4,75 из 5)
Loading...Loading...
Отправить на почту Отправить на почту

Многие новички в сетях и FreeBSD сталкиваются с вопросом:

«Как соединить две сети если сервер на FreeBSD имеет физическое подключение к обеим сетям ?»

Схема сети

Схема сети

Иными словами сервер FreeBSD должен выступать в роли router (маршрутизатор).

Итак, что мы имеем:

  • Ethernet сеть
  • Две подсети класса «С» (/24 — маска 255.255.255.0)
  • Сервер FreeBSD с двумя сетевыми картами
  • Клиенты в обеих подсетях

Наша задача, чтобы клиенты из подсети 192.168.1.0/24 могли обмениваться трафиком с клиентами из подсети 192.168.0.0/24.

Сначала настроим сервер FreeBSD и заставим его передавать (маршрутизировать) пакеты из одной подсети в другую.

За это отвечает параметр net.inet.ip.forwarding, посмотрим в какое значение он имеет:

[root@freebsd ~]# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0

На данный момент его значение «0», а это значит, что сервер FreeBSD не будет выполнять маршрутизации.

Включим эту функцию:

[root@freebsd ~]# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1

Так мы изменили значение с «0» на «1». Теперь нужно сделать, так чтобы после ребута это значение всегда было 1-цой. Это можно сделать 2-мя способами:

  1. в файл /etc/rc.conf добавить строчку: gateway_enable=»YES»
  2. в файл /etc/sysctl.conf добавить строчку: net.inet.ip.forwarding=1

На сервере у нас есть две сетевые карты и соответственно два интерфейса: em0 и em1.

Пусть em0 «смотрит» в сеть слева, а em1 в сеть справа. Назначим IP-адреса для интерфейсов FreeBSD сервера:

[root@freebsd ~]# ifconfig em0 add 192.168.1.1/24
[root@freebsd ~]# ifconfig em1 add 192.168.0.1/24


Примечание:

Если на команду ifconfig вы получаете ответ:
command not found
воспользуйтесь командой

[root@virus ~]# whereis ifconfig
ifconfig: /sbin/ifconfig /usr/share/man/man8/ifconfig.8.gz /usr/src/sbin/ifconfig
которая укажет где именно располагается утилита ifconfig
как видно из результата выполнения команды whereis утилита ifconfig находится /sbin/ifconfig
вводите полный путь до утилиты ifconfig, тогда надпись command not found появляться не будет и команда будет выполняться


Посмотрим что получилось:

[root@freebsd ~]# ifconfig -a

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
           ether 00:02:a5:4e:92:48
           inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
           media: Ethernet autoselect (100baseTX <full-duplex>)
           status: active
em1: flags=8802<UP,BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
           ether 00:02:a5:4e:92:49
           inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
           media: Ethernet autoselect (100baseTX <full-duplex>)
           status: active

Рассмотрим что все это значит :

em0 и em1 — имена сетевых интерфейсов
флаг UP — означает что сетевая карта включена, если этого флага не будет, то пакеты не будут приниматься на этом интерфейсе (для включения воспользуйтесь командой: ifconfig ИМЯ_ИНТЕРФЕЙСА up)
ether — это mac-адрес этой сетевой карты
inet — назначенный IP-адрес для этого интерфейса и broadcast адрес для этой подсети
media — информация о скорости и дуплексе интерфейса
status — текущий статус интерфейса. Если status: no carrier, то это означает, что на сетевой карте нет линка.

Сохраним настройки, чтобы IP-адреса назначались интерфейсам после ребута сервера, для этого необходимо добавить в файл /etc/rc.conf следующие строчки:

ifconfig_em0=»inet 192.168.1.1 netmask 255.255.255.0″
ifconfig_em1=»inet 192.168.0.1 netmask 255.255.255.0″

Если на сервере вы используете firewall, например ipfw, то добавим правила разрешающие проход пакетов из одной сети в другую:

ipfw add 100 allow ip from 192.168.1.1/24 to 192.168.0.1/24
ipfw add 110 allow ip from 192.168.1.0/24 to 192.168.1.1/24

Теперь настройте клиентские компьютеры:

  • Выставить IP-адрес из нужной подсети: 192.168.1.ХХХ или 192.168.0.ХХХ
  • Выставить маску подсети 255.255.255.0
  • Выставить шлюз по умолчанию: для подсети 192.168.1.ХХХ это 192.168.1.1, а для подсети 192.168.0.ХХХ это 192.168.0.1 (именно эти IP-адреса на интерфейсах нашего FreeBSD сервера)

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

  • 192.168.1.11
  • 192.168.0.15

Воспользуемся утилитой ping на сервере:

[root@freebsd ~]# ping 192.168.1.11

Если результат будет таким:

PING 192.168.1.11 (192.168.1.11): 56 data bytes
64 bytes from 192.168.1.11: icmp_seq=0 ttl=64 time=0.466 ms
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=0.238 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=0.272 ms
^C
— 192.168.1.11 ping statistics —
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.238/0.325/0.466/0.100 ms

Значит все хорошо и связь между сервером и клиентом есть. Проделайте тоже самое с 192.168.0.15.

Если результат ping отрицательный, то убедитесь что на клиентском компьютере правильно выставлен IP-адрес и маска подсети, а так же наличие линка на сетевой карте.

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

Так же воспользуемся утилитой ping, но уже на компьютере с IP-адресом 192.168.1.11:

ping 192.168.0.15

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

Если ответа нет, то воспользуемся утилитой tracert (для Windows) или traceroute (для FreeBSD):

tracert 192.168.0.15

Если сразу «идут звездочки»:

1 * * *

То проверьте правильность выставление шлюза по умолчанию.

Если трасса выглядит так:

1 192.168.1.1 (192.168.1.1) 0.421 ms 0.447 ms 0.485 ms
2 * * *

То пакет доходит до сервера, убедитесь что firewall сервера не блокирует пакеты и что клиентский компьютер с IP-адресом 192.168.0.15 правильно настроен и «видит» сервер (проверьте IP-адрес, маску подсети, шлюз по умолчанию и наличие ping до сервера)

Вы все проверили, но по прежнему ничего не работает ? Воспользуемся утилитой tcpdump на сервере, которая покажет пакеты проходящие через интерфейсы сервера:

[root@freebsd ~]# tcpdump -ni em0
и
[root@freebsd ~]# tcpdump -ni em1

Запустите пинг с одного клиентского компьютера из одной подсети на другой клиентский компьютер в другой подсети (как мы делали в примерах выше) и смотрите в вывод команды tcpdump на сервере, который будет примерно таким:

[root@freebsd ~]# tcpdump -ni em0

12:17:23.398376 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 49222, seq 0, length 64
12:17:24.399906 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 49222, seq 1, length 64

Т.е. компьютер 192.168.1.11 посылает пакет ICMP echo request до компьютера 192.168.0.15, но ответов мы не видим. Посмотри передает ли сервер эти пакеты на другую сетевую карту:

[root@freebsd ~]# tcpdump -ni em1

12:21:18.167017 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 50246, seq 4, length 64
12:21:19.168022 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 50246, seq 5, length 64

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

Когда все работает вывод будет таким:

12:21:17.165998 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 50246, seq 3, length 64
12:21:17.171199 IP 192.168.0.15 > 192.168.1.11: ICMP echo reply, id 50246, seq 3, length 64
12:21:18.167017 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 50246, seq 4, length 64
12:21:18.171353 IP 192.168.0.15 > 192.168.1.11: ICMP echo reply, id 50246, seq 4, length 64

Мы видим стандартый вывод «запрос-ответ», когда на пакет ICMP echo request приходит ответ в виде пакета ICMP echo reply

Ссылки:

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 7, среднее: 4,43 из 5)
Loading...Loading...
Отправить на почту Отправить на почту

У Вас может возникнуть необходимость поднять vlan и trunk на оборудовании Juniper, например маршутизаторы:

Juniper серии M7i, M10i или серия MX

Как это сделать ?

Первое что мы делаем это переходим в режим конфигурации:

configure

Как вы наверняка заметили, что конфиг Juniper похож на конфиг DNS серверов и состоит из секций.

Перейдем в секцию конфигурации интерфейсов:

edit interfaces

Дадим команду show чтобы посмотреть какие интерфейсы у нас есть:

show

ge-0/0/0 {

}
fxp0 {
      unit 0 {
      }
}
lo0 {
     unit 0 {
         family inet {
             address 127.0.0.1/32;
        }
     }
}

ge-0/0/0 — это наш гигабитный интерфейс на котором мы и будем поднимать vlan
fxp0 — это managment интерфейс (встроенный)
lo0 — это соответственно Loopback интерфейс

Приступим собственно к настройке, возьмем для примера создание 2-х vlan — 5 и 10 на гигабитном интерфейсе ge-0/0/0.

Для того чтобы поднять на интерфейсе ge-0/0/0 vlan`ы нам нужно в «корне» этого интерфейса выставить vlan-tagging, т.е. указать что этот интерфейс будет trunk`ом и будет принимать vlan`ы:

[edit interfaces]
root@juniper#
set ge-0/0/0 vlan-tagging

Следующий шаг это создание sub interface (саб-интерфейсов):

[edit interfaces]
root@juniper#
set ge-0/0/0 unit 5

Тем самым мы создали саб-интерфейс под номером 5-ть. Номера саб-интерфейсов никак не привязаны к номеру vlan. Вы можете задавать любые значения, я (мне так удобней) делаю саб-интерфейсы с номерами vlan, некоторые делаю саб-интерфейсы давая номера по порядку. Тут дело за вами.

Теперь зададим созданному саб-интерфейсу номер vlan:

[edit interfaces]
root@juniper#
set ge-0/0/0 unit 5 vlan-id 5

Выставим ему описание:

[edit interfaces]
root@juniper#
set ge-0/0/0 unit 5 description «My 5 vlan»

Укажем его IP-адрес:

[edit interfaces]
root@juniper#
set ge-0/0/0 unit 5 family inet address 192.168.1.1/24

Посмотрим что у нас получилось:

show

ge-0/0/0 {
   vlan-tagging;
   unit 5 {
       description "My 5 vlan";
       vlan-id 5;
       family inet {
            address 192.168.1.1/24;
       }
}

Теперь по аналогии создадим vlan 10, но немного упростим себе жизнь дабы вводить команду поменьше.

Для этого перейдем в конфигурации чуть глубже, непосредственно в секцию интерфейса ge-0/0/0:

[edit interfaces]
root@juniper#
edit ge-0/0/0

[edit interfaces ge-0/0/0]
root@juniper#

Тем самым нам уже не будет требоваться вводить имя интерфейса при каждой команде, а так же мы введем все сразу одной строкой:

[edit interfaces ge-0/0/0]
root@juniper#
set unit 10 vlan-id 10 description «My 10 vlan» family inet address 192.168.2.1/24

Так мы сразу выполнили все четыре пункта:

  1. создали саб-интерфейс
  2. задали номер влана
  3. задали описание
  4. назначили IP-адрес

Посмотрим что же у нас получилось:

show

ge-0/0/0 {
   vlan-tagging;
   unit 5 {
       description "My 5 vlan";
       vlan-id 5;
       family inet {
            address 192.168.1.1/24;
       }
   unit 10 {
       description "My 10 vlan";
       vlan-id 10;
       family inet {
            address 192.168.2.1/24;
       }
}

Вот и все, теперь интерфейс ge-0/0/0 принимает vlan 5 и 10 и вы можете «подавать» в этот интерфейс trunk в котором прописать эти vlan`ы.

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

[edit interfaces ge-0/0/0]
root@juniper#
commit check

Если в ответ появится configuration check succeeds то все ОК, конфигурация верна. Осталось её закомитить:

[edit interfaces ge-0/0/0]
root@juniper#
commit comment «Set up two sub interfaces on ge-0/0/0»

Конфигурация применится на Juniper и сохранится с указанным комментарием.


Заметка:
Juniper сохраняет до 50-ти конфигураций которые вы commit`ите. Посмотреть можно их список:
root@juniper> show system commit

Если вы находитесь в режиме конфигурирования, то нужно добавлять слово «run»:
[edit]
root@juniper#
run show system commit


Ссылки:

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 9, среднее: 4,44 из 5)
Loading...Loading...
Отправить на почту Отправить на почту

В продолжение статьи Настраиваем vlan на FreeBSD, но теперь немного усложним задачу.

Задача:

Есть два свича Cisco Catalyst 3560 к которым подключены два сегмента сети в разных vlan.

Необходимо, что бы пользователи подключенные к Cisco Catalyst 3560 видели IP-адреса FreeBSD сервера и Cisco Catalyst 3560 свичи находились во vlan`е управления.

Схема

Схема

Данная схема будет работать и на любых других свичах (других моделях Cisco Catalyst (тот же Catalyst 2950 или Catalyst 3550) или например свичах Dlink или Planet), главное чтобы в свиче была поддержка vlan (802.1Q).

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

Switch 01
Создадим vlan`ы:

Switch01#configure terminal
Switch01(config)#vlan 5
Switch01(config-vlan)#name management
Switch01(config-vlan)#vlan 10
Switch01(config-vlan)#name segment_10
Switch01(config-vlan)#vlan 20
Switch01(config-vlan)#name segment_20
Switch01(config-vlan)#exit

Настроим IP-адрес свича во влане управления:

Switch01(config)#int vlan 5
Switch01(config-if)#ip address 10.0.0.2 255.255.255.248
Switch01(config-if)#exit

Поместим пользовательские порты свича в эти vlan`ы:

Switch01(config)#int gi 0/2
Switch01(config-if)#switchport mode access
Switch01(config-if)#switchport access vlan 10
Switch01(config-if)#int gi 0/3
Switch01(config-if)#switchport mode access
Switch01(config-if)#switchport access vlan 20

Настроим trunk на порту смотрящий в сторону Switch02, но разрешим только vlan 5,10 и 20:

Switch01(config-if)#int gi 0/1
Switch01(config-if)#switchport trunk encapsulation dot1q
Switch01(config-if)#switchport trunk allowed vlan 5,10,20
Switch01(config-if)#switchport mode trunk

Будьте внимательны: чтобы в последующем добавлять новые vlan в наш trunk вам необходимо использовать ту же команду, но с ключевым add:

Switch01(config-if)#switchport trunk allowed vlan add VLAN_ID

Если вы не будете использовать add, то свич выставит в разрешенные vlan`ы на trunk порту только те что будут вами перечисленны и удалит старые значения.

Например, команда:

Switch01(config-if)#switchport trunk allowed vlan add 25,30

добавит в trunk vlan`ы 25 и 30 при этом сохранив старые значения 5,10 и 20 и получится, что в данном tunk`е разрешены vlan`ы 5,10,20,25,30

Вернемся к нашей схеме и настроим Switch02.

Switch 02
Создадим vlan`ы:

Switch02#configure terminal
Switch02(config)#vlan 5
Switch02(config-vlan)#name management
Switch02(config-vlan)#vlan 10
Switch02(config-vlan)#name segment_10
Switch02(config-vlan)#vlan 20
Switch02(config-vlan)#name segment_20
Switch02(config-vlan)#exit

Настроим IP-адрес свича во влане управления:

Switch02(config)#int vlan 5
Switch02(config-if)#ip address 10.0.0.3 255.255.255.248
Switch02(config-if)#exit

Поместим пользовательские порты свича в эти vlan`ы:

Switch02(config)#int gi 0/11
Switch02(config-if)#switchport mode access
Switch02(config-if)#switchport access vlan 20
Switch02(config-if)#int gi 0/10
Switch02(config-if)#switchport mode access
Switch02(config-if)#switchport access vlan 10
Switch02(config-if)#exit

Настроим trunk на порту смотрящий в сторону Switch01 и разрешим только vlan 5,10 и 20:

Switch02(config)#int gi 0/2
Switch02(config-if)#switchport trunk encapsulation dot1q
Switch02(config-if)#switchport trunk allowed vlan 5,10,20
Switch02(config-if)#switchport mode trunk
Switch02(config-if)#exit

Также настроим trunk порт смотрящий в сторону FreeBSD:

Switch02(config)#int gi 0/24
Switch02(config-if)#switchport trunk encapsulation dot1q
Switch02(config-if)#switchport trunk allowed vlan 5,10,20
Switch02(config-if)#switchport mode trunk
Switch02(config-if)#exit

Настроим сервер FreeBSD

Создадим vlan управления:

/sbin/ifconfig vlan1 create
/sbin/ifconfig vlan1 vlan 5 vlandev em0
/sbin/ifconfig vlan1 add 10.0.0.1/29
/sbin/ifconfig vlan1 up

Создадим vlan 10:

/sbin/ifconfig vlan2 create
/sbin/ifconfig vlan2 vlan 10 vlandev em0
/sbin/ifconfig vlan2 add 192.168.10.1/24
/sbin/ifconfig vlan2 up

Создадим vlan 20:

/sbin/ifconfig vlan3 create
/sbin/ifconfig vlan3 vlan 20 vlandev em0
/sbin/ifconfig vlan3 add 192.168.20.1/24
/sbin/ifconfig vlan3 up

На этом с настройками покончено, настало время проверки. Если вы все сделали правильно, то:

  1. С FreeBSD сервера во влане управления (vlan 5) вы будете видеть и управлять (например по telnet) cisco catalyst)
  2. Пользователи во вланах 10,20 будут видеть IP интерфейсы сервера FreeBSD. Вы можете использовать этот сервер как шлюз в сеть Интернет для данных пользователей.

Посмотрим на cisco catalyst:

show vlan brief — просмотр существующих vlan`ов на свиче
show ip interface brief — просмотр существующих IP интерфейсов на свиче
show interfaces trunk — просмотр существующих trunk интерфейсов на свиче
show interfaces switchport — просмотр коммутации на интерфейсах свича

На FreeBSD интерфейсы смотрим командой ifconfig

Проверьте наличие пинга (ping) с FreeBSD сервера до пользователей и свичей.

Ссылки:

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 6, среднее: 5,00 из 5)
Loading...Loading...
Отправить на почту Отправить на почту