Подозирам, че напоследък ми се събира прекалено много работа, от което следва и едно порядъчно сдухване. За мен лично няма нищо странно да си променям мнението за това дали да използвам маршрутизатор Cisco или настроен от мен GNU/Linux диаметрално в рамките на един ден.

В очите на колегите ми обаче това може би изглежда не както трябвва. Обикновено аз, макар и бидейки един не твърде актвен зелот, смятам GNU/Linux за по-доброто решение. Всъщност и в момента се вижда, че е така, а финансовото предимство е несъизмеримо. Чисто технологично обаче, ако на някой след мен се наложи да поддържа това решение, ще му се дойде малко възгеч.

Note to myself: PF_RING и FB_TRIE FIB_TRIE вършат нелоша прекрасна работа.

ПС Глупости говоря, разбира се.

По-долу можете да видите скрипт за policy маршрутизиране по source адрес към два шлюза. Познайте какво се случва, когато се изпълни скрипт на GNU/Linux маршрутизатор със само един шлюз.

#! /bin/sh

ip="/sbin/ip"

DTABLE1=101
DTABLE2=102

STABLE="main"

fw1="192.168.100.1"
fw1_nets=" 10.10.128.0/22 \
10.10.132.0/22 \
10.10.136.0/21 \
10.10.156.0/22 \
10.10.188.0/22"

fw2="192.168.100.8"
fw2_nets=" 10.10.144.0/22 \
10.10.148.0/22 \
10.10.152.0/22 \
10.10.185.0/22 \
10.10.186.0/22 \
10.10.187.0/22"
$ip route flush table $DTABLE1
$ip route show table $STABLE | grep -Ev '^default' | grep '10.10' \
| while read ROUTE ; do
$ip route add table $DTABLE1 $ROUTE
done

$ip route flush table $DTABLE2
$ip route show table $STABLE | grep -Ev '^default' | grep '10.10'\
| while read ROUTE ; do
$ip route add table $DTABLE2 $ROUTE
done

# CMTS1,5
$ip route add table $DTABLE1 default via $fw1
for net in $fw1_nets;
do
$ip rule add from $net table $DTABLE1;
done

# CMTS2,3,4
$ip route add table $DTABLE2 default via $fw2;
for net in $fw2_nets;
do
$ip rule add from $net table $DTABLE2;
done

$ip route flush cache

Аз мога да ви отговоря – машината не ще по никакъв начин да препраща пакети от един интерфейс на друг и си пълни логовете със съобщения от вида:

Apr 15 11:33:17 mincho kernel: Neighbour table overflow.
Apr 15 11:33:22 mincho kernel: printk: 8516 messages suppressed.

Като се има предвид, че лично аз съм писал въпросния скрипт (макар и преди повече от 2 години), ми отне около 15 минути, докато разбера какво става, и, което е по-важното, да го оправя.

След като мина близо година време, най-после успях да си поиграя с hfsc (Hierarchical Fair Service Curve) и да постигна сравнително добри резултати, поне в два от офисите (единия е в моя мрежов сегмент, а другия е зад DOCSIS кабелен модем). Това се случи, след като прочетох едно писмо от Patrick McHardy, в което той пише:

        I forgot to mention, there is actually a quite easy way to get
        started with HFSC if you already have a working HTB setup. Just
        delete the "prio" statements, replace "htb" by "hfsc",
        "rate" by "sc rate", "ceil" by "ul rate" and delete all the
        remaining htb specific parameters and you have something working.

Малко по-нататък в кореспонденцията се допълва, че:

        One thing to note is that HFSC will drop, rather than pass unshaped,
        traffic that is unclassified.
        So if you don't use a default class and don't filter arp to a class then
        HFSC will appear broken whereas HTB will work.

Има и други интересни неща, които вероятно ще опитам да опиша някой ден, за да не ми се налага да ги помня. Същинското ми трафик контрол решение обаче, което гарантира капацитети за няколко хиляди клиента и поема трафик от порядъка на 150Мбита в пикови моменти, все още използва htb.

Ако някой се интересува, тук има превод на част от ALTQ документацията, по-специално в частта си за HFSC.