Subnets.ru blog

Juniper: BGP load balancing on 2 links (same ISP)

На одном из маршрутизаторов Juniper появился второй физический линк на того же апстрима, т.к. первый линк уже сильно нагружен. Что по итогу получилось ?

А получилось что мы имеем два линка в одну и ту же ASку (два физических линка и две BGP сессии) и трафик может распределяться по 2 линкам неравномерно.

В своей предыдущей статье «Настройка протокола BGP на оборудовании Juniper» я уже затрагивал тему лоад балансинга, но там load balance применяется ко всем апстримам, а тут у меня появилась немного другая задача, сделать балансинг только на двух этих линках. (уточню, что речь идет ТОЛЬКО про исходящий трафик из моей AS)

Для примера будем считать, что у апстрима номер автономной системы AS100.

Итак начнем, войдем в режим конфигурации:

root@juniper> configure

Как известно, что практический любой вопрос можно решить как минимум двумя способами, подумав, я решил балансить трафик исходя из as-path, поэтому создадим «AS path regular expression «:

[edit]
root@juniper# set policy-options as-path as100 «100.*»

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

Далее создадим полиси (в терминах cisco «маршрутную карту» — route-map):

[edit]
root@juniper# set policy-options policy-statement load-balance-as100 from as-path as100
[edit]
root@juniper# set policy-options policy-statement load-balance-as100 then load-balance per-packet

в которой мы и указали созданный выше as-path как параметр для матча (совпадение as-path в маршруте)

Ну и осталось применить это к таблице маршрутизации — forwarding-table:

[edit]
root@juniper# set routing-options forwarding-table export load-balance-as100

Проверим все ли в порядке:

[edit]
root@juniper# commit check

Если в ответ вы получили сообщение:

configuration check succeeds

значит ошибок в конфигурации нет и вы можете применять её на маршрутизаторе.

Сделаем это и добавим комментарий к этому конфигу:

[edit]
root@juniper# commit comment «Load balance AS100»

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

Разница конечно будет, не ждите 100% одинаковости трафика по каналам, но в общем целом она перестала различаться в разы и составляет 10-20 Мбит/с.

За балансинг входящего к вам трафик уже отвечает ваш апстрим, но для него это же исходящий трафик 😉

Ссылки:

• Configuring the Load-Balance Per-Packet Action
• Defining AS Path Regular Expressions
• Defining Routing Policies
• Настройка протокола BGP на оборудовании Juniper

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

Автор: Николаев Дмитрий (virus (at) subnets.ru)

В продолжении статьи Backup конфига Cisco на FTP, не забудем про Juniper.

Допустим что:

192.168.1.3 — IP-адрес Juniper
192.168.1.254 — IP-адрес backup сервера

Приступим:

Для начала на наш FreeBSD backup сервер нужно установить порт, но не тот, что и в случае с циской:

cd /usr/ports/net/p5-Net-Telnet
make install clean

После того как порт установился напишем небольшой perl скрипт:

#!/usr/bin/perl

use Net::Telnet ();

@c=("192.168.1.3");  #Массив с IP-адресами того что будем бекапить
@cn=("juniper.conf");  #Как будет называться конфиг после бекапа
@login=("backup");      #Логин на оборудование
@pass=("passwd");       #Пароль

$ftp="192.168.1.254";
$ftpuser="juniper-backup";      #Логин к FTP
$ftpass="ftpPasswd";           #Пароль к FTP

$maindir="/backup/juniper";     #Папка доступная по FTP

#Определяем папки в $maindir в формате ГОД/МЕСЯЦ/ДЕНЬ/ЧАС куда будет перемещен конфиг после закачки его на FTP
$dir="$maindir/inet";
$backup_dir=`date +"%Y/%m/%d/%H"`;
chomp($backup_dir);
$backup_dir="$dir/$backup_dir";

#Проверяем наличие директории куда будет складываться backup и
#Создаем директорию если её не существует
opendir(D,$backup_dir) or `/bin/mkdir -p $backup_dir`;
closedir D;

#Цикл по массиву с IP-адресами железок
for ($i=0;$i<=$#c;$i++){
        my $h=sprintf("%s",$c[$i]);
        my $conf=sprintf("%s",$cn[$i]);
        my $user=sprintf("%s",$login[$i]);
        my $pas=sprintf("%s",$pass[$i]);

        #Устанавливаем соединение с железкой и ловим строку приглашения
        #ВНИМАНИЕ !!! Ваша строка приглашения может отличаться !!!
        #Все зависит от имени железки, то которое вы ей задали, и логина с которым вы туда стучитесь
        $ses = new Net::Telnet (Timeout => 10,
                        Prompt => '/backup\\@juniper. $/');

        if ($ses->open($h)) {
                #Если соединение установлено
                $ses->login($user, $pas);
                @lines = $ses->cmd("configure");
                my $bcmd=sprintf("save ftp://%s:%s\@%s/%s",$ftpuser,$ftpass,$ftp,$conf);
                #Отправляем команды на backup
                @lines1 = $ses->cmd($bcmd);

        }else{
                warn "Can't: " . $ses->errmsg;
        }
         $ses->close;
        `/bin/sleep 3`;
        #Перемещаем закаченный на FTP конфиг в backup директорию
        #как итог она будет: /backup/cisco/inet/ГОД/МЕСЯЦ/ДЕНЬ/ЧАС
        system(sprintf("/bin/mv %s/%s %s",$maindir,$conf,$backup_dir));
}

Сохраняем наш скрипт, например как backup-juniper.pl

Делаем его запускаемым:

chmod a+x backup-juniper.pl

Вот и все. Осталось проверить его работу запустив руками, а затем, если все нормально, добавить его в crontab:

0 2 * * * root /backup/juniper/backup-juniper.pl

Что означает, что каждый день в 2:00 будет запускаться наш скрипт который сохранит конфиги Juniper в директории /backup/juniper/inet/ГОД/МЕСЯЦ/ДЕНЬ/ЧАС

Удачного вам бекапа !

Ссылки:

• www.juniper.net
• Backup конфига Cisco на FTP

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

Авторы: Николаев Дмитрий (virus (at) subnets.ru) и Панфилов Алексей (lehis (at) subnets.ru)

Итак, вы в качестве пограничного маршрутизатора своей AS выбрали маршрутизатор Juniper.

Поздравляю вас ! Вы сделали отличный выбор ! 😉

В этой статье я постараюсь рассказать как настроить протокол BGP на оборудовании этого производителя.

Это не how-to на все случаи в жизни, а пример, с которого можно хоть как-то начать постигать замечательное железо от Juniper.

В качестве примера буду использовать:

Наша автономная система: AS100

Наш префикс: 1.1.0.0/20

Схема подключения:

Два апстрима: AS200 (2.2.2.1/30) и AS300 (3.3.3.1/30)

И один прямой пиринг с AS400 (4.4.4.1/30)

Схема подключения

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

Настройка протокола BGP начинается с секции protocols.

Войдем в режим конфигурации:

root@juniper> configure

перейдем в раздел protocols bgp

[edit]
root@juniper# edit protocols bgp

Начнем с того, что укажем номер своей автономной системы:

[edit protocols bgp]
root@juniper# set local-as 100

Зададим логирование изменений состояния «соседей» (peer):

[edit protocols bgp]
root@juniper# set log-updown

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

[edit protocols bgp]
root@juniper# set advertise-inactive

Зададим route flap damping (так называемые «хлопающие» маршруты):

Т.к. это пограничный маршрутизатор, а значит «серые» сети не должны выходить за его пределы, выполним следущее (discard):

[edit routing-options]
root@juniper# set route 10.0.0.0/8 discard

[edit routing-options]
root@juniper# set route 172.16.0.0/12 discard

[edit routing-options]
root@juniper# set route 192.168.0.0/16 discard

Не будем «насиловать» лишними маршрутами своих апстримов и будем им оглашать весь блок /20 целиком. Для этого сделаем агрегирование:

[edit routing-options]
root@juniper# set aggregate route 1.1.0.0/20 discard

Посмотрим что получилось в этой секции:

[edit routing-options]
root@juniper# show

Настало время создать маршрутные карты. Начнем с per-flow-load-balancing.

Перейдем в другую секцию:

[edit routing-options]
root@juniper# top

[edit]
root@juniper# edit policy-options

Создадим для per-flow-load-balancing:

[edit policy-options]
root@juniper# set policy-statement per-flow-load-balancing term balance then load-balance per-packet

Приступим к дефолтным маршрутным картам для соседей.

Для начала bogus-reject:

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 127.0.0.0/8 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 10.0.0.0/8 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 172.16.0.0/12 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 192.168.0.0/16 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 169.254.0.0/16 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 224.0.0.0/4 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 240.0.0.0/4 orlonger

Так мы задали список маршрутов, теперь укажем что мы с ними хотим сделать, в т.ч., и не принимать такие маршруты:

[edit policy-options]
root@juniper# set policy-statement bogus-reject then reject

Создадим default-route-reject для запрета приема default gateway по протоколу BGP:

[edit policy-options]
root@juniper# set policy-statement default-route-reject from route-filter 0.0.0.0/0 exact

[edit policy-options]
root@juniper# set policy-statement default-route-reject then reject

Создадим bogus-ases для запрета приема «серых» (private) номеров AS:

[edit policy-options]
root@juniper# set policy-statement bogus-ases from as-path grey-as

[edit policy-options]
root@juniper# set policy-statement bogus-ases then reject

[edit policy-options]
root@juniper# set policy-statement as-path grey-as 64512-65535

Пришло время для карт для соседей. В маршрутных картах на in (input) вы можете «играться» с теми или иными маршрутами приходящими от соседей. Фильтровать что-то, поднимать local-prefence и т.п. Для примера покажу как поднять local-prefence на маршрутах, для которых ваш апстрим является origin (т.е. те маршруты, которые принадлежат его AS).

Итак Prov-1-in:

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term own-as from as-path prov-1-as

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term own-as then local-preference 200

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term own-as then accept

Теперь создадим as-path:

[edit policy-options]
root@juniper# set as-path prov-1-as «.*200»

Т.к. orign AS для маршрута всегда находится в конце as-path, то я и задал регулярное выражение которое ищет AS200 в конце as-path. Подробнее о регулярных выражениях читайте в технической документации по вашей версии JUNOS. Вы можете использовать не только as-path, но и префиксы которые принадлежат данному апстриму. Это на ваш выбор. Я выбрал as-path потому, что бы каждый раз не лазать и не изменять конфиг когда у этого апстрима появится новый блок IP-адресов.

Теперь зададим последний этап обработки приходящих от этого апстрима маршутов и действий с ними. Т.к. у нас full-view, то логично, что мы разрешим все остальное:

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term final-accept then accept

Тут же вы можете выставить default local-preference для этого апстрима:

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term final-accept then local-preference 100

Проделайте тоже самое и для Prov-2-in подставив туда его значения создав policy-statement Prov-2-in и as-path с AS300.

Для примера для нашего прямого пира AS400 мы создадим маршрутку с его префиксами, а не с as-path:

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term own-prefix from prefix-list-filter peer-1-prefix exact

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term own-prefix then accept

Поднимем local-preference для этих маршрутов выше, чем все остальное:

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term own-prefix then local-preference 210

Теперь запретим все остальное (т.к. как я уже говорил это прямой пир, а не апстрим, а раз так то принимаем только те префиксы, которые ему принадлежат):

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term final-reject then reject

Ну и осталось создать peer-1-prefix который мы прописали выше и указать в нем префиксы, которые принадлежат AS400, допустим это будут префиксы:

• 195.128.0.0/16
• 77.87.224.0/21

[edit policy-options]
root@juniper# set prefix-list peer-1-prefix 195.128.0.0/16

[edit policy-options]
root@juniper# set prefix-list peer-1-prefix 77.87.224.0/21

Итак с приемом маршрутов разобрались, приступим к оглашению наших. Эта задача состоит из двух частей:

• оглашение агрегированного маршрута для апстримов
• оглашение разделенного блока /20 для прямого пира

При прописывании всех наших соседей мы использовали разные маршрутные карты для того, что бы у нас была возможность управлять анонсами для каждого соседа по разному. Это вам пригодится для управления входящим в вашу AS трафиком, например prepend`ом.

Начнем с AS200 (первый апстрим) и как мы условились апстримам мы оглашаем агрегированный маршрут:

[edit policy-options]
root@juniper# set policy-statement Prov-1-out term my-prefix from protocol aggregate

[edit policy-options]
root@juniper# set policy-statement Prov-1-out term my-prefix from policy our-CIDR-blocks-aggregated

[edit policy-options]
root@juniper# set policy-statement Prov-1-out term my-prefix then accept

Создадим сам фильтр policy our-CIDR-blocks-aggregated:

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks-aggregated term AS100-prefix from route-filter 1.1.0.0/20 exact

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks-aggregated term AS100-prefix then accept

Т.к. на данном этапе мы всем апстримам оглашаем одно и тоже, то создайте Prov-2-out сами.

Теперь нужно сделать out для нашего прямого пира и оглашать мы ему будем две сети /21:

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term AS100-prefix from protocol static

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term AS100-prefix from policy our-CIDR-blocks

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term AS100-prefix then accept

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term final-reject then reject

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks term AS100-prefixes from route-filter 1.1.0.0/21 exact

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks term AS100-prefixes from route-filter 1.1.8.0/21 exact

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks term AS100-prefixes then accept

Ну вот вроде на первый взляд и все. Проверим все ли в порядке:

[edit policy-options]
root@juniper# commit check

Если в ответ вы получили сообщение:

configuration check succeeds

значит ошибок в конфигурации нет и вы можете применять её на маршрутизаторе. Сделаем это и добавим комментарий к этому конфигу:

[edit policy-options]
root@juniper# commit comment «My first configuration»

Juniper может хранить до 50-ти «закомиченных» конфигураций и вы всегда можете откатываться к любой их них, поэтому я рекомендую всегда добавлять комментарий к конфигу, чтобы потом различать их 🙂

Посмотреть состояние всех соседей можно командой:

[edit policy-options]
root@juniper# run show bgp summary

Т.к. мы все ещё находимся в режиме конфигурирования нам приходится добавлять ключевое слово run чтобы команда show отработала не на конфигурации.

Если мы выйдем из режима конфигурирования:

[edit policy-options]
root@juniper# exit

то тут слово run добавлять уже не нужно:

root@juniper> show bgp summary

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

Мануал, по всем командам, вы можете прочитать в технической документации по вашей версии Junos на сайте производителя: www.juniper.net

Рекомендую полистать книгу:

Заранее прошу прощения за оЧепЯтки и неточности. По мере нахождения багов и замечаний статья будет изменяться.

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

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Может возникнуть ситуация когда пропускной способности одного гигабитного интерфейса не достаточно.

Решить эту проблему может ещё один интерфейс и агрегирование их в один логический.

В нашем примере мы используем гигабитные интерфейсы.

Juniper

Войдем в режим конфигурации:

root@juniper> configure

перейдем в раздел chassis

[edit]
root@juniper# edit chassis

теперь необходимо задать количество агрегированных интерфейсов:

[edit chassis]
root@juniper# set aggregated-devices ethernet device-count 1

Теперь нам нужно выбрать и настроить наши гигабитные интерфейсы:

[edit chassis]
root@juniper# top

[edit]
root@juniper# edit interfaces

[edit interfaces]
root@juniper# set ge-0/1/0 gigether-options 802.3ad ae0

[edit interfaces]
root@juniper# set ge-1/3/0 gigether-options 802.3ad ae0

теперь можно приступать к настройке агрегированного интерфейса, он имеет имя ae0 и с ним можно делать все тоже самое, что и с обычным интерфейсом, например поднимать вланы:

[edit interfaces]
root@juniper# set ae0 vlan-tagging

[edit interfaces]
root@juniper# set ae0 unit 11 vlan-id 11 family inet address 192.168.1.1/24 preferred

Посмотрим итог:

chassis {
     aggregated-devices {
           ethernet {
                device-count 1;
           }
     }
}
interfaces {
    ge-0/1/0 {
          gigether-options {
              802.3ad ae0;
          }
    }
    ge-1/3/0 {
          gigether-options {
              802.3ad ae0;
          }
    }
    ae0 {
          vlan-tagging;
          unit 11 {
                 vlan-id 11;
                family inet {
                       address 192.168.1.1/24 {
                            preferred;
                      }
                }
          }
    }
}

Cisco

Приступим к настройке Cisco Catalyst 3560G

Switch> enable
Switch# configure terminal
Switch(config)# interface GigabitEthernet0/1
Switch(config-if)# channel-group 1 mode on
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport trunk allowed vlan 11
Switch(config-if)# switchport mode trunk
Switch(config-if)# interface GigabitEthernet0/2
Switch(config-if)# channel-group 1 mode on
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport trunk allowed vlan 11
Switch(config-if)# switchport mode trunk
Switch(config-if)# interface Port-channel1
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport trunk allowed vlan 11
Switch(config-if)# switchport mode trunk
Switch(config-if)# exit
Switch(config)# port-channel load-balance src-ip

port-channel load-balance src-ip
!
interface Port-channel1
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 11
 switchport mode trunk
!
interface GigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 11
switchport mode trunk
channel-group 1 mode on
!
interface GigabitEthernet0/2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 11
switchport mode trunk
channel-group 1 mode on
!

У Вас может возникнуть необходимость поднять 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 и сохранится с указанным комментарием.

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

• Документация по JUNOS
• Настраиваем 802.1Q trunk между свичами Cisco Catalyst 3560G и сервером FreeBSD
• Настраиваем vlan на FreeBSD

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

Автор: Николаев Дмитрий (virus (at) subnets.ru)