Mikrotik с нуля. 04 Коммутация
Ранее уже обсуждалось, что RouterBOARD может в себя включать встроенный коммутатор.
В данной схеме устройство в себе объединяет два чипа коммутации: гигабитный и 100мбитный.
Любой порт данного устройства можно либо объединить в логически единый коммутатор, либо порт может работать отдельно, на 3-м уровне.
Нужно понимать что сам по себе чип коммутации способен коммутировать без участия процессора, при этом существуют разные чипы коммутации, которые могут быть включены в состав RouterBOARD.
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features
Выше приведена диаграмма RB2011, в составе которого входят два чипа: Atheros8327 (ether1-ether5+sfp1); Atheros8227 (ether6-ether10)
Возможности данных чипов приведена ниже:
hAP ac lite (RB952Ui-5ac2nD)
hAP ac lite имеет на борту чип Atheros8227 (ether1-ether5)
На уровне switch мы можем управлять элементами:
— switch
— port
— port-isolation
— host
— vlan
— rule
При этом при попытке создать rule, мы получим ошибку, поскольку данный switch не поддерживает rule.
Объединение портов
Здесь стоит упомянуть, что до версии 6.41 в коммутации было понятие master-port.
После версии 6.41 все объединения портов выполняются через bridge.
Поэтому не рекомендуется даунгрейдить на версию ниже 6.41
Далее весь материал будет применяться к версии 6.41 и старше.
Итак, принадлежность портов к тому или иному свитчу или чипу можно определить командами:
interface ethernet print
interface ethernet switch port print
Как видно, в данной модели RouterBOARD все порты «живут» на одном чипе switch1.
Например, hAP ac lite имеет на борту чип Atheros8227 (ether1-ether5). И при включении функции Bridge VLAN Filtering, Hardware Offload будет невозможна, т.к. данный чип не поддерживает эту функцию. Hardware Offload будет автоматически отключена и в обработке коммутации Bridge будет участвовать CPU.
Fast Path
Настройка Bridge
Как видно, мы добавили все три порта в Bridge. Теперь все IP адреса должны «жить» на интерфейсе Bridge.
DHCP также должен быть привязан к интерфейсу Bridge
interface bridge port print
Если добавить в созданный Bridge интерфейсы wifi:
interface bridge port print
Как видно, на интерфейсах wlan отсутствует Hardware Offload. Это из-за того, что интерфейсы wlan «не живут» на чипе switch
Коммутация в Mikrotik — Bridge и Master-port
В RouterOS есть два способа коммутации портов.
Коммутация портов MikroTik через Switch (Master Port)
В этом случае коммутация производится через чип свитча, в обход центрального процессора маршрутизатора. Обычно в SOHO маршрутизаторах Mikrotik используется одна свитч-группа на 5 портов, если портов больше — две свитч-группы. В устройствах Cloud Router Switch чипы коммутации на больше портов и имеют больше возможностей, подробней на них мы останавливаться в этой статье не будем.
Настроить коммутацию можно в разделе General каждого порта, просто выбрав в пункте Master Port. Это главный порт, через который будет происходить коммутация. Коммутация позволяет достичь проводной скорости обмена данными между портами одной группы, как между портами в обычном Ethernet-коммутаторе. Основной (master) порт будет являться портом, через который RouterOS будет сообщаться со всеми остальными портами данной группы. Интерфейсы, для которых задан master-порт, становятся неактивны – не учитывается поступивший и отправленный трафик. Фактически, как будто мы объединили порты физическим, «тупым» коммутатором (свитчем). В роутерах Mikrotik применяются следующие чипы коммутации:
Возможности чипов коммутации:
| Возможности | Atheros 8316 | Atheros 8327 | Atheros 7240 | ICPlus 175D | Другие |
|---|---|---|---|---|---|
| Коммутация портов | да | да | да | да | да |
| Зеркалирование портов | да | да | да | да | нет |
| Таблица MAC-адресов | 2000 записей | 2000 записей | 2000 записей | нет | нет |
| Vlan-таблица | 4096 записей | 4096 записей | 16 записей | нет | нет |
| Таблица правил | 32 правила | 92 правила | нет | нет | нет |
* Порт ether1 на RB450G имеет особенность, которая позволяет ему быть исключённым/добавленным из/в коммутируемой(ую) группы(у) по умолчанию. По умолчанию порт ether1 будет включён в группу коммутации. Данная конфигурация может быть изменена с помощью команды
«/interface ethernet switch set switch1 switch-all-ports=no».
switch-all-ports=yes/no:
«yes» означает, что порт ether1 является портом коммутатора и поддерживает создание групп коммутации и все остальные расширенные возможности чипа Atheros8316, включая расширенную статистику (/interface ethernet print stats).
«no» означает, что порт ether1 не является частью коммутатора, что, фактически, делает его самостоятельным Ethernet-портом – это способ увеличения пропускной способности между ним и другими портами в режимах сетевого моста и маршрутизации, но в то же время исключает возможность коммутации на этом порту. Коммутация через Switch является самой быстрой и производительной в маршрутизаторе, в тоже время имеет наименьшее количество возможностей. При этом:
Итого, можно выделить несколько особенностей такого метода:
Коммутация в MikroTik через Bridge-interface
Порты объединяются не напрямую, а программно, используя ресурсы центрального процессора маршрутизатора. К портам могут быть применены фильтры брандмауэра. Такое объединение так-же влияет на прохождение пакетов по упрощенной схеме (Fastpath). Если взять в пример 2011-серию маршрутизаторов, то ether1-ether5 объеденены в switch1 (Atheros 8327) а ether6-ether10 в switch2 (Atheros 8227), вы можете использовать только Bridge для объединения их в одно целое. Особенность данного метода:
Коммутация позволяет достичь проводной скорости (wire speed) обмена данными между портами одной группы, как между портами в обычном Ethernet-коммутаторе.
Пока пакет не достиг cpu-порта, его обработка полностью осуществляется логикой коммутатора, не требуя какого-либо участия центрального процессора, и эта обработка происходит с проводной скоростью при любом размере кадра.
Пропала опция Master-port и поле Switch
Не пугайтесь, это нормально, если прошивка вашего роутера 6.41 и выше. Теперь вся информация, которая передается на втором уровне модели OSI, будет передаваться через Bridge. Использование swich-чипа (hw-offload) будет автоматически активировано автоматически в случае такой возможности. По умолчанию при добавлении любого интерфейса в Bridge у него будет активирована опция «Hardware Offload», которая будет передавать всю информацию 2-го уровня через switch-чип. Если эту опцию убрать, то обработка будет осуществляться силами операционной системы.
При обновлении на RouterOS 6.41 и выше с RouterOS версий 6.40.5 и ниже все настройки master-port будут автоматически перенесены в Bridge-интерфейс. Если произвести downgrade до версии, которая поддерживает master-port, то настройки не будут возвращены на место. Настоятельно рекомендуется сделать резервную копию до обновления.
До обновления до RouterOS 6.41:
/interface ethernet set [ find default-name=ether1 ] name=ether1-WAN1 set [ find default-name=ether5 ] name=ether5-LAN1-master set [ find default-name=ether2 ] master-port=ether5-LAN1-master name=ether2-LAN1 set [ find default-name=ether3 ] master-port=ether5-LAN1-master name=ether3-LAN1 set [ find default-name=ether4 ] master-port=ether5-LAN1-master name=ether4-LAN1 /ip address add address=10.10.10.1/24 interface=ether1-WAN1 network=10.10.10.0 add address=192.168.0.1/24 interface=ether5-LAN1-master network=192.168.0.0 /ip firewall nat add action=masquerade chain=srcnat out-interface=ether1-WAN1
После обновления на RouterOS 6.41 и старше:
/interface bridge add admin-mac=6C:3B:6B:4A:80:3D auto-mac=no comment=»created from master port» name=bridge1 protocol-mode=none /interface ethernet set [ find default-name=ether1 ] name=ether1-WAN1 set [ find default-name=ether2 ] name=ether2-LAN1 set [ find default-name=ether3 ] name=ether3-LAN1 set [ find default-name=ether4 ] name=ether4-LAN1 set [ find default-name=ether5 ] name=ether5-LAN1-master /interface bridge port add bridge=bridge1 interface=ether2-LAN1 add bridge=bridge1 interface=ether3-LAN1 add bridge=bridge1 interface=ether4-LAN1 add bridge=bridge1 interface=ether5-LAN1-master /ip neighbor discovery-settings set discover-interface-list=!dynamic /ip address add address=10.10.10.1/24 interface=ether1-WAN1 network=10.10.10.0 add address=192.168.0.1/24 interface=bridge1 network=192.168.0.0 /ip firewall nat add action=masquerade chain=srcnat out-interface=ether1-WAN1
L3 Hardware Offloading
hanging VLAN setti
Introduction
Layer 3 Hardware Offloading (L3HW, otherwise known as IP switching or HW routing) allows to offload some router features onto the switch chip. This allows reaching wire speeds when routing packets, which simply would not be possible with the CPU.
Switch Configuration
To enable Layer 3 Hardware Offloading, set l3-hw-offloading=yes for the switch:
Switch Port Configuration
Layer 3 Hardware Offloading can be configured for each physical switch port. For example:
Note that l3hw settings for switch and ports are different:
To enable full hardware routing, enable l3hw on all switch ports:
To make all packets go through the CPU first, and offload only the Fasttrack connections, disable l3hw on all ports but keep it enabled on the switch chip itself:
The next example enables hardware routing on all ports but the upstream port (sfp-sfpplus16). Packets going to/from sfp-sfpplus16 will enter the CPU and, therefore, subject to Firewall/NAT processing.
The existing connections may be unaffected by the l3-hw-offloading setting change.
Interface Lists
It is impossible to use interface lists directly to control l3-hw-offloading because an interface list may contain virtual interfaces (such as VLAN) while the l3-hw-offloading setting must be applied to physical switch ports only. For example, if there are two VLAN interfaces (vlan20 and vlan30) running on the same switch port (trunk port), it is impossible to enable hardware routing on vlan20 but keep it disabled on vlan30.
However, an interface list may be used as a port selector. The following example demonstrates how to enable hardware routing on LAN ports (ports that belong to the «LAN» interface list) and disable it on WAN ports:
Please take into account that since interface lists are not used directly in the hardware routing control, modifying the interface list also does not automatically reflect into l3hw changes. For instance, adding a switch port to the «LAN» interface list does not automatically enable l3-hw-offloading on that. The user has to rerun the above script to apply the changes.
The hardware supports up to 8 MTU profiles, meaning that the user can set up to 8 different MTU values for interfaces: the default 1500 + seven custom ones.
Layer 2 Dependency
Layer 3 hardware processing lies on top of Layer 2 hardware processing. Therefore, L3HW offloading requires L2HW offloading on the underlying interfaces. The latter is enabled by default, but there are some exceptions. For example, CRS3xx devices support only one hardware bridge. If there are multiple bridges, others are processed by the CPU and are not subject to L3HW.
Another example is ACL rules. If a rule redirects traffic to the CPU for software processing, then hardware routing (L3HW) is not triggered:
To make sure that Layer 3 is in sync with Layer 2 on both the software and hardware sides, we recommend disabling L3HW while configuring Layer 2 features. The recommendation applies to the following configuration:
In short, disable l3-hw-offloading while making changes under /interface/bridge/ and /interface/vlan/ :
Inter-VLAN Routing
Since L3HW depends on L2HW, and L2HW is the one that does VLAN processing, Inter-VLAN hardware routing requires a hardware bridge underneath. Even if a particular VLAN has only one tagged port member, the latter must be a bridge member. Do not assign a VLAN interface directly on a switch port! Otherwise, L3HW offloading fails and the traffic will get processed by the CPU:
/interface/vlan add interface=ether2 name=vlan20 vlan-id=20
Assign VLAN interface to the bridge instead. This way, VLAN configuration gets offloaded to the hardware, and, with L3HW enabled, the traffic is subject to inter-VLAN hardware routing.
L3HW MAC Address Range Limitation (DX2000/DX3000 series only)
Marvell Prestera DX2000 and DX3000 switch chips have a hardware limitation that allows configuring only the last (least significant) octet of the MAC address for each interface. The other five (most significant) octets are configurated globally and, therefore, must be equal for all interfaces (switch ports, bridge, VLANs). In other words, the MAC addresses must be in the format «XX:XX:XX:XX:XX. «, where:
This requirement applies only to Layer 3 (routing). Layer 2 (bridging) does not use the switch’s ethernet addresses. Moreover, it does not apply to bridge ports because they use the bridge’s MAC address.
The requirement for common five octets applies to:
Route Configuration
Suppressing HW Offload
For example, if we know that majority of traffic flows to the network where servers are located, we can enable offloading only to that specific destination:
Now only the route to 192.168.3.0/24 has H-flag, indicating that it will be the only one eligible to be selected for HW offloading:
H-flag does not indicate that route is actually HW offloaded, it indicates only that route can be selected to be HW offloaded.
Offloading Fasttrack Connections
Firewall filter rules have hw-offload option for Fasttrack, allowing fine-tuning connection offloading. Since the hardware memory for Fasttrack connections is very limited, we can choose what type of connections to offload and, therefore, benefit from near-the-wire-speed traffic. The next example offloads only TCP connections while UDP packets are routed via the CPU and do not occupy HW memory:
Configuration Examples
Inter-VLAN Routing with Upstream Port Behind Firewall/NAT
This example demonstrates how to benefit from near-to-wire-speed inter-VLAN routing while keeping Firewall and NAT running on the upstream port. Moreover, Fasttrack connections to the upstream port get offloaded to hardware as well, boosting the traffic speed close to wire-level. Inter-VLAN traffic is fully routed by the hardware, not entering the CPU/Firewall, and, therefore, not occupying the hardware memory of Fasttrack connections.
We use the CRS317-1G-16S+ model with the following setup:
Setup interface lists for easy access:
Routing requires dedicated VLAN interfaces. For standard L2 VLAN bridging (without inter-VLAN routing), the next step can be omitted.
Configure management and upstream ports, a basic firewall, NAT, and enable hardware offloading of Fasttrack connections:
At this moment, all routing still is performed by the CPU. Enable hardware routing on the switch chip:
L3HW Feature Support
| Feature | Support | Comments | Release |
|---|---|---|---|
| IPv4 Unicast Routing | HW | 7.1 | |
| IPv6 Unicast Routing | CPU | ||
| IPv4 Multicast Routing | CPU | ||
| IPv6 Multicast Routing | CPU | ||
| ECMP | HW | Multipath routing | 7.1 |
| Blackholes | HW | 7.1 | |
| Prohibited routes | CPU | ||
| Unreachable routes | CPU | /ip/route add dst-address=10.0.99.0/24 type=unreachable | |
| gateway= | CPU/HW | 7.1 | |
| BRIDGE | HW | IP Routing from/to bridge interface | 7.1 |
| VLAN | HW | Routing between VLAN interfaces | 7.1 |
| Bonding | HW | 7.1 | |
| Firewall | FW | Users must choose either HW-accelerated routing or firewall. Firewall rules get processed by the CPU. Fasttrack connections get offloaded to HW. | 7.1 |
| NAT | FW | NAT rules applied to the offloaded Fasttrack connections get processed by HW too. | 7.1 |
| VRF | N/A | ||
| VRRP | N/A | ||
| MTU | HW | The hardware supports up to 8 MTU profiles. | 7.1 |
Only the devices listed in the table below support L3 HW Offloading.
L3HW Device Support
Only the devices listed in the table below support L3 HW Offloading.
CRS300: Switch DX8000 and DX4000 Series
The devices below are based on Marvell 98DX8xxx, 98DX4xxx switch chips, or 98DX325x model.
1 Depends on the complexity of the routing table. Whole-byte IP prefixes (/8, /16, /24, etc.) occupy less HW space than others (e.g., /22). When the HW route limit is reached, new route entries are ignored by the switch chip! The user should choose the device with HW capability large enough to store all the routes or/and suppress offloading of the routes that do not fit in the HW memory.
2 When the HW limit of Fasttrack or NAT entries is reached, other connections will fall back to the CPU. MikroTik’s smart connection offload algorithm ensures that the connections with the most traffic are offloaded to the hardware.
3 Fasttrack connections share the same HW memory with ACL rules. Depending on the complexity, one ACL rule may occupy the memory of 3-6 Fasttrack connections.
4 MPLS shares the HW memory with Fasttrack connections. Moreover, enabling MPLS requires the allocation of the entire memory region, which could store up to 768 (0.75K) Fasttrack connections otherwise. The same applies to Bridge Port Extender. However, MPLS and BPE may use the same memory region, so enabling them both doesn’t double the limitation of Fasttrack connections.
5 All NAT entries cannot be used due to the limited amount of Fasttrack connections.
CRS300: Switch DX3000 and DX2000 Series
The devices below are based on Marvell 98DX224S, 98DX226S, or 98DX3236 switch chip model. These devices do not support Fasttrack or NAT connection offloading.
The 98DX3255 and 98DX3257 models are exceptions, which have a feature set of the DX8000 rather than the DX3000 series.
| Model | Release | IPv4 Route Prefixes 1 | Nexthops | ECMP paths per prefix 2 |
|---|---|---|---|---|
| CRS305-1G-4S+ | 7.1 | 13312 | 4K | 8 |
| CRS318-1Fi-15Fr-2S | 7.1 | 13312 | 4K | 8 |
| CRS318-16P-2S+ | 7.1 | 13312 | 4K | 8 |
| CRS326-24G-2S+ | 7.1 | 13312 | 4K | 8 |
| CRS328-24P-4S+ | 7.1 | 13312 | 4K | 8 |
| CRS328-4C-20S-4S+ | 7.1 | 13312 | 4K | 8 |
1 Since the total amount of routes that can be offloaded is limited, prefixes with higher netmask are preferred to be forwarded by hardware (e.g /32 /30 /29, etc.), any other prefixes that do not fit in the HW table will be processed by the CPU.
2 If a route has more paths than the hardware ECMP limit (X), only the first X paths get offloaded.
CCR2000
1 The switch chip has a feature set of the DX8000 series.
Базовая конфигурация MikroTik (CLI) ( Создание простейшей конфигурации для обеспечения работы небольшого офиса с парой десятков пользователей. )
6 января 2015 (обновлено 26 января 2019)
Hard: «MikroTik RB/CCR».
OS: «RouterOS v6».
Задача: создать простейшую конфигурацию маршрутизатора «MikroTik» для обеспечения работы типового небольшого офиса с парой десятков пользователей и двумя-тремя серверами.
Прежде всего, если устройство только что поступило на полное реконфигурирование, есть смысл предварительно зачистить его настройки, и уже после этого приступать к дальнейшим действиям:
Аналогичного эффекта сброса настроек до заводских можно достигнуть следующей последовательностью действий:
Ознакомиться с текущей конфигурацией проще всего посредством команды экспортирования всего набора команд для воссоздания таковой:
Первичные настройки доступа.
Устанавливаем пароль для текущего пользователя «admin»:
Заводим дополнительного пользователя и выдаём ему полномочия суперпользователя:
Выключаем все сервисы управления устройством, кроме SSH, «winbox» и COM-порта:
Активируем повышенный уровень шифрования сеансов SSH и запрещаем транзитные подключения:
Настраиваем сетевое именование.
Задаём символическое сетевое имя (FQDN) устройству:
Задаём набор NS-серверов, к которым следует отправлять DNS-запросы (в примере Google и Yandex):
Разрешаем обслуживание маршрутизатором рекурсивных DNS-запросов от пользователей:
Устанавливаем точное системное время.
Наверняка изначально может потребоваться явно указать желаемый часовой пояс (пример для Новосибирска):
Задаём внешний источник данных для автоматической синхронизации времени:
Сразу по применению новых параметров даты и времени система попытается синхронизировать его с указанными time-серверами.
Позволяем маршрутизатору делиться сведениями о точном времени, активируя NTP-Server:
Об аппаратных чипах и логике коммутации.
Ранее (до «RouterOS v6.41») на большинстве «Mikrotik» в настройках по умолчанию была предустановлена схема из двух уровней коммутации: группа ethernet-интерфейсов собирается в «switch-group» (трафик которой обслуживается только в рамках подключения к физическому чипу коммутации, коих может быть несколько), а порты «switch-group» через произвольный «master-port» (таковым может быть назначен любой из портов группы) вводятся в мостовой виртуальный интерфейс «bridge», коммутирующий (уже на уровне центрального процессора) пакеты «switch-group», автономных ethernet-интерфейсов и беспроводного интерфейса, предоставляя им единое L2 адресное пространство.
Рекомендую сразу разделить по разным группам коммутации проводные и беспроводные интерфейсы (помним, что по умолчанию они сведены в «прозрачный мост») с тем, чтобы иметь возможность подключающихся беспроводных клиентов в любых комбинациях изолировать от работающих в проводной сети пользователей, а порты последней распределить в соответствии с назначением, функционально изолировав их в рамках аппаратных чипов.
Планируем распределение сетевых интерфейсов по задачам.
В дальнейшей настройке будем исходить из потребности в следующих сущностях:
Если устройство начального уровня, то в нём немного физических портов и может статься, что каждый из них будет задействован в своей задаче с индивидуальной сетевой IP-адресацией. Если ethernet-портов больше, чем задач, что часть из них можно свести в группы коммутации, получив в итоге картину вроде нижеследующей:
Конфигурируем локальные сетевые подключения.
Переименовываем сетевые интерфейсы для удобства восприятия их функциональной привязки, в соответствие с вышеприведённой схемой:
Создаём «мостовые интерфейсы», которые будут играть роль виртуальных коммутаторов:
Подключаем к виртуальным «мостовым интерфейсам» соответствующие сетевые физические интерфейсы:
Проверяем, получилось ли задуманное распределение интерфейсов:
Назначаем «мостовым интерфейсам» локальных сетей IP-адреса:
Результат наших действий по назначению IP-адресов:
Конфигурируем беспроводное сетевое подключение.
Создаём выделенный профиль, описывающий метод аутентификации пользователя в беспроводной сети:
Задаём параметры сети, обслуживаемой беспроводным интерфейсом, заодно привязав к нему заранее подготовленный профиль аутентификации:
Задаём IP-адрес беспроводному интерфейсу и включаем таковой:
Настраиваем автоматическую выдачу IP-адресов.
Запускаем DHCP-сервер для обслуживания клиентов локальной сети:
При необходимости фиксируем IP-адрес компьютера пользователя за его аппаратным MAC-адресом:
Запускаем DHCP-сервер для обслуживания клиентов беспроводной сети:
Удостоверяемся, что наши DHCP-серверы активны в заданной конфигурации:
А вот так можно просмотреть список выданных пользователям сетей IP-адресов:
Конфигурируем внешние сетевые подключения.
Задаём внешнему интерфейсу первого (основного) провайдера IP-адрес:
Объявляем маршрут «по умолчанию», отправляющий весь нераспределённый трафик в сеть первого провайдера «ISP1»:
Просматриваем получившуюся таблицу простейшей статической маршрутизации:
Настраиваем трансляцию запросов из локальной сети в интернет.
Так как внутри «MikroTik» живёт «Linux», управление сетевым трафиком и модификация пакетов реализовано через подсистему ядра «netfilter», только вместо обвязки «iptables» здесь оперируют сущностью «firewall».
Для упрощения дальнейшего конфигурирования отношений между подсетями составляем списки таковых:
Задаём правила NAPT/PAT (NAT Overload/Port Address Translation) трансляции локальных сетевых адресов пользователей во внешние, при обращении за сетевые интерфейсы провайдеров:
Проверяем, применились ли правила организации доступа в интернет:
.
1 ;;; NAPT/PAT via WAN1
chain=srcnat action=src-nat to-addresses=123.45.67.90 src-address-list=LIST_INET_USERS_IP out-interface=ether1-WAN1 log=no log-prefix=»»
2 ;;; NAPT/PAT via WAN2
chain=srcnat action=masquerade src-address-list=LIST_INET_USERS_IP out-interface=ether6-WAN2 log=no log-prefix=»»
Настраиваем трансляцию запросов из внешней сети к локальным ресурсам.
Наверняка потребуется обеспечить доступность внутреннего сервиса, спрятанного за «MikroTik», извне.
Добавляем правила DNAT (Destination NAT), разрешающие пропуск трафика снаружи к определённым сервисам и портам:
Более глубокую настройку защитного экрана, как такового рассмотрим в отдельной заметке.
Деактивируем ненужные в простом офисе функциональные модули:
Выключаем сервисы мониторинга (Ping) и управления (Telnet, Winbox), принимающие подключения с указанием MAC-адреса, если IP-адрес интерфейсу не выдан:
Выключаем сервис, предназначенный для приёма подключений с целью тестирования пропускной способности:
Явно выключаем сервисы проксирования клиентских запросов:
[ уже посетило: 6689 / +3 ] [ интересно! / нет ]
Поблагодарить автора 
( сделайте свой денежный вклад в хорошее настроение )
