|
|
|
Съвети>Мрежа
|
Оптимизация на iptables и tc правила
|
|
|
|
|
|
от Vladsun(19-10-2006)
рейтинг (20)
[ добре ]
[ зле ]
Вариант за отпечатване Оптимизация на iptables и tc правила.
Целта на статията е да покаже начини за подобряване ефективността и работата на рутери, които извършват и трафик контрол върху потребителите. Това е постигнато чрез оптимизиране на правилата използвани в iptables и tc инструментите в рутера. Като допълнително четиво към тази статия е статията на Uvigii "Разпределяне на трафик от два (или повече) интернет доставчика".
1. Предварителна подготовка
Статията НЕ е предназначена за начинаещи в тази област и за тях е наложително да разгледат някои документации:
2. Системни изисквания
Предварително трябва да е инсталиран (пачнат) следния софтуер:
- в ядрото - QoS (htb, sfq);
- iptables;
- iptables - IPMARK;
- tc;
- Perl (за скриптовете използвани в тази статия).
3. Проблемът
Най-често срещания алгоритъм за разпределяне на трафик между потребители е следния:
- разделяне на трафика на входящ и изходящ;
- разделяне на трафика на български и международен чрез подходящо маркиране на пакетите (вж. "Разпределяне на трафик от два (или повече) интернет доставчика");
- разделяне на трафика за всеки потребител чрез повторно маркиране на пакетите за всеки вид трафик;
Освен това обикновено се налага да се прави контрол на достъпа на потребителите - чрез използването на iptables правила в PREROUTING или FORWARD веригите.
Проблемът при повечето от така реализирани алгоритми е значителното натоварване на сървъра поради ниската ефективност на набора от използваните правила в iptables и tc. За по-детайлно обяснение ще покажа примерен набор от правила използвани в iptables. Предполага се, че разделянето на трафика на български и международен, съответно входящ/изходящ вече е направен и са получени следните потребителски дефинирани вериги - BG_IN, BG_OUT, INT_IN, INT_OUT. В тези вериги трябва да се извърши маркирането за всеки потребител, т.е. добавяме по 4 правила на потребител:
Примерен код |
iptables -A BG_OUT -s IP1 -j MARK --set-mark MARK_IP1_BG_OUT
iptables -A INT_IN -d IP1 -j MARK --set-mark MARK_IP1_INT_IN
iptables -A INT_OUT -s IP1 -j MARK --set-mark MARK_IP1_INT_OUT |
Малката ефективност на този метод е породена от линейното (последователното) обхождане на тези правила за всеки пакет. По този начин всеки пакет минава през около 260 правила, при това само в тези вериги! Още по-лошият вариант, при който няма разделян на изходящ/входящ трафик, броят на правилата обходени от всеки пакет е над 510! При този вариант горните правила изглеждат по този начин:
Примерен код |
iptables -A BG -s IP1 -j MARK --set-mark MARK_IP1_BG_OUT
iptables -A INT -d IP1 -j MARK --set-mark MARK_IP1_INT_IN
iptables -A INT -s IP1 -j MARK --set-mark MARK_IP1_INT_OUT |
След маркирането на пакетите е необходимо също така да се създадат tc правилата, които ще определят минималната и максималната скорост за всеки един потребител в зависимост от вида на трафика. Това означава, че за всеки потребител ще имаме по 4 класа, 4 qdisc (б.а. - дайте свестен превод) и 4 филтъра - по 2 за всеки интерфейс. Прякото следствие от този начин на построяване на tc правилата е отново линейното обхождане на tc филтрите. В случая не знам дали при достигане на съответния филтър за маркирания пакет проследяването на пакета в следващите филтри продължава или не. Но дори и в най-добрия случай имаме средностатистически брой на обходените филтри - 1/2 от всички филтри, или 254 филтъра. Това също е свързано с допълнително (при това излишно) натоварване на рутера.
4. Решението
Ще покажа решение (не твърдя, че е единственото или най-доброто), при което проблемът с линейното и излишно обхождане на правила в iptables и съответните филтри в tc е избягнат напълно. Всъщност самото решение е реализирано отдавна, но за съжаление не е добре документирано (да не казвам изобщо). Нека разгледаме man-а на iptables и по-специално IPMARK:
IPMARK
Allows you to mark a received packet basing on its IP address. This can replace many mangle/mark entries with only one,
if you use firewall based classifier.
This target is to be used inside the mangle table, in the PREROUTING, POSTROUTING or FORWARD hooks.
--addr src/dst
Use source or destination IP address.
--and-mask mask
Perform bitwise `and' on the IP address and this mask.
--or-mask mask
Perform bitwise `or' on the IP address and this mask.
The order of IP address bytes is reversed to meet "human order of bytes": 192.168.0.1 is 0xc0a80001. At first the `and'
operation is performed, then `or'.
Examples:
We create a queue for each user, the queue number is adequate to the IP address of the user, e.g.: all packets going
to/from 192.168.5.2 are directed to 1:0502 queue, 192.168.5.12 -> 1:050c etc.
We have one classifier rule:
tc filter add dev eth3 parent 1:0 protocol ip fw
Earlier we had many rules just like below:
iptables -t mangle -A POSTROUTING -o eth3 -d 192.168.5.2 -j MARK --set-mark 0x10502
iptables -t mangle -A POSTROUTING -o eth3 -d 192.168.5.3 -j MARK --set-mark 0x10503
Using IPMARK target we can replace all the mangle/mark rules with only one:
iptables -t mangle -A POSTROUTING -o eth3 -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000
On the routers with hundreds of users there should be significant load decrease (e.g. twice).
Като 'жокер' ви давам и допълнителна информация, която открих в Интернет (случайно):
Something I've only just noticed from a comment in the code - htb can use mark without the need for lots of filters.
You only need one empty filter on the root (maybe you can still nest) like -
tc filter add dev eth0 parent 1:0 protocol ip prio 1 fw
and then if you arrange for your classes to be the same minor numbers as the marks it will behave like using classify.
You need to set the major number of your htb (1 in example above) in the top 16 bits of the mark.
There is also a netfilter pom-ng patch IPMARK that will set marks based on ipaddress.
Andy.
Нека сега преведа на български и малко по-подробно всичко това:
-
IPMARK: маркира пакетите, като за стойността на маркера използва стойността на самото IP;
-
IPMARK: приема като параметри 3 неща - IP-то по което ще маркираме и 2 параметъра за управление на получения MARK;
-
IPMARK: IP-то по което ше маркираме се взима директно от пакета и в зависимост от това дали --addr параметъра е src или dst, се взима съответно src IP-то или dst IP-то;
-
IPMARK: 2-та параметъра за управление на получения MARK реализират побитово И и ИЛИ върху стойността на IP адреса;
Пример: искаме да маркираме всички IP-та от мрежа 192.168.0.0/24, така че маркерът да е последната група от IP-то сумирано с 512. При това положение
AND-маската е 0x00ff - взимаме последните 2 шестнайсетични числа и чрез OR-маска 0x0200 (512 dec.) сумираме с 512. Така получените пакети ще имат следните маркери:
192.168.0.1 - МАРК = 0x201;
192.168.0.2 - МАРК = 0x202;
192.168.0.3 - МАРК = 0x203;
...........
...........
192.168.0.253 - МАРК = 0x2FD;
192.168.0.254 - МАРК = 0x2FE;
Във втората дадена по-горе информация се обяснява, че ако оставим tc филтър без параметри за fw полето, то тогава този филтър действа директно по MARK полето на пакета. Действието на филтъра е следното:
- разделя МАРК полето на 2 част - младша тетрада и старша тетрада;
- младшата тетрада определя minor номера на класа, а старшата - major номера на класа.
Ако за пример вземем пакет маркиран с 0x0001 0005, този пакет се насочва към клас със classid = 1:5.
Нека сега след тези разяснения да получим решение за разпределяне на трафика на една С-клас мрежа (прим. 192.168.0.0):
Примерен код |
iptables -A BG_IN -d 192.168.0.0/24 -j IPMARK --addr=dst --and-mask=0xff --or-mask=0x10100
iptables -A BG_OUT -s 192.168.0.0/24 -j IPMARK --addr=dst --and-mask=0xff --or-mask=0x10200
iptables -A INT_IN -d 192.168.0.0/24 -j IPMARK --addr=dst --and-mask=0xff --or-mask=0x10300
iptables -A INT_OUT -s 192.168.0.0/24 -j IPMARK --addr=dst --and-mask=0xff --or-mask=0x10400 |
Добавяме общите филтри (дефинирането на tc правилата за общия, българския и международния трафик, съответно входящ/изходящ няма да бъде разглеждан в тази статия):
Примерен код |
tc filter add dev eth0 parent 1:0 protocol ip prio 1 fw
tc filter add dev eth1 parent 1:0 protocol ip prio 1 fw |
и един Perl скрипт за добавяне на едно ИП (последните 3 цифри):
ip.add |
($ip, $bgmin, $bgmax, $intmin, $intmax) = @ARGV;
$id = sprintf("%X", $ip + 0x200);
$class_bg_ul = "tc class add dev eth0 parent 1:15 classid 1:0".$id." htb rate ".$bgmin."Kbit ceil ".$bgmax."Kbit prio 5";
$qdisc_bg_ul = "tc qdisc add dev eth0 parent 1:0".$id." handle 0".$id." sfq perturb 10 ";
$id = sprintf("%X", $ip + 0x100);
$class_bg_dl = "tc class add dev eth1 parent 1:10 classid 1:0".$id." htb rate ".$bgmin."Kbit ceil ".$bgmax."Kbit prio 5";
$qdisc_bg_dl = "tc qdisc add dev eth1 parent 1:0".$id." handle ".$id." sfq perturb 10 ";
$id = sprintf("%X", $ip + 0x400);
$class_int_ul = "tc class add dev eth0 parent 1:25 classid 1:0".$id." htb rate ".$intmin."Kbit ceil ".$intmax."Kbit prio 4";
$qdisc_int_ul = "tc qdisc add dev eth0 parent 1:0".$id." handle ".$id." sfq perturb 10 ";
$id = sprintf("%X", $ip + 0x300);
$class_int_dl = "tc class add dev eth1 parent 1:20 classid 1:0".$id." htb rate ".$intmin."Kbit ceil ".$intmax."Kbit prio 4";
$qdisc_int_dl = "tc qdisc add dev eth1 parent 1:0".$id." handle ".$id." sfq perturb 10 ";
`$class_bg_ul`;
`$qdisc_bg_ul`;
`$class_int_ul`;
`$qdisc_int_ul`;
`$class_bg_dl`;
`$qdisc_bg_dl`;
`$class_int_dl`;
`$qdisc_int_dl`; |
По този начин съкратихме 4*254=1016 правила в iptables na 4!, и още 1016 филтъра в tc също на 4!!! :)
5. Допълнителна оптимизация
По-горе беше отбелязано, че често се налага използването на iptables правила за реализирането на контрол върху дсотъпа на потребителите. Най-често реализацията е по следния начин:
Примерен код |
iptables -A FORWARD -s IP1 -j ACCEPT
iptables -A FORWARD -d IP1 -j ACCEPT
....................................
....................................
iptables -A FORWARD -s IPn -j ACCEPT
iptables -A FORWARD -d IPn -j ACCEPT |
Или казано по-друг начин: всички потребители, които имат разрешение за достъп до Интернет изрично се добавят във FORWARD веригата с ACCEPT. На останалите им се отказва достъп заради избраната политика на тази верига - DROP. Отново имаме линейно обхождане на много правила, което обаче изглежда абсолютно наложително. Този път ще приложа друга стратегия - ще трансформирам тези линейно разположени правила в дървовидна структура, чрез последователно разделяна на 2. Така при обхождането на правилата за един пакет ще се реализира двоично търсене, което както се знае е най-ефективното за наредени данни (поправете ме, ако греша). За да се изясня ще покажа нагледно наборът от правила в полученото дърво за входящ български трафик при мрежа 192.168.2.0/24 :
Примерен код |
Първа итерация:
iptables -t filter -N BG_IN_192_168_2_0-255
iptables -t filter -A FORWARD_IN -d 192.168.2.0/24 -j BG_IN_192_168_2_0-255
iptables -t filter -N BG_IN_192_168_2_0-127
iptables -t filter -A BG_IN_192_168_2_0-255 -d 192.168.2.0/25 -j BG_IN_192_168_2_0-127
iptables -t filter -N BG_IN_192_168_2_128-255
iptables -t filter -A BG_IN_192_168_2_0-255 -d 192.168.2.128/25 -j BG_IN_192_168_2_128-255
Втора итерация:
iptables -t filter -N BG_IN_192_168_2_0-255
iptables -t filter -A FORWARD_IN -d 192.168.2.0/24 -j BG_IN_192_168_2_0-255
iptables -t filter -N BG_IN_192_168_2_0-127
iptables -t filter -A BG_IN_192_168_2_0-255 -d 192.168.2.0/25 -j BG_IN_192_168_2_0-127
iptables -t filter -N BG_IN_192_168_2_0-63
iptables -t filter -A BG_IN_192_168_2_0-127 -d 192.168.2.0/26 -j BG_IN_192_168_2_0-63
iptables -t filter -N BG_IN_192_168_2_64-127
iptables -t filter -A BG_IN_192_168_2_0-127 -d 192.168.2.64/26 -j BG_IN_192_168_2_64-127
iptables -t filter -N BG_IN_192_168_2_128-255
iptables -t filter -A BG_IN_192_168_2_0-255 -d 192.168.2.128/25 -j BG_IN_192_168_2_128-255
iptables -t filter -N BG_IN_192_168_2_128-191
iptables -t filter -A BG_IN_192_168_2_128-255 -d 192.168.2.128/26 -j BG_IN_192_168_2_128-191
iptables -t filter -N BG_IN_192_168_2_192-255
iptables -t filter -A BG_IN_192_168_2_128-255 -d 192.168.2.192/26 -j BG_IN_192_168_2_192-255
................... |
и така докато получим интервал съдържащ избрания от нас брой IP-та, които ще бъдат обходени последователно (прим. 2 или 4). По този начин средностатичстическия брой на правилата, които трябва да премине всеки пакет е брой_деления пъти по-малък от иначе необходимия (127).
Тъй като тази задача е доста трудоемка прилагам Perl скрипт (може би не най-добрия) за решаването й:
rc.netsubdiv |
$net = "192.168.2.0";
$table = "filter";
$start_chain = "FORWARD";
$chain = "BG";
$src = 1;
$dst = 1;
$subdiv = 128;
$ipt = "/usr/local/sbin/iptables";
sub divide_net
{
my($net,$maxdiv, $div, $subnet, $prev_chain, $int_min) = @_;
my $subint = 256/$div;
my $ip;
if ($div > $maxdiv)
{
return;
}
$net2 = $net;
$net2 =~ s/\./_/g;
for ($ip=0; $ip<$div and $ip<2 ; $ip++)
{
$min = $ip*$subint+$int_min;
$max = $min + $subint - 1;
print $ipt." -t ".$table." -N "
.$chain."_IN_".$net2."_".$min."-"
.$max."\n";
if ($div > 1)
{
if ($dst == 1)
{
print $ipt." -t ".$table." -A "
.$chain."_IN_".$prev_chain." –d "
.$net.".".$min."/".$subnet." -j "
.$chain."_IN_".$net2."_".$min."-".$max."\n";
}
if ($src == 1)
{
print $ipt." -t ".$table." -A "
.$chain."_OUT_".$prev_chain." -s "
.$net.".".$min."/".$subnet." -j "
.$chain."_OUT_".$net2."_".$min."-".$max."\n\n";
}
}
else
{
if ($dst == 1)
{
print $ipt." -t ".$table." -A ".$start_chain."_IN -d "
.$net.".0/".$subnet." -j ".$chain."_IN_"
.$net2."_".$min."-".$max."\n";
}
if ($src == 1)
{
print $ipt." -t ".$table." -A ".$start_chain."_OUT -s "
.$net.".0/".$subnet." -j ".$chain."_OUT_"
.$net2."_".$min."-".$max."\n\n";
}
}
$prev_chain2 = $net2."_".$min."-".$max;
divide_net($net, $maxdiv, $div*2, $subnet+1, $prev_chain2, $min);
}
}
$net =~ /^((\d+)\.(\d+)\.(\d+))/;
$net = $1;
divide_net($net, $subdiv, 1, 24, '', 0); |
Променливите в началато на скрипта се използват конфигуриране. Естествено за специфични нужди този скрипт ще се наложи да се модифицира. Забележете, че самия скрипт не изпълнява iptables правилата. Необходимо е изходът от този скрипт да се пренасочи към файл и вече от този файл да се изпълнят iptables командите.
След като сме построили дървото е нужно да добавим правилата за контрол на достъпа за всяко IP. Отново на помощ идва Perl:
Примерен код |
sub get_subnet_interval()
{
($ip, $subdiv) = $_;
my $subint = 256/$subdiv;
my $net = $ip;
$net =~ /^((\d+).(\d+).(\d+))/;
$net = $1;
$ip =~ /^(\d+).(\d+).(\d+).(\d+)/;
$ip = $5;
$min = (int($ip/$subint))*$subint;
$max = $min + $subint - 1;
return ($min."-".$max);
} |
Чрез тази функция получавате веригата, в която се намира даденото от Вас IP. Функцията връща стринг, който е от вида ползван в предишния скрипт за генериране на дървото, но без префиксите на веригата. Това е направено с цел по-универсалната употреба на функцията.
Е, това е :)
Очаквам коментари!
<< Делегиране на права чрез /etc/sudoers | Плавно преминаване от една ОС/Дистрибуция на друга >>
|
|
|
|
|
iptables От: gat3way <mrangelov __@__ globul[ точка ]bg> На: 13-03-2006@15:33 GMT+2 Оценка: 1/НеутраленГолемият проблем на iptables идва оттам, че правилата се пазят под формата на свързан списък, който се обхожда всеки път когато се обработва някой пакет, когато правилата станат няколкостотин почва да се усеща.
Едно много хубаво решение на проблема е:
http://www.hipac.org/
Където правилата се организират в дървета, които се обхождат в пъти по-бързо. Виж, за tc ме съмнява да е възможно да се подходи по същия начин...
[Отговори на този коментар]
Към: iptables От: Vladsun На: 13-03-2006@15:55 GMT+2 Оценка: 1/НеутраленИнтересен сайт, наистина.
Ще го разгледам, но още от сега виждам, че няма пълна съвместимост към Iptables. Още не съм разбрал и дали пачовете за iptables ще работят.
По-интересно ми е друго в пост-а ти - казваш, че правилата се пазят в свързaн списък (да разбирам linked list??? ), но за всяка верига нали? Ако е така все пак разделянето на веригите в дърво все пак ще действа. Това и на практика го видях :)
PS: Дай повече информация за hipac - как се държи в реални условия, усложнения и др. такива :). Стана ми интересно :)
Редактиран на: 13-03-2006@22:39
[Отговори на този коментар]
Към: iptables От: SysAdmin На: 13-03-2006@20:12 GMT+2 Оценка: 1/НеутраленПробвали ли сте pf и ако да, сравнете неговите възможности с iptables.
Според мен е доста по-стабилен, издържа на голямо натоварване, много по-защитен е, по-разбираем (кратки и ясни правила) и лесен за обслужване.
[Отговори на този коментар] Към: Към: iptables От: Anonim На: 13-03-2006@21:23 GMT+2 Оценка: 1/НеутраленNe sym expert, nov scripta "rc.netsubdiv" ima bugs. Na pryv pogled se vijda 4e na red 54 ima "else" klauza bez "if" klauza. Na red 73/74 ima edna figurna skoba v pove4e.
[Отговори на този коментар] Към: Към: Към: iptables От: Vladsun На: 13-03-2006@22:32 GMT+2 Оценка: 1/НеутраленДнес си скъсах нервите докато кача статията тука - половината ми код изчезна заради > < символите. От там идва проблема ......
Благодаря за забележката :)
[Отговори на този коментар] Към: Към: iptables От: Vladsun <vsmin< at >mail< dot >bg> На: 13-03-2006@22:46 GMT+2 Оценка: 1/НеутраленСъжалявам, но не съм пробвал никога *BSD система (доколкото разбрах pf е за bsd), така че :) ... някой друг да си каже мнението.
[Отговори на този коментар] Към: Към: Към: iptables От: smelkomar На: 14-03-2006@7:19 GMT+2 Оценка: 1/НеутраленПослушах съвета на един пич от FReeScO БГ-форума ме посъветва да разгледам m0nowall... пак *BSD
[Отговори на този коментар] Към: Към: Към: Към: iptables От: Stanislav Georgiev <s_georgiev (a) abv__dot__bg> На: 14-03-2006@15:57 GMT+2 Оценка: 1/Неутраленpf е филтър, написан от авторите на OpenBSD, след като се сменя лиценза на ipf. Става доста по-мощен и лесен с годините. Не случайно още от 2002 год. (поне, доколкото ми е известно) се мъчат да го портнат за Линукс. Първоначално успяха да го пренесат на NetBSD, после на FreeBSD, отначало без пълната функционалност. Сега pf работи на всички BSD базирани ОС и върши наистина добра работа. В OpenBSD от версия 3.3 нагоре много неща се правят в един единствен конфигурационен файл - pf.conf. Лимитиране на трафик, опашки, всякакви правила, port forwarding и прочие...
[Отговори на този коментар]
ipsets От: Наско <atanas< dot >tsonkov__at__gmail< dot >com> На: 14-03-2006@10:42 GMT+2 Оценка: 1/НеутраленВ Patch-o-matic има още нещо което трябва да
разгледаш ;) - IPSETS
(http://www.netfilter.org/projects/ipset...)
Чрез него можеш с едно правило да прожеряваш
списък IP адреси (както и портове или дори
списък нееднородни мрежи). Принципът му на
работа е хеширането, което е по-ефективно
дори от двоичното търсене (има константна
сложност за разлика от логаритмичната на
търсенето - не че има значение).
Така свеждаш списъка с правила за проверка
BG или INT е адреса до... ами 1. Освен това
свеждаш който се сетиш друг списък до 1
правило :)
Единственият проблем е дали се прилагат
чисто заедно с IPMARK. До колкото помня при
мен ядрото не се компилираше, но това беше
преди 3 месеца. Сега може би всичко ще е
наред.
[Отговори на този коментар]
Към: ipsets От: VladSun На: 14-03-2006@11:47 GMT+2 Оценка: 1/НеутраленМерси много за информацията :))))
Това наистина е много полезно!
Сега почвам да чета ман-а :)
ПС: Ето така се ражда истината - като се съберат много глави :)
[Отговори на този коментар]
Към: Към: ipsets От: Hapkoc <sasoiliev__at__mamul__dot__org> На: 14-03-2006@13:03 GMT+2 Оценка: 1/НеутраленСамо отбелязвам, понеже по-горе беше споменат PF - в него го има същото нещо и се нарича tables. :)
Поздрави
[Отговори на този коментар]
Маршрутизация!!! От: Beco <vlk__at__lcpe __точка__ uni-sofia __точка__ bg> На: 14-03-2006@15:57 GMT+2 Оценка: 1/НеутраленСтатията е написана технически добре. Ще гласувам с "добре" само заради похвалния технически стил на писане. Иначе изобщо не съм съгласен с ефективността на схемата, която се третира, а именно използването на списъци с мрежи, който са регистрирани от български LIR и оттам разпределянето на канли по скорости и достъпност. Според мен тази схема работи частично, а при съвременната динамика на маршрутизация, работи много лошо. За да не кажат разни добри хора, че се заяждам, ще си позволя да обясня някои неща.
Идеята за географско разпределение на адресните пространства е тотална заблуда. Хората са свикнали да имат много ограничена представа за Интернет, като за адресни мрежови пространства на отделни държави, които се свързани помежду си с "тесни" канали. Частен случай на тази заблуда е термина "български трафик", който се отъждествява с високоскоростна връзка между мрежите на българските интернет субекти, притежаващи или не собствени автономни системи. Че това е заблуда е много ясно. За да има висока скорост е нужно да има напречна свързаност с голям капацитет. Такава има само в големите градове и то при добра воля за свързване между доставчиците и често само при свързаност без транзит. Никой обаче не си дава сметка, че в по-малките населени места каналите за свързаност са изключително тесни. Може да се окаже, че максимално достижимата скорост при изтегляне за един клиент на софийски доставчик до мрежа във Варна е много по-ниска от тази до мрежа във Великобритания.
Също така не се обръща достатъчно внимание на понятето "транзит". У повечето администратори витае абсолютно погрешната мисъл, че трафикът в българското интернет пространство има висока скорост без уговорки. Ето ви следната постановка. Локална мрежа, клиентите на която изтеглят големи обеми данни от публични файлови сървъри (примерно www.data.bg). Локалната мрежа от своя страна е клиент на доставчик, който от своя страна е клиент на доставчиците A и B. Доставчик A е директно свързан към автономната система, в която се намира www.data.bg, а доставчик B достига до www.data.bg през доставчик C. И така, ако доставчикът на локалната мрежа изгуби по някакъв начин напречната си свързаност към www.data.bg през A, по стечение на правилата на динамичната маршрутизация ще достъпва www.data.bg през B и оттам през C. Това е класически пример за транзит. За доставчик C, доставчикът на локалната мрежа не е субект на директна доставка (той е в условия на транзит) и тогава C може да наложи политика на ограничение на трафика, за да може да удовлетвори потребностите на своите директно свързани клиенти. Ще се получи така, че свързаността до дадена точка на българското пространство може да се окаже с твърде малък капацитет от гледна точка на локалната мрежа.
Как обаче се прави истинският контрол на трафика? При него няма понятия като "български трафик" и международен канал. Там има просто различни канали, с различни скорости. Забележете, че дори даден доставчик да подава BGP таблицата си на клиентите, те не могат да извършват въз основа на нея качествен контрол на трафика по канали, защото тази таблица може да служи само за управляване на трафика по изходящите от гледна точка на клиента направления. Истината е, че самият доставчик трябва да поставя в отделни BGP "общности" (BGP community) на база скорост на канал префиксите на мрежите. Причисляването на даден префикс към BGP общност на база капацитет на канал е колективна задача. Тази информация няма как по друг начин да бъде известна на клиента и то в динамични условия, освен да дойде с маркер на BGP общност. След това този, който иска да разпредели download направленията по скорости, трябва да направи мрежа от виртуални или не маршрутизиращи машини, които да работят именно на база BGP общност и да класифицират трафика към даден канал с определена скорост за клиент или сумарно за канала.
Всичко други схеми са половинчати, грешни и често опасно наивни (следват скандали за плащания на трафик и т.н).
За жалост у нас доставчиците не за дозрели съвсем за точно такава колаборация с клиентите си и трафикът не се управлява ефективно.
[Отговори на този коментар]
Към: Маршрутизация!!! От: Vladsun На: 14-03-2006@19:31 GMT+2 Оценка: 1/НеутраленЧестно казано и аз съм мислил за описаните от Вас проблеми, г-н Колев, но никога не съм се задълбочавал в тях. Напълно съм съгласен с изложената постановка и възможните ситуации, които описвате.
Също така ми се иска да видя решението, което описвате или поне начините за динамично определяне на "пропускливостта" към отделни префикси на мрежите.
Съжалявам, че може би звучи малко мързеливо, но наистина нямам много време за задълбаване в една твърде непозната за мен територия и бързото ми запознаване поне с базисите ще е добре дошло :)
Все пак си мисля, че всъщност описаният проблем за транзитиране на трафика го има навсякъде по света, но също така навсякъде по света се дават и гарантирани скорости на трафика към всички направления (макар и винаги ми е било смешно как доставчика гарантира нещо, което в общи линии не е в негов конрол ;) ).
Какво решение е приложено тогава?
Мисля си, че всъщност "тесните" места на мрежата се натоварват най-малко поради естествения подбор продиктуван от желанието на потребителя за бърз достъп. И в крайна сметка балансирането на трафика става на чисто психологическа основа :) (как звучи само) и "пропускливостта" се изравнява донякъде.
[Отговори на този коментар]
Към: Към: Маршрутизация!!! От: Beco <vlk (a) lcpe< dot >uni-sofia< dot >bg> На: 14-03-2006@22:11 GMT+2 Оценка: 1/НеутраленТова с гарантираните скорости на трафика към всички направления може да си го сложа в рамка, като виц на годината. И хайде да не си говорим на "господин" и "вие". Много се дразня от такива псевдоофициалности. Тук е технически портал преди всичко, а не сбирка на технически неграмотни адвокатчета от ОРАК.
Момчета, мислете преди да напишете някоя глупост. Никой не може да ви даде гарантирана скорост по направление. Гарантирана скорост може да се даде само по линия от точка A до точка B, ако този дето я дава има пълен контол върху крайните устройства и междинните такива (маршрутизатори, комутатори). Тази гарантирана скорост касае САМО и единствено пакетите, които минават от точка A до точка B бе значение от къде идват и накъде отиват, т.е. няма направление.
Когато един доставчик ви дава 100% гарантиран канал примерно до българското интернет пространство, това е маркетингов блъф. Първо топологично няма как този доставчик да гарантира скоростите до мрежи, които са извън неговата техническа опека, а дори и в своята. Това весеки човек с елекментарни мрежови знания го знае. Понеже сигурно и това няма да може да бъде осмислено, то ще го обясня направо. Доставчик A има сървър AA. Клиент B и клиент C имат напречна свързаност до A. Ако сумарния капацитет на сървъра е 1 Gbps и двата клиента A и B имат договор за 1 Gbps канал до A, то е ясно, че двата клиента не могат да теглят от AA със скорост 1 Gbps и разпределението на скоростта ще е доста неравномерно за всеки клиент.
Тук не отчитаме натоварването на сървърите, на устройствата на комутация и маршрутизация на пакетите, на паразитния трафик, на колидиралите пакети и т.н.
Така, че седнете, помислете и тогава пишете. Изнервящо е човек да чете глупости, наистина. И после търсите уважение и добър тон...
[Отговори на този коментар] Към: Към: Към: Маршрутизация!!! От: Венци На: 15-03-2006@7:49 GMT+2 Оценка: 1/НеутраленЗдравей Весо,
съгласен съм с теб ,че гарантиране на скорости към дестинации не може да има или най-малкото не може да има 100% гаранция на скоростите. Не дочетох статията до край за това няма и да коментирам по нея но схванах идеята която стои зад нея. По интересни ми се сториха коментарите и по точно там където споменаваш как маркировки на трафика ще се предават динамично с помоща на BGP атрибути. Чувал съм за подобни решения наречени QPPB (QoS Plocy Propagation via BGP) в света на Cisco. Това ще рече ,че администратора на рутера който ще предава тази информация в BGP общноста трябва първо да направи необходимите конфигурации (ръчно) на неговата си машина. Също така един маршрут за различните доставчици може да има различна пропусквателна способност и от там различни трафик политика трябва да се асоцира с него. Това от своя страна вече предполага че всеки доставчик трябва да си направи тези ръчни конфигурации и при смяна на доставчика или други драстични промени в мрежата да ходи и да ги променя на ръка , което на мен ми прилича на момента с "статичното рутиране срещу динамичното ".
Надявам се да не съм те разбрал погрешно. Ако имаш време и желание ще те помоля да обясниш точно какво си имал в предвид когато обясняваше как точно се прави контрол на трафика.
Венци.
[Отговори на този коментар] Към: Към: Към: Маршрутизация!!! От: Vladsun На: 15-03-2006@8:15 GMT+2 Оценка: 1/НеутраленВ:
"... Все пак си мисля, че всъщност описаният проблем за транзитиране на трафика го има навсякъде по света, но също така навсякъде по света се дават и гарантирани скорости на трафика към всички направления (макар и винаги ми е било смешно как доставчика гарантира нещо, което в общи линии не е в негов конрол ;) ). ..."
В.К.:
"... Това с гарантираните скорости на трафика към всички направления може да си го сложа в рамка, като виц на годината. ..."
"... Никой не може да ви даде гарантирана скорост по направление. ..."
"... Когато един доставчик ви дава 100% гарантиран канал примерно до българското интернет пространство, това е маркетингов блъф. Първо топологично няма как този доставчик да гарантира скоростите до мрежи, които са извън неговата техническа опека, а дори и в своята. ..."
Явно не сте ме разбрали, защото и двамата казваме АБСОЛЮТНО едно и също нещо :)
Редактиран на: 15-03-2006@8:16
[Отговори на този коментар] Към: Към: Към: Към: Маршрутизация!!! От: Beco <vlk< at >lcpe __точка__ uni-sofia __точка__ bg> На: 15-03-2006@8:30 GMT+2 Оценка: 1/НеутраленАз лично щях да цитирам решението налично в JuniOS на Juniper. Преди малко Петър Щинков <shtinkov_at_spnet.net> ми даде много по-точна връзка към технологията:
http://www.juniper.net/techpubs/softwar...
Подобно нещо има и в Nortel маршрутизаторите, но там документацията е малко разпиляна и ще ми отнеме време, докато събера хипервръзките.
Иначе решенията на Cisco винаги са ме учудвали с ТНТМ насочеността си и голямото желание на собственичество върху тях, което никога не е било за добро.
Извинения на VladSun, че не съм схванал написаното в коментара от него.
[Отговори на този коментар] Към: Към: Към: Към: Към: Маршрутизация!!! От: Stanislav Georgiev <s_georgiev__at__abv< dot >bg> На: 15-03-2006@10:15 GMT+2 Оценка: 1/НеутраленMного задълбахте по материя, която никога няма как да получи точно разрешение на проблемите. От много философстване няма смисъл.
[Отговори на този коментар] Към: Към: Към: Към: Към: Към: Маршрутизация!!! От: Beco <vlk (a) lcpe__dot__uni-sofia__dot__bg> На: 15-03-2006@12:09 GMT+2 Оценка: 1/НеутраленКакво се обаждаш като недоволна червена бабичка? Може ли да бъда информиран както точно сме казали, което е философстване? Може би описанието на схемата беше философстване, може би точното позоваване на това как се прави решение от този тип е философстване?
Аман от кибици с епизодични включвания с поучителни мнения и e-идиоти.
[Отговори на този коментар]
Финансов аспект на проблема От: Александър Цанков На: 15-03-2006@10:41 GMT+2 Оценка: 1/НеутраленЗдравейте!
С риск да стартирам нов флейм тук, бих искал да посоча, че проблемът с раделянето по скорости на т.нар. Peering и International достъп до Интернет има и чисто финансов аспект. При условие, че сте да кажем малък (квартален) доставчик на Интернет услуги, който купува трафик от по-голям такъв доставчик, неминуемо ще трябва да се съобразявате с неговите представи за разделяне на трафика на български и международен (колкото и трагичен да е факта, че съществува такова разделение). В този случай може би е най-добре да получавате трафика от него маркиран по някаъв критерий и да го разделяте на БГ и международен съответно по този критерий. Дали разделението съответства строго на реалното географско разпределение на мрежите в случая е по-маловажно, защото в края на месеца трябва да се плаща трафика. Е, в случай на фрапиращи несъответствия, всеки е в правото си да се жалва и да иска коригиране на разпределението.
Така стои, обаче въпроса с download трафика. Що се касае до upload-а, там въпроса е открит и решението е или получаване на информация за BG и останалите мрежи по BGP, или не дотам удачното, но все пак някакво решение с перодичното изтегляне на файл с BG мрежите и разделяне според информацията в него.
Best wishes!
Alex
[Отговори на този коментар] hmzz От: a3 На: 17-04-2006@14:47 GMT+2 Оценка: 1/Неутраленtc-to ima neshto narecheno hashing tablici , kakvo smqtate za tqh ?
[Отговори на този коментар]
Към: hmzz От: Vladsun На: 18-04-2006@10:55 GMT+2 Оценка: 1/НеутраленРазглеждал съм ги, но има един съществен проблем - т.к. филтрирането е по ИП, то при ползването на NAT няма как да направиш трафик контрол на upload-a (tc-то действа след POSTROUTING).
Второ, не ми е много ясно как ще се разделя по тип трафик, ако се налага. Пробвал съм parent class-a да действа по MARK, а листата по ИП, ама нещо не се получи.
[Отговори на този коментар]
Нещо не ми е ясно как ще станат 4 правила? От: vanka <filipov__at__bol__dot__bg> На: 22-01-2007@23:12 GMT+2 Оценка: 1/НеутраленНещо не ми стана ясно как след като маркирам с IPMARK пакетите , мога да се отърва от многото правила за филтри, класове и qdisc-ове които по принцип са по 4 за IP. До колкото видях може би мога да се махнат само филтрите, но тогава пак остават достатъчно от класове и qdisc-ове и не виждам как могат да се направят на 4 за една мрежа от клас C (256 адреса) ?Някой дали може да каже как се прави ?
[Отговори на този коментар]
|
|
|
|
|
|
|
|