nokogerra
-
Публикации
4 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем nokogerra
-
-
Тема закрыта. Объяснили что такая схема нормально работать не будет, даже если эту конкретную проблему удастся побороть, в итоге высока вероятность получить множество других.
-
Добрый день.
Спасибо за ответ.
Не совсем понял, что за nf_conntrack_proto_gre, судя по результатами гугла это для ситуации с nat. В моем случае nat нет, интерфейсы 194.135.107.161, *162, *163 в одной подсети, политики netfilter: INPUT, FORWARD - DROP, OUTPUT - ACCEPT. Для ситуации туннель 1 к 1 достаточно правила iptables -A INPUT -i eth0 -p gre -j ACCEPT. Его, собственно, достаточно и в моем случае, но соединения почему-то попадают под правило с определением состояния INVALID.
-
Опубликовано · Изменено пользователем nokogerra · Жалоба на ответ
Доброго времени суток.
debian 7.8
3 машины, (194.135.107.161, 194.135.107.162, 194.135.107.163), между ними построены gre-туннели от каждой к каждой, т.е. по 2 gre интерфейса на каждой. На примере 194.135.107.163:
# The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 allow-hotplug eth0 iface eth0 inet static address 194.135.107.163 netmask 255.255.255.0 network 194.135.107.0 broadcast 194.135.107.255 gateway 194.135.107.238 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 194.135.107.1 auto gre1 iface gre1 inet static address 10.0.2.3 netmask 255.255.255.248 pre-up ip tunnel add gre1 mode gre local 194.135.107.163 remote 194.135.107.161 post-down ip tunnel del gre1 up route add -host 10.0.2.1 dev gre1 up route del -net 10.0.2.0/29 dev gre1 auto gre2 iface gre2 inet static address 10.0.2.3 netmask 255.255.255.248 pre-up ip tunnel add gre2 mode gre local 194.135.107.163 remote 194.135.107.162 post-down ip tunnel del gre2 up route add -host 10.0.2.2 dev gre2 up route del -net 10.0.2.0/29 dev gre2Как видно, адрес одинаковый (10.0.2.3), чтобы это работало, удаляю "connect" маршруты и добавляю индивидуальные. На остальных машинах также. Работает нормально. НО при создании правил netfilter получаю проблему:
если правило
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
поставить до правила
iptables -A INPUT -i eth0 -p gre -j ACCEPT
то трафик дропается, хотя дальше стоит правило:
iptables -A INPUT -i gre1 -j ACCEPT
Если правило с определением состояния INVALID вставить после правила с разрешением gre, то работает нормально. При построении туннеля 1 к 1 такой проблемы нет. Если это поможет - то вот tcpdump с машины 194.135.107.163 при попытке пинговать 10.0.2.1 при том, что правило с определением состояния на первом месте: http://pastebin.com/nfg1P4jH
Мне желательно сохранить одинаковые адреса на gre интерфейсах одной и той же машины (проблема скорее всего в этом).
Ограничить исходящий трафик на VyOS
в Программное обеспечение, биллинг и *unix системы
Опубликовано · Изменено пользователем nokogerra · Жалоба на ответ
Доброго времени суток.
Сразу оговорюсь, я вообще практически ничего не знаю о QoS, поэтому любой совет будет к месту.
Имеется VyOS в качестве пограничного устройства. Интерфейс, куда приходит ISP - eth0, интернет используют 3 сети - 2 LAN и один белый маршрутизируемый пул, арендуемый у оператора связи. Мне нужно ограничить исходящий трафик до 256 Мбит, при этом обе LAN можно ограничить сотней Мбит (суммарно на двоих), белый пул, например 220 Мбит/сек. Приведу крайне упрощенную схему:
Вся адресация вымышленная.
В общем, начал я читать документацию по Brocade Vyatta 5400 как наиболее полную, суть механизмов на VyOS и Vyatta одна. Собрал схему в EVE-NG и понял, что ничего не понял (ну, что-то понял, но недостаточно). Задам пару вопросов, уверен здесь есть компетентные в этом плане специалисты.
1. Как я понял, мне нужна traffic-policy либо Shaper, либо Limiter, но так как Limiter предназначена для входящего трафика, то выбираю Shaper. В правильном направлении смотрю?
2. Верно ли я понял, что при использовании Shaper, все, что выше указанной полосы пропускания будет буферизироваться, а не просто дропаться, и это не приведет к куче ретрансмиссий? Судя по описанию Traffic Limiter'а это именно так:
Я просто не уверен, будет ли при 'traffic-policy shaper' все, что выше полосы, буферизироваться, если политика будет висеть на eth0 в направлении out. Я бы дал ссылку на описание traffic-policy, но не знаю, как вставить ссылку с js, сама документация здесь http://www1.brocade.com/downloads/documents/html_product_manuals/vyatta/vyatta_5400_manual/wwhelp/wwhimpl/js/html/wwhelp.htm, раздел QoS.
3. Чем все-таки отличаются traffic-policy от queue-type? Я так понимаю, я могу использовать политику SFQ, а могу использовать политику Shaper и указать SFQ для каждого класса.
4. Предположим, создал я политику Shaper с bandwidth 100mbit, создал 2 класса, указал для них в качестве match адрес источника; для первого класса bandwidth=60%, ceiling=80%; для второго класса bandwidth=70%, ceiling=90%; для default bandwidth=40%, ceiling=50%. Итого имею 3 типа трафика - 2 класса и default. Для всех указал queue-type SFQ (по умолчанию, как я понял, работает FIFO). Т.е. внутри каждого класса каждому дается какой-то квант времени, и, если не вдаваться в детали работы механизма, то внутри каждого класса "всё по-честному". А между классами как? ведь суммарно они могут потребить 170% от 100mbit.
5. Что такое burst? Ок, вот описание:
А вот, что я видел на форуме ubiquiti (EdgeOS, вроде, та же Vyatta):
Ладно, это какая-то корзина, размер которой участник политики может послать за какой-то промежуток времени. По умолчанию 15 KB. Но за какой промежуток времени, и какой интервал между этими промежутками должен пройти до следующего "бурста"?
P.S. рассчитывал в лабе попробовать после включения политики iperf'ом одновременно померить скорость от LAN1, LAN2 и PUBLIC до some_internet, но одновременно никак, даже если сервер включить как демон (iperf -s -D). Есть какой-нибудь такой iperf, чтобы от нескольких клиентов подключиться к одному серверу одновременно?