untix Опубликовано 25 февраля, 2011 · Жалоба FreeBSD 7.4-STABLE теперь не могу собрать ни em-6.9.6-RELENG7-yandex-1.36.2.17.tar.gz ни e1000-7.0.5-RELENG7-yandex-1.36.2.18.tar.gz Может кто подскажет где копать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xOr Опубликовано 25 февраля, 2011 (изменено) · Жалоба А теперь попробуйте насоздавать, скажем на igb3 скриптом кучку vlan-ов и посмотрите, на какой штуке нарветесь на "could not setup received structures" или что-то подобное, при loader.conf -------------------- hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.num_queues=0 hw.igb.lro=0 hw.igb.enable_msix=1 -------------------- Причем если поиграть с hw.igb.num_queues, то можно подобрать такое количество очередей, при котором на ошибки наступать перестаем, но и тогда под нагрузкой ловятся косяки. Например у меня перестает показывать глюки при инициализации с hw.igb.num_queues=7, но более-менее стабильно работает только при hw.igb.num_queues=6 (по умолчанию, без настройки параметраhw.igb.num_queues, на моей конфигурации создается по 11 очередей) Если поднимать lagg на igb, то и вовсе hw.igb.num_queues=3 - предел, но ловим глюки в работа практически сразу. Параметров крутили много. И это при 2xXeon X5650 (всего 24 потока). Так что пока все печально. PT с дровами yandex на той же конфигурации пока недостижим. С hw.igb.rxd=4096 и hw.igb.txd=4096 сообщение "could not setup received structures" вылетало на старте системы (2 valn-a), но убрав их, неделю живет - полет номальный (700/500 Мбит/с отдачи/входа ) На предидущей версии дров igb (из FreeBSD 8.0) в моем случае нет практически никакой разницы в производительности с родными em, в одинаковых тазиках жуют одинаково трафика 800/400 вход/выход NAT, Netflow, Шейпинг Доброй ночи! Кто-нибудь может посоветовать, что сделать с сетевухами igb, чтобы они не глючили с lagg и vlan? Встроенные bge давали дропы уже на 300 мбит, поэтому купил igb за несколько сотен баксов, а с ними тоже фигня :( Раз в сутки падает! LAGG не разваливается, но перестает принимать пакеты. Причем видно, что со свитча они уходят. На сетевухах на входе не видно, и прерывания они не генерируют (может иногда одно -другое, но не соотв. поступлению пакетов). Сейчас обновляют с FreeBSD 8.1 STABLE до 8.2 RELEASE. Надеюсь что поможет, но по опыту - вряд ли. Изменено 25 февраля, 2011 пользователем xOr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
untix Опубликовано 27 февраля, 2011 · Жалоба А теперь попробуйте насоздавать, скажем на igb3 скриптом кучку vlan-ов и посмотрите, на какой штуке нарветесь на "could not setup received structures" или что-то подобное, при loader.conf -------------------- hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.num_queues=0 hw.igb.lro=0 hw.igb.enable_msix=1 -------------------- Причем если поиграть с hw.igb.num_queues, то можно подобрать такое количество очередей, при котором на ошибки наступать перестаем, но и тогда под нагрузкой ловятся косяки. Например у меня перестает показывать глюки при инициализации с hw.igb.num_queues=7, но более-менее стабильно работает только при hw.igb.num_queues=6 (по умолчанию, без настройки параметраhw.igb.num_queues, на моей конфигурации создается по 11 очередей) Если поднимать lagg на igb, то и вовсе hw.igb.num_queues=3 - предел, но ловим глюки в работа практически сразу. Параметров крутили много. И это при 2xXeon X5650 (всего 24 потока). Так что пока все печально. PT с дровами yandex на той же конфигурации пока недостижим. С hw.igb.rxd=4096 и hw.igb.txd=4096 сообщение "could not setup received structures" вылетало на старте системы (2 valn-a), но убрав их, неделю живет - полет номальный (700/500 Мбит/с отдачи/входа ) На предидущей версии дров igb (из FreeBSD 8.0) в моем случае нет практически никакой разницы в производительности с родными em, в одинаковых тазиках жуют одинаково трафика 800/400 вход/выход NAT, Netflow, Шейпинг Доброй ночи! Кто-нибудь может посоветовать, что сделать с сетевухами igb, чтобы они не глючили с lagg и vlan? Встроенные bge давали дропы уже на 300 мбит, поэтому купил igb за несколько сотен баксов, а с ними тоже фигня :( Раз в сутки падает! LAGG не разваливается, но перестает принимать пакеты. Причем видно, что со свитча они уходят. На сетевухах на входе не видно, и прерывания они не генерируют (может иногда одно -другое, но не соотв. поступлению пакетов). Сейчас обновляют с FreeBSD 8.1 STABLE до 8.2 RELEASE. Надеюсь что поможет, но по опыту - вряд ли. Я так мучался год назад с 8.0. Карточки на борту интел em. поставил семёрку (на тот момент 7.2) и забыл проблему. только вот сейчас обновился до 7.4, а драйвера от яндекса не собираются, пока на родных bsd работаю, проблем вроде как не возникает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fenix-vt Опубликовано 2 марта, 2011 (изменено) · Жалоба http://people.yandex-team.ru/~wawa/em-7.1.....17.2.25.tar.gz эти не пробовали на 8.2 еще? Изменено 2 марта, 2011 пользователем fenix-vt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mr.Scamp Опубликовано 13 марта, 2011 · Жалоба Хм, а как насчет 7.4? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 14 марта, 2011 · Жалоба http://people.yandex-team.ru/~wawa/em-7.1.....17.2.25.tar.gzэти не пробовали на 8.2 еще? В 8 есть netisr - 10 строчек в ether_(input|demux) раскладывают обработку пакетов по нужному количеству netisr-очередей независимо от карточки и драйвера. Зачем колбаситься с фаерволом, натом и шейпером в контексте прерывания, когда нужно быстренько принять пачку пакетов, положить их в соответствующую очередь и освободить обработчик? 10 root 171 ki31 0K 64K RUN 1 1369.1 99.56% {idle: cpu1} 10 root 171 ki31 0K 64K RUN 0 1301.5 97.75% {idle: cpu0} 10 root 171 ki31 0K 64K RUN 3 1318.7 95.65% {idle: cpu3} 10 root 171 ki31 0K 64K CPU2 2 1401.5 91.89% {idle: cpu2} 11 root -44 - 0K 400K WAIT 2 197.5H 6.01% {swi1: netisr 2} 11 root -44 - 0K 400K CPU0 0 192.8H 4.74% {swi1: netisr 0} 11 root -44 - 0K 400K WAIT 3 192.8H 4.74% {swi1: netisr 3} 11 root -44 - 0K 400K WAIT 1 192.0H 4.54% {swi1: netisr 1} 11 root -68 - 0K 400K CPU3 3 101.0H 3.47% {irq259: em1:rx 0} 51800 root 45 0 118M 57808K select 0 67.0H 3.22% {mpd5} 11 root -68 - 0K 400K WAIT 1 42.4H 1.03% {irq256: em0:rx 0} 11 root -68 - 0K 400K WAIT 0 19.6H 0.73% {irq257: em0:tx 0} 11 root -68 - 0K 400K WAIT 0 25.2H 0.63% {irq260: em1:tx 0} 0 root -68 0 0K 160K - 0 59.3H 0.00% {dummynet} Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mr.Scamp Опубликовано 14 марта, 2011 · Жалоба А как насчет pf, например? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AntonS Опубликовано 22 марта, 2011 · Жалоба ну у кого под 8.2 нормально заработало? с последними драйверами от февраля 2011 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Rotator87 Опубликовано 22 марта, 2011 · Жалоба Интерестно когда igb будут рабочими :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dystopian Опубликовано 23 марта, 2011 · Жалоба FreeBSD 7.3-RELEASE-p4, дрова e1000-7.0.5-RELENG7-yandex-1.36.2.18, сетевуха em0 Intel 82566DM. При создании/удалении вланов (порядка 200, меньше не проверял) перестает работать TCP; ARP, UDP, ICMP работают нормально. Помогает ifconfig em0 -rxcsum. Также странно, что если вланы создаются при загрузке системы rc-скриптом, все работает нормально до первого создания/удаления влана ручками. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Laa Опубликовано 23 марта, 2011 · Жалоба Интерестно когда igb будут рабочими :)За 11 дней аптайма полет нормальный.Средняя нагрузка порядка 22 кппс за эти 11 дней. В пики доходит до 55кппс. Пока моим кастомерам больше не надо. :) # uname -rs FreeBSD 8.2-RELEASE # netstat -id|grep ^igb igb0 1500 <Link#1> 00:1b:21:4a:4e:1c 18891344798 0 0 17396457783 0 0 0 igb1 1500 <Link#2> 00:1b:21:4a:4e:1d 17980987850 0 0 18371618493 0 0 0 igb1 1500 192.168.0.0/1 192.168.0.1 37315897 - - 28535342 - - - # uptime 12:41 up 11 days, 5:41, 5 users, load averages: 0,03 0,09 0,08 # sysctl dev.igb|grep desc: dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.0.7 dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 2.0.7 # Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Laa Опубликовано 23 марта, 2011 (изменено) · Жалоба FreeBSD 7.3-RELEASE-p4, дрова e1000-7.0.5-RELENG7-yandex-1.36.2.18, сетевуха em0 Intel 82566DM. При создании/удалении вланов (порядка 200, меньше не проверял) перестает работать TCP; ARP, UDP, ICMP работают нормально. Помогает ifconfig em0 -rxcsum. Также странно, что если вланы создаются при загрузке системы rc-скриптом, все работает нормально до первого создания/удаления влана ручками.Попробуйте свежие e1000 драйвера из FreeBSD-CURRENT. 3-4 дня назад их внес Jack и скоро уже будет MFC.Вроде он внедрил массу доработок. з.ы. опсь, а для этой темы это оффтопик.. ;) Изменено 23 марта, 2011 пользователем Laa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
blackjack Опубликовано 24 марта, 2011 · Жалоба С hw.igb.rxd=4096 и hw.igb.txd=4096 сообщение "could not setup received structures" вылетало на старте системы (2 valn-a), но убрав их, неделю живет - полет номальный (700/500 Мбит/с отдачи/входа ) Это как бы не выход =) у меня на двухядерном ксеоне CPU: Intel(R) Xeon(R) CPU E5503 @ 2.00GHz (2002.51-MHz K8-class CPU) стоит две двухпортовых igb, в одну вхдят два гиговых канала, с другой сделан лагг. тоже была такая фигня, помог подбор параметра hw.igb.num_queues=2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 25 марта, 2011 (изменено) · Жалоба а что в 8.2 следует использовать для успокоения dummynet? Поставил на тестирование 8.2 релиз, трафика мегабит 20-30 всего, dummynet периодически съедает до 100% одного ядра без всяких видимых причин (каких-то увеличений pps и mbps в эти моменты нет) . Рядом в таком-же тазу стоит 7.х с яндекс-драйверами + сpuset и такого не наблюдается на трафе в десятки раз большем. А тут что? Изменено 25 марта, 2011 пользователем umike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 31 марта, 2011 · Жалоба а что в 8.2 следует использовать для успокоения dummynet? Поставил на тестирование 8.2 релиз, трафика мегабит 20-30 всего, dummynet периодически съедает до 100% одного ядра без всяких видимых причин (каких-то увеличений pps и mbps в эти моменты нет) . Рядом в таком-же тазу стоит 7.х с яндекс-драйверами + сpuset и такого не наблюдается на трафе в десятки раз большем. А тут что? Из личных наблюдений - даминет должен жить на одном ядре с прерываниями от таймера, как правило это ядро 0, по возможности на этом ядре не должно жить больше ничего. Прибивание даминета на другие ядра вызывало крепкие скачки нагрузки независимо от трафика, сам трафик вроде как ни на что и не влияет. Это 8-stable еще со времен 8.1, на неделе какраз собирался затягивать свежий stable для экспериментов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 31 марта, 2011 (изменено) · Жалоба # netstat -id|grep ^igb igb0 1500 <Link#1> 00:1b:21:4a:4e:1c 18891344798 0 0 17396457783 0 0 0 igb1 1500 <Link#2> 00:1b:21:4a:4e:1d 17980987850 0 0 18371618493 0 0 0 igb1 1500 192.168.0.0/1 192.168.0.1 37315897 - - 28535342 - - - Вот это лишнее, ИМХО, интерфейсов м.б. тысячи, лучше так: netstat -id -I igb0 && netstat -id -I igb1 Изменено 31 марта, 2011 пользователем Deac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Сильвер Опубликовано 31 марта, 2011 · Жалоба Из личных наблюдений - даминет должен жить на одном ядре с прерываниями от таймера, как правило это ядро 0, по возможности на этом ядре не должно жить больше ничего. Прибивание даминета на другие ядра вызывало крепкие скачки нагрузки независимо от трафика, сам трафик вроде как ни на что и не влияет. Это 8-stable еще со времен 8.1, на неделе какраз собирался затягивать свежий stable для экспериментов. Тоже из наблюдений, cpuset -l 0 -t $(procstat -t 0 | awk '/dummynet/ {print $2}') приносит облегчение. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 4 апреля, 2011 · Жалоба 10 root 171 ki31 0K 64K RUN 1 1369.1 99.56% {idle: cpu1} 10 root 171 ki31 0K 64K RUN 0 1301.5 97.75% {idle: cpu0} 10 root 171 ki31 0K 64K RUN 3 1318.7 95.65% {idle: cpu3} 10 root 171 ki31 0K 64K CPU2 2 1401.5 91.89% {idle: cpu2} 11 root -44 - 0K 400K WAIT 2 197.5H 6.01% {swi1: netisr 2} 11 root -44 - 0K 400K CPU0 0 192.8H 4.74% {swi1: netisr 0} 11 root -44 - 0K 400K WAIT 3 192.8H 4.74% {swi1: netisr 3} 11 root -44 - 0K 400K WAIT 1 192.0H 4.54% {swi1: netisr 1} 11 root -68 - 0K 400K CPU3 3 101.0H 3.47% {irq259: em1:rx 0} 51800 root 45 0 118M 57808K select 0 67.0H 3.22% {mpd5} 11 root -68 - 0K 400K WAIT 1 42.4H 1.03% {irq256: em0:rx 0} 11 root -68 - 0K 400K WAIT 0 19.6H 0.73% {irq257: em0:tx 0} 11 root -68 - 0K 400K WAIT 0 25.2H 0.63% {irq260: em1:tx 0} 0 root -68 0 0K 160K - 0 59.3H 0.00% {dummynet} это какая версия? Настройками не поделитесь? У меня если взять дефолтные дрова на 8.2 картина выглядит как-то вовсе безрадостно net.isr.numthreads: 4 net.isr.bindthreads: 0 net.isr.maxthreads: 4 net.isr.direct: 0 net.isr.direct_force: 0 11 root 171 ki31 0K 32K CPU3 3 39.2H 100.00% {idle: cpu3} 11 root 171 ki31 0K 32K RUN 1 38.6H 100.00% {idle: cpu1} 11 root 171 ki31 0K 32K CPU0 0 38.3H 100.00% {idle: cpu0} 11 root 171 ki31 0K 32K CPU2 2 37.6H 91.26% {idle: cpu2} 12 root -44 - 0K 192K WAIT 2 178:44 15.28% {swi1: netisr 3} 12 root -44 - 0K 192K WAIT 3 86:39 1.37% {swi1: netisr 0} 0 root -68 0 0K 96K - 0 108:37 0.00% {dummynet} 0 root -68 0 0K 96K - 0 22:00 0.00% {em1 taskq} 0 root -68 0 0K 96K - 3 15:50 0.00% {em0 taskq} 12 root -32 - 0K 192K WAIT 1 6:51 0.00% {swi4: clock} Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 4 апреля, 2011 (изменено) · Жалоба это какая версия? Настройками не поделитесь? У меня если взять дефолтные дрова на 8.2 картина выглядит как-то вовсе безрадостно net.isr.numthreads: 4 net.isr.bindthreads: 0 net.isr.maxthreads: 4 net.isr.direct: 0 net.isr.direct_force: 0 Настройками не поделюсь, не рулится оно простыми sysctl. Для нормального распаралеливания нужен нормальный flowid, я его рассчитал примерно вот так: diff -Nur /usr/src/sys/net/if_ethersubr.c /root/src/sys/net/if_ethersubr.c --- /usr/src/sys/net/if_ethersubr.c 2010-09-12 01:02:36.000000000 +0300 +++ /root/src/sys/net/if_ethersubr.c 2010-11-11 22:57:29.000000000 +0200 @@ -621,6 +622,11 @@ ifp->if_imcasts++; } + m->m_flags |= M_FLOWID; + m->m_pkthdr.flowid = eh->ether_dhost[0] + eh->ether_dhost[1] + eh->ether_dhost[2] + eh->ether_dhost[3] + eh->ether_dhost[4] + eh->ether_dhost[5]; + m->m_pkthdr.flowid += eh->ether_shost[0] + eh->ether_shost[1] + eh->ether_shost[2] + eh->ether_shost[3] + eh->ether_shost[4] + eh->ether_shost[5]; + + #ifdef MAC /* * Tag the mbuf with an appropriate MAC label before any other @@ -830,6 +836,29 @@ if ((m = ip_fastforward(m)) == NULL) return; isr = NETISR_IP; + + struct ipheader { + u_char offset [12]; //ip header fields not actually needed here + u_char src [4]; //ip src + u_char dst [4]; //ip dst + } __packed __aligned(4); + + if (m->m_pkthdr.len < sizeof(struct ipheader)) { //from ip_fastforward + if_printf(ifp, "flowid math: discard frame with too small header\n"); + goto discard; + } + if (m->m_len < sizeof (struct ipheader) && + (m = m_pullup(m, sizeof (struct ipheader))) == NULL) { //ip_fastforward + if_printf(ifp, "flowid math: discard frame at pullup\n"); + return; /* mbuf already free'd */ + } + struct ipheader *ip; + ip = mtod(m, struct ipheader *); + m->m_pkthdr.flowid += ip->src[0] + ip->src[1] + ip->src[2] + ip->src[3]; + m->m_pkthdr.flowid += ip->dst[0] + ip->dst[1] + ip->dst[2] + ip->dst[3]; + +// if_printf(ifp, "Calculated flow id %d\n", m->m_pkthdr.flowid); + break; case ETHERTYPE_ARP: Выглядит криво конечно, работает только для ethernet и ipv4, но я нифига не девелопер, и я хз почему это не сделали в базовой системе - штука тривиальная на самом деле, может кто знающий подскажет почему. Ну и по хорошему нужно нормальный патч, ну чтобы там можно было включать-выключать это через sysctl да и рассчет flowid можно дернуть макросами, которые в lagg используются и запостить pr какой-то. Изменено 4 апреля, 2011 пользователем make.kernel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 5 апреля, 2011 · Жалоба насколько я понял активно используется flowtable. И не впадает в ступор? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adeep Опубликовано 5 апреля, 2011 (изменено) · Жалоба Выглядит криво конечно, работает только для ethernet и ipv4, но я нифига не девелопер, и я хз почему это не сделали в базовой системе - штука тривиальная на самом деле, может кто знающий подскажет почему. Ну и по хорошему нужно нормальный патч, ну чтобы там можно было включать-выключать это через sysctl да и рассчет flowid можно дернуть макросами, которые в lagg используются и запостить pr какой-то. А пробовали добавить аналогичный код для Ethernet фреймов (PPPoE)? судя по netisr.h можно и ethernet фреймы так обработать. И можно еще подумать над hash функцией от исходных данных. Изменено 5 апреля, 2011 пользователем adeep Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adeep Опубликовано 5 апреля, 2011 · Жалоба насколько я понял активно используется flowtable. И не впадает в ступор? flowtable тут не причем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 5 апреля, 2011 · Жалоба Выглядит криво конечно, работает только для ethernet и ipv4, но я нифига не девелопер, и я хз почему это не сделали в базовой системе - штука тривиальная на самом деле, может кто знающий подскажет почему. Ну и по хорошему нужно нормальный патч, ну чтобы там можно было включать-выключать это через sysctl да и рассчет flowid можно дернуть макросами, которые в lagg используются и запостить pr какой-то. А пробовали добавить аналогичный код для Ethernet фреймов (PPPoE)? судя по netisr.h можно и ethernet фреймы так обработать. И можно еще подумать над hash функцией от исходных данных. Не пробовал, просто и так трафик размазался достаточно хорошо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Daniil_ Опубликовано 6 июня, 2011 · Жалоба Поставил дрова от яндекса, по умолчанию каждая сетевая паралелится на 2 ядра 0 root 70 0 0K 240K CPU4 4 74:16 38.13% {em1_rx0_0} 0 root 66 0 0K 240K PKWAIT 5 66:16 36.18% {em0_rx0_0} 0 root 67 0 0K 240K PKWAIT 1 66:21 35.64% {em0_rx0_1} 0 root 65 0 0K 240K CPU6 6 74:09 34.67% {em1_rx0_1} можно ли как-то заставить каждую сетевую паралелится на 4 ядра например? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
John_obn Опубликовано 7 ноября, 2011 · Жалоба Какие дрова сейчас ставить лучше для карточек igb (82576), родные последние с сайта Intel или дрова от wawa? FreeBSD 7.4-STABLE, машина в роли роутера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...