Перейти к содержимому
Калькуляторы

Несколько BGP (quagga) роутеров?

Да не запинайте ногами ближнего своего :)

 

ЧТО ЕСТЬ: Сейчас BGP-роутер один (debian+quagga) и, соответственно, более-менее нормально распределяет трафик между каналами и в нормальном режиме и когда один из каналов падает. Однако в пике загрузка по процессору уже подбирается к 70-75%. Следовательно, расширяя канал, я почти наверняка упрусь в потолок производительности.

Внутри сети OSPF. Из БГП внутренней карточкой смотрит в сегмент, в который смотрят 10 NAS-ов (FreeBSD+mpd). Правда, планирую пересобрать это в формате БГП - 2 Шейпера - 10 НАСов.

 

ЧЕГО ХОЧЕТСЯ: Понять, в какую сторону правильно плясать от этой печки:

а) можно отапгрейдить железо и тем отодвинуть потолок на некоторое (возможно, достаточно длительное) время;

б) уже сейчас разделить каналы на разные БГП-роутеры;

 

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

 

Что я не очень понимаю:

1) Очевидно, придется редистрибьютить фулл-вью бгп в оспф. Иначе как они узнают, через кого отдается оптимальный маршрут и через кого ходить, если канал падает. Но это сильно забьет таблицу маршрутов на НАСах, что не айс. Альтернатива: редистрибьютить маршруты только до двух шейперов, шейперы собрать в CARP, а для НАСов уже будет один единственный default.

2) Должны ли БГП-роутеры общаться между собой? И если да, то где об этом почитать? Прогуглив ничего особенно не нашел на предмет конфигураций с несколькими БГП.

3) Стоит ли вообще городить этот огород с отдельными машинками?

 

Если кто-то уже успешно и красиво это реализовал, или знает как - поделитесь схемой, конфигом или ссылкой на почитать.. Пожааалуйста :)

Изменено пользователем ibmed

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

О разделении мысль верная.

Только зачем редистребьют? Нужно между двумя BGP поднять iBGP линк и гонять по нему фулвью.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

О разделении мысль верная.

Только зачем редистребьют? Нужно между двумя BGP поднять iBGP линк и гонять по нему фулвью.

Гм.

А как исходящий трафик будет разделяться? Если не делать редистрибьют, то мы остаемся только с маршрутом по умолчанию на роутерах, смотрящих на БГП..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

О разделении мысль верная.

Только зачем редистребьют? Нужно между двумя BGP поднять iBGP линк и гонять по нему фулвью.

Гм.

А как исходящий трафик будет разделяться? Если не делать редистрибьют, то мы остаемся только с маршрутом по умолчанию на роутерах, смотрящих на БГП..

исходящий как обычно, в некоторых случаях будет подряд два бордера.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Разделять на разные железки БГП только из-за нагрузки не есть гуд по моемому. Обычно это делают когда аплинки в разных местах подают каналы или ещё какието причины. Я бы задумался о железном варианте.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 ibmed:

 

а не поделитесь цифрами - количество абонентов/суммарная полоса аплинков/процессор/сетевые ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 ibmed:

 

а не поделитесь цифрами - количество абонентов/суммарная полоса аплинков/процессор/сетевые ?

Да, с удовольствием - может кому-то будет полезно.

БГП сейчас живет на дебиане, что происходит еще со времен, когда мы натили пользователей. Хотя фря мне куда милее, но на момент установки машинки, линукс НА ГОЛОВУ лучше натил, чем фря (сейчас не знаю - переехали на белые адреса).

 

Машинка делает только bgp+ospf. Iptables выкомпилены из ядра.

Суммарная емкость каналов: 1.5G

Пользователей в чнн - примерно 3500-3800

 

Linux debian 2.6.30 #8 SMP Mon Jul 27 08:12:32 MSD 2009 i686 GNU/Linux

 

Железо:

model name : Intel® Core2 Quad CPU Q6600 @ 2.40GHz

MemTotal: 3636324 kB

4х портовый Intel (e1000e: Intel® PRO/1000 Network Driver - 1.0.2.5-NAPI)

 

Нагрузка:

Time Int rKB/s wKB/s rPk/s wPk/s rAvs wAvs %Util Sat

23:24:48 bond0 5.48 519.7 275581 238518 0.02 2.23 0.00 3676.5

23:24:49 bond0 150136 136498 267778 235705 574.1 593.0 0.00 2085.1

23:24:50 bond0 145706 132029 263263 232181 566.7 582.3 0.00 0.00

23:24:51 bond0 145066 124750 261689 225558 567.7 566.3 0.00 4558.2

23:24:52 bond0 145468 129694 261564 227004 569.5 585.0 0.00 0.00

23:24:53 bond0 144394 131243 263996 230733 560.1 582.5 0.00 2571.8

23:24:54 bond0 144105 131382 263899 233221 559.2 576.9 0.00 0.00

23:24:55 bond0 148000 132686 267199 233429 567.2 582.1 0.00 0.00

 

при этом

debian:~/nicstat-1.22# netstat -i

Kernel Interface table

Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg

bond0 1500 0 1752538785 0 23199120 0 1516900495 0 0 0 BMmRU

 

(т.е. имеются RX-DRP)

 

TOP:

Tasks: 101 total, 1 running, 100 sleeping, 0 stopped, 0 zombie

Cpu0 : 0.3%us, 0.3%sy, 0.0%ni, 45.7%id, 0.0%wa, 4.1%hi, 49.5%si, 0.0%st

Cpu1 : 0.7%us, 0.0%sy, 0.0%ni, 41.6%id, 0.0%wa, 4.8%hi, 52.9%si, 0.0%st

Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 47.0%id, 0.0%wa, 4.2%hi, 48.8%si, 0.0%st

Cpu3 : 0.7%us, 0.0%sy, 0.0%ni, 53.7%id, 0.4%wa, 4.2%hi, 41.1%si, 0.0%st

Mem: 3636324k total, 600032k used, 3036292k free, 91764k buffers

Swap: 0k total, 0k used, 0k free, 184016k cached

 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

8 root 15 -5 0 0 0 S 4 0.0 3:33.85 ksoftirqd/2

6 root 15 -5 0 0 0 S 3 0.0 8:35.73 ksoftirqd/1

 

Что довольно странно: на данный момент машинка примерно на 50% в idle, однако уже второй день вижу потери пакетов порядка 1-3% по пингу на локальный интерфейс. Сие довольно странно, т.к. нагрузка бывало доходила и до 70%+ и оно жило. Возможно железо, возможно, что-то еще - пока не разобрался. В ближайшее время расширяем канал и добавляем скорости к анлимам, так что нагрузка еще возрастет. Под все это дело решил переехать на фрю.

Кстати по нашим тестам в формате выкомпиленного файрвола и линк-агрегейшн фря давала большую скорость, чем линукс.

 

Что-то еще забыл? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опишу, как у нас: сейчас два аплинка, в сумме порядка 2gb In + 2gb Out

На машинке ospf нет, ната/шейпа нет, iptables самый минимум, БГП к аплинкам и iBGP к насам (для роутинга белых ипов)

 

Крутится генту

Linux gw.ip-home.net 2.6.32.7 #5 SMP x86_64 Intel® Xeon® CPU E5504 @ 2.00GH

 

Стоит два 4-головых интела:

10:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10e8] (rev 01)

Subsystem: Intel Corporation Gigabit ET Quad Port Server Adapter [8086:a02b]

Kernel driver in use: igb

 

Но задействованы сейчас только 4 порта из них. Собраны в бонд, по которому гоняется весь трафик. Из восьми ядер, соответственно, загружены 4 -- на каждое по сетевухе. При загрузке 1.8 гбит фулдуплекс (3.6 гб по-цисковски ;) - software interrupts на загруженных ядрах составляет ~50%

Сейчас тоже будем расширяться, но всё расширение в итоге сойдется в задействовании ещё 4-х портов в бонде ;) Они нагрузят простаивающие сейчас ещё 4 ядра. Такая схема теоретически потащит 4гб ин + 4 аут без проблем. Ну на крайняк - заменим процы, 2ггц уже не очень смотрится.

Ни потерь ни лагов по вине машинки до сих пор не было, юзеры счастливы, жмакая спидтест и пингтест ;)

 

 

 

 

Кроме того, чтобы разгрузить pc, я сейчас думаю попробовать схему: выпросить у аплинков по лишнему пиринговому IP, воткнуть интерфейсы каталиста в пиринговое пространство, и БГП-бордером отдавать аплинкам next-hop = интерфейс каталиста. Таким образом весь входящий трафик будет идти через железо, соответственно, писюк в 2 раза разгрузится. Если всё хорошо пойдёт - скоро потестирую =)

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опишу, как у нас: сейчас два аплинка, в сумме порядка 2gb In + 2gb Out

На машинке ospf нет, ната/шейпа нет, iptables самый минимум, БГП к аплинкам и iBGP к насам (для роутинга белых ипов)

А можно об этом подробнее? Как это? Квагга на NAS-е видит новые маршруты (читай: новые PPP) и отправляет их бордеру?

Нет ли задержки?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опишу, как у нас: сейчас два аплинка, в сумме порядка 2gb In + 2gb Out

На машинке ospf нет, ната/шейпа нет, iptables самый минимум, БГП к аплинкам и iBGP к насам (для роутинга белых ипов)

А можно об этом подробнее? Как это? Квагга на NAS-е видит новые маршруты (читай: новые PPP) и отправляет их бордеру?

Нет ли задержки?

Задержек нет, единственное - на НАСе не квага, там микротики

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опишу, как у нас: сейчас два аплинка, в сумме порядка 2gb In + 2gb Out

На машинке ospf нет, ната/шейпа нет, iptables самый минимум, БГП к аплинкам и iBGP к насам (для роутинга белых ипов)

А можно об этом подробнее? Как это? Квагга на NAS-е видит новые маршруты (читай: новые PPP) и отправляет их бордеру?

Нет ли задержки?

Задержек нет, единственное - на НАСе не квага, там микротики

Спасибо, понял.

А почему не OSPF?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опишу, как у нас: сейчас два аплинка, в сумме порядка 2gb In + 2gb Out

На машинке ospf нет, ната/шейпа нет, iptables самый минимум, БГП к аплинкам и iBGP к насам (для роутинга белых ипов)

А можно об этом подробнее? Как это? Квагга на NAS-е видит новые маршруты (читай: новые PPP) и отправляет их бордеру?

Нет ли задержки?

Задержек нет, единственное - на НАСе не квага, там микротики

Спасибо, понял.

А почему не OSPF?

Исторически сложилось так, а сейчас переделывать особых причин нет =)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ibmed я так понимаю вы ставя два шейпера (почему не в бридже кстати?) получаете такую схему:

NAS1,NAS5 - shaper1 - border и NAS6,10 - shaper 2 - border ?

так что мешает в таком случае поставить 2 бордера, и с обоих сессии к аплинку/аплинкам поднять? ну и между собой докучи еще можно, чтобы часть своих адресов не через аплинка была доступна. получится типовая схема помноженная на два, которую впоследствии можно сколько угодно раз повторять. До кучи для hot_backup можно добавить внутрь iBGP и анонсить с бордеров внутрь default с разным AS-path или weight, или пользоваться localpref для распределения.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

[GP]Villi

Не совсем так.

На данный момент наиболее правильной схемой в сценарии с двумя БГП мне кажется что-то вроде:

 

БГП1 =\_/= Шейпер1

БГП2 =/ \= Шейпер2

 

Оба БГП при этом будут отдавать по ОСПФ свой фулл-вью, а Шейперы на сетевых, смотрящих в сторону НАСов будут собраны в CARP, чтобы у насов оставался один единственный дефолт, и фулл-вью дальше шейперов не выходил.

Таким образом лучше обеспечивается отказоустойчивость (БГП упал, анонсы в оспф перестали, маршруты прозрачно построились через живой бгп).

 

Почему не бриджом?

Ну во-первых, наверное, я просто не знал, насколько хорошо бридж справляется с нагрузкой против роутера (хорошо?).

Во-вторых, в приведенной схеме при использовании Шейпов как бриджей придется-таки рассказывать НАСам про фулл-вью, либо изобретать что-то другое (С iBGP, честно, никогда не игрался и пока не умею - возможно, оно там получается красивей, чем мне кажется? Поищу на почитать.).

 

P.S> В данный момент я больше склоняюсь-таки к железячному сценарию развития. :)

Изменено пользователем ibmed

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сегодня переехали на новое железо и фрю. Однако..

 

CPU: Intel® Xeon® CPU E5420 @ 2.50GHz (2506.23-MHz K8-class CPU)

Origin = "GenuineIntel" Id = 0x1067a Stepping = 10

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLU

SH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>

Features2=0x40ce3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,<b19>,XSAVE>

AMD Features=0x20100800<SYSCALL,NX,LM>

AMD Features2=0x1<LAHF>

Cores per package: 4

usable memory = 8576208896 (8178 MB)

avail memory = 8250183680 (7867 MB)

ACPI APIC Table: <INTEL S5000PSL>

FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs

 

 

7.2-RELEASE-p7 amd64

Ядро - практически GENERIC, только убрано ненужное.

 

2 четырехголовых Интела (em) с последним драйвером от Яндекса (<Intel® PRO/1000 Network Connection 6.9.6.Yandex[$Revision: 1.36.2.17 $]>).

По одному порту на два канала. 3 порта в lacp lagg в сторону локалки.

 

bgp# cat /boot/loader.conf

vm.kmem_size=3G

 

hw.em.rxd=4096

hw.em.txd=4096

 

 

cat /etc/sysctl.conf:

net.inet.ip.fastforwarding=1

 

sysctl -w dev.em.2.rx_int_delay=750

sysctl -w dev.em.2.tx_int_delay=750

sysctl -w dev.em.2.rx_abs_int_delay=1000

sysctl -w dev.em.2.tx_abs_int_delay=1000

 

sysctl -w dev.em.3.rx_int_delay=750

sysctl -w dev.em.3.tx_int_delay=750

sysctl -w dev.em.3.rx_abs_int_delay=1000

sysctl -w dev.em.3.tx_abs_int_delay=1000

 

sysctl -w dev.em.7.tx_int_delay=750

sysctl -w dev.em.7.rx_int_delay=750

sysctl -w dev.em.7.rx_abs_int_delay=1000

sysctl -w dev.em.7.tx_abs_int_delay=1000

 

sysctl -w dev.em.8.tx_int_delay=750

sysctl -w dev.em.8.rx_int_delay=750

sysctl -w dev.em.8.rx_abs_int_delay=1000

sysctl -w dev.em.8.tx_abs_int_delay=1000

 

sysctl -w dev.em.9.tx_int_delay=750

sysctl -w dev.em.9.rx_int_delay=750

sysctl -w dev.em.9.rx_abs_int_delay=1000

sysctl -w dev.em.9.tx_abs_int_delay=1000

 

(Пробовал играться с этими показателями. Поначалу выставил все значения в 250 - нагрузка процов уже при 500kpps была порядка 50%. Поменял все значения на 500 - нагрузка мгновенно упала вдвое, без каких-либо дропов. Увеличение до 750 совсем чуть-чуть снизило нагрузку. Дальнейшее увеличение результатов не принесло и было оставлено в том виде, в котором приведено).

 

 

bgp# netstat -w1

input (Total) output

packets errs bytes packets errs bytes colls

850599 0 550159804 834747 0 521952924 0

850871 0 546076120 832834 0 518072008 0

861307 0 550636679 842033 0 522021955 0

860054 0 551806145 839254 0 522651924 0

858529 0 548114024 838182 0 519862948 0

864952 0 554527751 846750 0 525230852 0

855247 0 546161607 840761 0 519676813 0

 

(перемалывал и больше - под 1Mpp/s, почти совсем без дропов (200-500 пакетов на 950Кппс))

 

 

Но.

Нагрузка по процам такая же как была на 4-ядерном железе под линуксом еще вчера. И это странно.

 

last pid: 13429; load averages: 5.03, 4.97, 5.36 up 0+11:50:21 23:08:12

141 processes: 12 running, 115 sleeping, 14 waiting

CPU 0: 0.0% user, 0.0% nice, 65.2% system, 0.0% interrupt, 34.8% idle

CPU 1: 0.4% user, 0.0% nice, 65.0% system, 0.0% interrupt, 34.6% idle

CPU 2: 0.0% user, 0.0% nice, 55.3% system, 0.0% interrupt, 44.7% idle

CPU 3: 0.0% user, 0.0% nice, 57.1% system, 0.0% interrupt, 42.9% idle

CPU 4: 0.0% user, 0.0% nice, 53.2% system, 0.0% interrupt, 46.8% idle

CPU 5: 0.0% user, 0.0% nice, 50.6% system, 0.0% interrupt, 49.4% idle

CPU 6: 0.0% user, 0.0% nice, 49.1% system, 0.0% interrupt, 50.9% idle

CPU 7: 0.0% user, 0.0% nice, 46.8% system, 0.0% interrupt, 53.2% idle

Mem: 259M Active, 58M Inact, 302M Wired, 92K Cache, 21M Buf, 7273M Free

Swap: 8192M Total, 8192M Free

 

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND

44 root 1 43 - 0K 16K CPU6 6 309:57 67.09% em3_rx_kthread_1

43 root 1 43 - 0K 16K CPU5 5 310:32 64.60% em3_rx_kthread_0

11 root 1 171 ki31 0K 16K CPU7 7 476:43 55.18% idle: cpu7

12 root 1 171 ki31 0K 16K RUN 6 472:29 51.86% idle: cpu6

13 root 1 171 ki31 0K 16K RUN 5 457:13 49.07% idle: cpu5

14 root 1 171 ki31 0K 16K CPU4 4 438:51 47.75% idle: cpu4

15 root 1 171 ki31 0K 16K CPU3 3 421:27 44.29% idle: cpu3

16 root 1 171 ki31 0K 16K CPU2 2 398:34 40.38% idle: cpu2

17 root 1 171 ki31 0K 16K CPU1 1 372:24 37.99% idle: cpu1

64 root 1 43 - 0K 16K WAIT 3 192:05 36.87% em8_rx_kthread_1

18 root 1 171 ki31 0K 16K RUN 0 356:56 36.67% idle: cpu0

63 root 1 43 - 0K 16K WAIT 3 192:23 34.08% em8_rx_kthread_0

60 root 1 43 - 0K 16K WAIT 4 192:10 33.50% em7_rx_kthread_1

42 root 1 -68 - 0K 16K CPU7 7 73:10 33.15% em3_txcleaner

59 root 1 43 - 0K 16K WAIT 4 192:23 32.18% em7_rx_kthread_0

39 root 1 43 - 0K 16K WAIT 1 197:14 31.79% em2_rx_kthread_0

40 root 1 43 - 0K 16K WAIT 2 196:49 29.98% em2_rx_kthread_1

68 root 1 43 - 0K 16K WAIT 2 128:59 22.46% em9_rx_kthread_1

67 root 1 43 - 0K 16K WAIT 0 129:15 22.17% em9_rx_kthread_0

38 root 1 -68 - 0K 16K WAIT 6 51:37 18.36% em2_txcleaner

58 root 1 -68 - 0K 16K WAIT 0 27:35 11.96% em7_txcleaner

62 root 1 -68 - 0K 16K WAIT 0 27:40 11.08% em8_txcleaner

66 root 1 -68 - 0K 16K WAIT 3 27:07 10.50% em9_txcleaner

4753 root 1 44 0 179M 172M select 1 3:46 0.00% bgpd

 

 

Я ожидал увидеть как минимум 25% снижение нагрузки по графикам. В ближайшее время, возможно, попробую собрать конфигурацию на том же железе, что сейчас с фрей, но под линуксом. Если кто-то может поделиться советами по тюнингу линукса в контекст высокопроизводительного роутера - буду признателен.

Изменено пользователем ibmed

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Wingman

А не покажете суммарное количество pps по интерфейсам в ЧНН?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Wingman

А не покажете суммарное количество pps по интерфейсам в ЧНН?

1434835 Packets/s сейчас при чуть более гбит/с в обе стороны. Вообще надо было в субботу смотреть ;) в след. выходные гляну, отпишу

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Wingman

О как..

Получается, линукс и здесь фрю делает.. "Обидно, Вань" (с) :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Получается, линукс и здесь фрю делает.. "Обидно, Вань" (с) :)

Кому обидно, а кто пойдет троллить BSDельников. ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

какой смысл в дровах от яндекса если у вас и так сетевух больше чем ядер?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Wingman

О как..

Получается, линукс и здесь фрю делает.. "Обидно, Вань" (с) :)

1953016 Packets/s

759616448.png

13273767.png

:P

И это где-то 60-70% от пиков по выходным, так что да, конкретно в этом случае - делает =))

 

 

По одному порту на два канала. 3 порта в lacp lagg в сторону локалки.
Почему бы не попробовать собрать все линки (и в локалку, и от аплинков) на коммутатор, и гонять трафик на бордер в едином бонде? Так по идее нагрузка должна более равномерно распределяться. Ну и оставшиеся сетевушки задействуйте, пусть простаивающие ядра вкалывают

Ну и да, линух поставьте %) (ядро ванильное без левых патчей; отрубите socket security hooks - лишняя нагрузка, ну и почитайте тут на наге ветку про linux softrouter и за последние месяцы пара подобных тем была про оптимизацию, много полезного почерпнул)

 

(P.s. при работе с линухом, conntrack, надеюсь, отрубали? 0_о)

Изменено пользователем Wingman

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Wingman

Спасибо за наводки. Топики уже читаю.

Не затруднит ли Вас поделиться конфигом ядра и прочими тюнингами от вашей success-story? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Wingman

Спасибо за наводки. Топики уже читаю.

Не затруднит ли Вас поделиться конфигом ядра и прочими тюнингами от вашей success-story? :)

В личку скину

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Wingman

Спасибо за наводки. Топики уже читаю.

Не затруднит ли Вас поделиться конфигом ядра и прочими тюнингами от вашей success-story? :)

В личку скину

ну вот...с таким интересом следил за темой :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.