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

NAT порядка 500 правил (режем серую сеть по /24 и натим во внешний адрес)

т.е. каждый пакет пробегает в среднем 250 правил файрвола. отсюда и затыки...

 

делайте нормальный нат в диапазон адресов и не мучьтесь.

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


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

Не каждый. Только первый из соединения. А что говорит pref top

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


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

Не каждый. Только первый из соединения. А что говорит pref top

 

5,51%  [ixgbe]                 [k] ixgbe_poll
 5,16%  [ip_tables]             [k] ipt_do_table
 5,10%  [kernel]                [k] fib_table_lookup
 4,41%  [kernel]                [k] __ticket_spin_lock
 3,24%  [ixgbe]                 [k] ixgbe_xmit_frame_ring
 3,16%  [nf_conntrack]          [k] ____nf_conntrack_find
 2,20%  [kernel]                [k] __copy_skb_header
 2,13%  [kernel]                [k] nf_iterate
 1,91%  [kernel]                [k] __netif_receive_skb
 1,68%  [kernel]                [k] dev_queue_xmit
 1,68%  [kernel]                [k] skb_release_head_state
 1,35%  [kernel]                [k] check_leaf.isra.9

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


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

2 Wiredom

net.netfilter.nf_conntrack_tcp_timeout_established = 90

жестокий вы человек :)

а вообще тоже склонен к правилам. если сделано для лучшего определения кто куда ходил. то временно нат в подсеть сделайте для оценки ситуации, а там думать.

конечно пакет цепочку проходит один раз. Но в нат модуле проверка внешних айпи по возврату тоже 500 раз делается. Может ошибаюсь, но легче попробовать чем в исходники опять лезть

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

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


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

а вообще тоже склонен к правилам. если сделано для лучшего определения кто куда ходил. то временно нат в подсеть сделайте для оценки ситуации, а там думать.

конечно пакет цепочку проходит один раз. Но в нат модуле проверка внешних айпи по возврату тоже 500 раз делается. Может ошибаюсь, но легче попробовать чем в исходники опять лезть

 

Делал, какого то тотального результата не было. Условно говоря делал так:

-t nat -A POSTROUTING -s x.x.x.x/16 -o eth0.8 -j SNAT --to-source xx.xx.xx.1-xx.xx.xx.254

 

(кстати наличие влана на высоконагруженном интерфейсе может как то влиять на нагрузку?)

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


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

кстати наличие влана на высоконагруженном интерфейсе может как то влиять на нагрузку?

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

и еще, когда пишите загрузку, загрузка проца 65% понятие растяжимое, одно ядро 2%, другое 90. ну и плюс все от ппс зависит, трафик может быть ни о чем. графики выше показывают зависимость именно ппс. я бы увеличил tcp_establish время, ибо поиск в контреке это намного быстрее чем удаление, а удалив сессию открытую клиент ее переподымет заново, не знаю поможет ли, но чисто мое мнение. Графиков insert-delete никто (в отличии от бсдшников) не выкладывает, а зря.

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


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

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

и еще, когда пишите загрузку, загрузка проца 65% понятие растяжимое, одно ядро 2%, другое 90. ну и плюс все от ппс зависит, трафик может быть ни о чем. графики выше показывают зависимость именно ппс. я бы увеличил tcp_establish время, ибо поиск в контреке это намного быстрее чем удаление, а удалив сессию открытую клиент ее переподымет заново, не знаю поможет ли, но чисто мое мнение. Графиков insert-delete никто (в отличии от бсдшников) не выкладывает, а зря.

 

 

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

значение established я догнал до 600

 

Вот про insert-delete можно ткнуть носом что это и куда посмотреть...

 

Кстати вот что забыл упомянуть совсем так это наличие quagga+bgp с кошками. На серере порядка 5к маршрутов (формата хост такой то шлюз до него такой то) кошек таких три.

BGP нужно что бы роутер знал на каком брасе абонент и вернул трафик на нужный брас.

 

 

Кол-во пакетов в секунду 280к 290к в пиках 300к (при этом загрузка до 65-70%) взлетает.

Кстати, в сервере стоит второй проц еще. Но прерывания утащил все на один процессор, я думаю это влиять не может, но кто его знает (может влияет?)

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

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


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

в стейтфул фаерах есть понятие поиск, вставка, удаление сессии. Так доссы и ложат наты, отправляя много новых конектов. На линуксе не видел чтобы это анализировали, фрибсдшники всегда эти данные прикладывают, к примеру графики строить можно отсюда cat /proc/net/stat/nf_conntrack.

Но не суть, раз никто этого не пишет, значит никто и не анализировал. Не помню в какой версии линукса выпилили роуте кэш, может это и есть проблема большого количества маршрутов.

Я бы подумал как уйти от бгп. К примеру у наших натов два машрута, остальное делает маршрутизатор + немного pbr. конечно все зависит от индивидуальности конфигурации.

Процессоры вещь вообще мутная. распайка влияет на производительность факт, но куча процессоров больше сделает чем куча в 2 раза меньше. Сколько не игрался показатели разные. Причем влияет сильно и мать. У меня 2 идентичных сервера lisg. Один лучше на 1 проце (на 2х дропает пакеты, хотя не загружен), второй на двух лучше первого, так что только тестинг.

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


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

Кто может подсказать, softirq: Let ksoftirqd do its job из kernel 4.9 - есть ли от него польза софт роутеру?

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


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

У меня на пролианте 380g6 4.9 нормально не запустилось, вместо 4 ядер увидело одно, и выдало ошибку, что номера процов больше 16. Видел еще пару таких же сообщений о других моделях пролиантов. Вобще последние ядра очень странные, на 4.8 сломали nat --persistent, в 4.9 судя по всему поправили, но сломали еще что-то...

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


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

к слову, никто не пробовал свежие камни от AMD в качестве софтроутеров/брасов/прочих трафикомолотилок? вроде как с латентностью кешей у них все намного лучше, чем у в меру старых интелов:

 

AIDA-cachemem_zpsd4kryafo.png

 

lOFGE.jpg

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


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

Там улучшения видны только на фоне старых же атлонов, на фоне современных(и даже не очень) интелов - все плохо.

Домашний древний i5-2500 с ddr3...

i5-2500.png

+ на скрине райзена - память работает на дикой частота 3600. На "штатных" 2133-2400 цифры будут совсем-совсем другие.

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


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

ну штатно у ддр4 вообще-то 3200 не редкость, а 2133-2400 - это как ддр3 1066-1333 :)

 

а есть возможность протестить этот i5 свежей версией аиды? как-то смущает разница в скорости чтения из кеша на порядок при близкой латентности... думается, алгоритм тестирования сменился немного...

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


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

ну штатно у ддр4 вообще-то 3200 не редкость, а 2133-2400 - это как ддр3 1066-1333 :)

Дык на скрине интела таки ddr4-2133 с дикими таймингами, некорректное сравнение.

думается, алгоритм тестирования сменился немного

cachemem2.png

Цифры изменились, таки разные версии Aida64 сравнивать в лоб нельзя. Но все равно латентность ниже чем у топового райзена.

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


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

Нашел скрин для kaby lake

core-7700-aida64.png

 

P.S. нашел и результаты райзена без экстремального разгона. Тут все грустно.

Про роутеры на АМД и в этом поколении забываем :)

24-amd-ryzen-7-1800x.png

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

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


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

Про роутеры на АМД и в этом поколении забываем :)
1. Райзен — это конструкция а-ля NUMA. Есть два блока (CCX) по четыре ядра, соединённых некой шиной с неизвестными характеристиками (известно что она работает на половинной частоте памяти).

2. Кеш третьего уровня в одном CCX разделён, как минимум на четыре части (а судя по фоточкам, и на восемь). Соответственно, латентность варьируется (АМДшники этого и не скрывают).

3. L3 собран по модели victim cache: данные в L3 вытесняются из L2, соответственно в случае если нужно поместить данные в L2 из L3, место в L2 нужно освободить, вытеснив данные в L3. Минимальной латентности это не способствует.

 

Исходя из вышеперечисленного, все эти тесты меряют среднюю температуру по больнице, и к реальности отношение имеют весьма слабое.

 

Косяки архитектуры кешей компенсируются стоимостью, энергопотреблением и гигантскими объёмами.

 

Но АМДшники — мерзкие свиньи. Они так и не удосужились выложить в открытый доступ руководство по оптимизации. Без него, все эти «тесты» и оценки ничем принципиально отличаются от сообщений агентства ОБС.

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


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

Macil

Все эти особенности не мешают замерить латентность памяти - она в 1.5 раза выше чем у аналогичных интел'ов.

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


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

Я думаю это весьма уместная тема для небольшого самопиара: я недавно допилил набор тулз для мониторинга и тюнинга сетевого стека в Linux.

Для самопальных софтроутеров - самое оно.

Буду рад любому фидбэку :)

 

Описание на русском: https://strizhechenko.github.io/2017/05/31/netutils-linux-1.2.11.html

Исходники: https://github.com/strizhechenko/netutils-linux

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

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


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

Я думаю это весьма уместная тема для небольшого самопиара: я недавно допилил набор тулз для мониторинга и тюнинга сетевого стека в Linux.

Для самопальных софтроутеров - самое оно.

Буду рад любому фидбэку :)

 

Описание на русском: https://strizhechenko.github.io/2017/05/31/netutils-linux-1.2.11.html

Исходники: https://github.com/strizhechenko/netutils-linux

 

[root@border-area2 netutils-linux]# network-top
Traceback (most recent call last):
 File "/usr/bin/network-top", line 7, in <module>
   NetworkTop().run()
 File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/base_top.py", line 76, in run
   self.tick()
 File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/network_top.py", line 39, in tick
   self.current = self.parse()
 File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/network_top.py", line 30, in parse
   return dict((top_name, _top.parse()) for top_name, _top in self.tops.iteritems())
 File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/network_top.py", line 30, in <genexpr>
   return dict((top_name, _top.parse()) for top_name, _top in self.tops.iteritems())
 File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/link_rate.py", line 65, in parse
   return dict((dev, self.__parse_dev__(dev)) for dev in self.options.devices)
 File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/link_rate.py", line 65, in <genexpr>
   return dict((dev, self.__parse_dev__(dev)) for dev in self.options.devices)
 File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/link_rate.py", line 90, in __parse_dev__
   return dict((stat, self.__parse_dev_stat__(dev, stat)) for stat in self.stats)
 File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/link_rate.py", line 90, in <genexpr>
   return dict((stat, self.__parse_dev_stat__(dev, stat)) for stat in self.stats)
 File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/link_rate.py", line 95, in __parse_dev_stat__
   with open('/sys/class/net/{0}/statistics/{1}'.format(dev, stat.filename)) as devfile:
IOError: [Errno 20] Not a directory: '/sys/class/net/bonding_masters/statistics/rx_packets'

В CentOs 6.8 bonding_masters - это файл.

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


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

Не надо трогать настройки сетивого стека! Он и так быстрый. Это вам не OpenBSD, где из сетивого стека надо в буквальном смысле все соки выжымать.

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


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

Не надо трогать настройки сетивого стека! Он и так быстрый. Это вам не OpenBSD, где из сетивого стека надо в буквальном смысле все соки выжымать.

 

Особенно когда он использует одно из 16 ядер с малой частотой всеми сетевыми картами! :)

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


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

В CentOs 6.8 bonding_masters - это файл.

 

Исправлено: https://github.com/strizhechenko/netutils-linux/issues/68

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

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


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

Здравствуйте, друзья!

Я хочу попросить помощи в следующей ситуации!

 

У меня есть сервер:

CPU Intel® Xeon® E5320 @ 1.86GHz 2шт x 4 ядра

Мат. плата Intel S5000PSL

2 встроенных сетевых адаптера Intel 82563EB

Внешние сетевые адаптеры Intel 82541, Intel 82544, HP BCM5706 (2 порта).

 

На маршрутизаторе используется 2 сетевые карты. Одна смотрит в сторону пограничного маршрутизатора, вторая - в сторону клиентов.

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

 

uname -a
Linux localhost 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux
__________________________________________
Intel 82563EB
driver: e1000e
version: 3.2.6-k
firmware-version: 1.0-0

[root@localhost ~]# ethtool -c enp4s0f0
Coalesce parameters for enp4s0f0:
Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 3
rx-frames: 0
rx-usecs-irq: 0
rx-frames-irq: 0

tx-usecs: 0
tx-frames: 0
tx-usecs-irq: 0
tx-frames-irq: 0

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
__________________________________________

Intel 82541, Intel 82544
driver: e1000
version: 7.3.21-k8-NAPI

[root@localhost ~]# ethtool -c enp5s1
Coalesce parameters for enp5s1:
Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 0
rx-frames: 0
rx-usecs-irq: 0
rx-frames-irq: 0

tx-usecs: 0
tx-frames: 0
tx-usecs-irq: 0
tx-frames-irq: 0

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
__________________________________________

HP BCM5706
driver: bnx2
version: 2.2.6
firmware-version: bc 1.9.6

[root@a-gw ndu]# ethtool -c net1
Coalesce parameters for net1:
Adaptive RX: off  TX: off
stats-block-usecs: 999936
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 18
rx-frames: 12
rx-usecs-irq: 18
rx-frames-irq: 2

tx-usecs: 80
tx-frames: 20
tx-usecs-irq: 18
tx-frames-irq: 2

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

 

Я провожу стресс тест на количество пропускаемых пакетов сетевой картой. Входящие пакеты любым сетевым адаптером равномерно распределяются между ядрами при любой нагрузке. Исходящие пакеты равномерно распределяются между ядрами только при нагрузке менее 500 тыс. пакетов/сек. Если нагрузка исходящего трафика превышает порог 500 тыс. пакетов/сек, то одно из ядер забивается на 100%. В этом случае на этой сетевой карте затормаживается обработка пакетов, пока нагрузка не упадет. Сетевые карты проверял в различных комбинациях. Кольцевые буферы выставлял на максимум - результат не меняется. Я еще раз повторю, что ядро забивается в случае отправки пакетов, а не приема.

Я обнаружил, что проблема возникает во всех случаях, кроме случае прохождения пакета пакет-->внешний сетевой адаптер-->OS Linux-->внутренний сетевой адаптер. Однако практически во всех других комбинациях наблюдается эта проблема. Почему почти? Потому-что я не могу досконально утверждать, что все комбинации проверял, ведь сетевая карта HP BCM5706 используется под нагрузкой.

 

Вот пример проблемной ситуации

Every 1.0s: cat /proc/softirqs                                                                                               localhost: Mon Jun 19 13:05:31 2017

                   CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
         HI:          0          1          0          4          0          0          0          0
      TIMER:      18766      17311      21781      36072      18429      14728      14850      17759
     NET_TX:        218       1208        250     114181        720        257        243        511
     NET_RX:    3611784    3595720    3608193    3697658    3542628    3540516    3553108    3531652
      BLOCK:       2318       1691       1652       1881       1995       1583       2107       2025
   IRQ_POLL:          0          0          0          0          0          0          0          0
    TASKLET:       2601       2669       2600       2696       2635       2656       2606       2660
      SCHED:      15465      13632      14378      16157      14260      10967      11437      13048
    HRTIMER:          0          0          0          0          0          0          0          0
        RCU:       9876       9856      15880      17163      10356       8367       8260      12001


Every 1.0s: cat /proc/interrupts| grep enp                                                                                   localhost: Mon Jun 19 13:06:50 2017

25:    2126060    2090503    2151377    2113891    2125791    2150314    2128414    2140061   IO-APIC   1-fasteoi   enp5s1 (Счётчики в момент ступора ядра останавливаются)
26:       6765       6982       6726       6883       6968       6856       6731       6898   PCI-MSI 2097152-edge      enp4s0f0
28:    1251194    1285380    1225995    1262559    1250625    1226919    1248457    1236982   PCI-MSI 2099200-edge      enp4s0f1 (Счётчики в момент ступора ядра останавливаются)


ATOP

PRC | sys    3.01s | user   0.02s  |              |              | #proc    146 |  #trun      2 | #tslpi   134 |              | #tslpu     0  | #zombie    0 | clones    10 |              |               | #exit     10 |									
CPU | sys       1% | user      1%  |              | irq     100% |              |  idle    698% | wait      2% |              |               | steal     0% | guest     0% | curf 1.87GHz |               | curscal   ?% |									
cpu | sys       0% | user      0%  |              | irq     100% |              |  idle      0% | cpu003 w  0% |              |               | steal     0% | guest     0% | curf 1.87GHz |               | curscal   ?% |									
cpu | sys       0% | user      1%  |              | irq       0% |              |  idle     99% | cpu000 w  0% |              |               | steal     0% | guest     0% | curf 1.87GHz |               | curscal   ?% |									
cpu | sys       0% | user      0%  |              | irq       0% |              |  idle    100% | cpu001 w  0% |              |               | steal     0% | guest     0% | curf 1.87GHz |               | curscal   ?% |									
cpu | sys       0% | user      0%  |              | irq       0% |              |  idle     98% | cpu004 w  1% |              |               | steal     0% | guest     0% | curf 1.87GHz |               | curscal   ?% |									
cpu | sys       0% | user      0%  |              | irq       0% |              |  idle    100% | cpu006 w  0% |              |               | steal     0% | guest     0% | curf 1.87GHz |               | curscal   ?% |									
CPL | avg1    0.80 |               | avg5    0.42 | avg15   0.33 |              |               |              | csw      413 |               | intr    1446 |              |              |  numcpu     8 |              |									
MEM | tot     3.9G | free    3.7G  | cache  48.4M | dirty   0.1M | buff   15.4M |  slab   60.0M | slrec  36.0M | shmem   0.6M | shrss   0.0M  | shswp   0.0M | vmbal   0.0M |              |  hptot   0.0M | hpuse   0.0M |									
SWP | tot    16.0G | free   16.0G  |              |              |              |               |              |              |               |              |              | vmcom  38.4M |               | vmlim  17.9G |									
MDD |          md1 | busy      0%  |              | read       0 | write      3 |               | KiB/r      0 | KiB/w      4 | MBr/s    0.0  |              | MBw/s    0.0 | avq     0.00 |               | avio 0.00 ms |									
DSK |          sda | busy      4%  |              | read       0 | write      8 |               | KiB/r      0 | KiB/w      2 | MBr/s    0.0  |              | MBw/s    0.0 | avq     1.10 |               | avio 15.9 ms |									
DSK |          sdb | busy      4%  |              | read       0 | write      8 |               | KiB/r      0 | KiB/w      2 | MBr/s    0.0  |              | MBw/s    0.0 | avq     1.13 |               | avio 15.8 ms |									
NET | transport    | tcpi       4  | tcpo       4 | udpi       0 |              |  udpo       0 | tcpao      0 | tcppo      0 | tcprs      0  | tcpie      0 | tcpor      0 |              |  udpnp      0 | udpie      0 |									
NET | network      | ipi  1053809  |              | ipo  1053800 | ipfrw 1054e3 |               | deliv     12 |              |               |              |              | icmpi      0 |               | icmpo      0 |									
NET | enp4s0f   8% | pcki  526904  | pcko  526887 |              | sp 1000 Mbps |  si   89 Mbps | so   89 Mbps |              | coll       0  | mlti       0 | erri       0 | erro       0 |  drpi       0 | drpo       0 |									
NET | enp5s1    8% | pcki  526912  | pcko  526857 |              | sp 1000 Mbps |  si   84 Mbps | so   84 Mbps |              | coll       0  | mlti       0 | erri       0 | erro       0 |  drpi       0 | drpo       0 |									
NET | enp4s0f   0% | pcki      33  | pcko       4 |              | sp  100 Mbps |  si    7 Kbps | so    5 Kbps |              | coll       0  | mlti       0 | erri       0 | erro       0 |  drpi       0 | drpo       0 |									


Прикреплено вложение вывода htop

 

Вопросы:

Почему ОС Linux в случае отправки пакетов при превышении указанного порога начинает задействовать только одно ядро (есть незначительная загрузка других ядер)? Может достигнута пропускная способность какой-либо шины материнской платы?

Почему в момент перегрузки останавливаются счетчики /proc/interrupts ?

 

Если не сможем разобраться, то есть другой вариант - использовать сервер HP G5 ntel® Xeon® CPU X5260 @ 3.33GHz со встроенными адаптерами BCM5708. На нем этой проблемы нет.

post-96641-082557800 1497945628_thumb.png

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


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

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

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


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

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

у меня уже 600+, будет расти (не провайдер).

 

можно, конечно, перетащить роутинг между сегментами сети на l3-свитч, но мне удобнее, когда всё в одном месте конфигурируется.

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


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

Join the conversation

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

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

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

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

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

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

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