Нумерація TC класів / фільтрів Linux

Зараз я працюю над рішенням щодо формування трафіку для компаній на рівні провайдерів і зіткнувся з цікавою (філософською) проблемою.

Дивлячись на кількість кінцевих точок, якими повинна працювати система (що становить приблизно ~ 20 кб), я трохи переживав, що буде, коли мені потрібно буде формувати трафік більшої кількості користувачів. Оскільки я зараз використовую дерево формування форми HFSC (див. Tc-hfsc, здебільшого те саме, але більш круте, що і більш відоме HTB) для всієї мережі, мені потрібно використовувати більше ClassID (очевидно, принаймні один для кожного користувача в мережа). Проблема, яку я знайшов, полягала в тому, що TC ClassID є обмеженими - це 16-бітне число, що дає мені максимум 64k користувачів, сформованих цим рішенням.

Так само, якщо я хочу ефективно керувати фільтрами TC (наприклад, не використовуючи "техніку промивання всіх"), мені потрібно мати змогу видалити або змінити окремі записи фільтра. (Я використовую щось подібне до хеш-таблиці від LARTC [1]). Знову ж таки, єдиний метод, який, здається, працює з цим - це нумерація всіх фільтрів за допомогою індивідуальних пріоритетів (tc filter add dev ... prio 1). Немає іншого параметра, який міг би бути використаний для цієї мети, і, на жаль, пріо є також 16-бітовим.

Моє запитання наступне: чи існує якийсь хороший метод розширення доступного "простору ідентифікаторів", наприклад 32-розрядний clsid для команди "tc class" та 32-бітні пріоритети (або будь-які інші ручки модифікації) для "фільтра tc" командувати?

Дуже дякую,

-мк

(btw Я сподіваюся, що це не піде на сценарій "64k користувачів повинно вистачити на всіх").

— екз
джерело

Усі ці значення зберігаються в просторі ядра, щоб збільшити їх, вам потрібно буде перекомпілювати утиліти ядра та користувальницького простору. Ви намагалися використовувати ядро 64 біт? Там вони можуть бути визначені як 32-бітні.

— Хуберт Каріо

64-бітове ядро використовує однакові розміри. Наприклад, число фільтра - це u32-ціле число, яке складається з верхньої (протоколу) і нижньої частини (пріорі), очевидно, 16 біт. Ідентифікатори класу жорстко кодуються як u16. Можливо, я спробую запитати когось у LKML.

— екз

навіть якщо ви використовуєте хеш для ваших фільтрів, у вас виникне багато проблем з IO, якщо ви використовуєте стільки фільтрів (я думаю, для висхідної та нижньої течії). Я витратив багато часу і довелося виправляти виконання черг всередині ядра, щоб речі працювали з ksoftirqd. Я використав патч від хлопця на ім’я Саймон Лодал, якого я познайомився на LARTC 4 роки тому. Погляньте на його патч mail-archive.com/lartc@mailman.ds9a.nl/msg16279.html . Ви можете спробувати надіслати йому електронний лист, оскільки у нього завжди є дуже оновлена версія (щодо останнього ядра).

— Паблуез

@Pabluez Дякую дуже, я постараюся отримати найкраще з цього.

— екз

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

— AndreasM

Відповіді:

Я думаю, що ви не повинні ставити 64k користувачів із верхніми та нижчими класами та фільтрами для кожного з них на одному інтерфейсі. Ви можете повторити обробники для кожного наявного інтерфейсу, тому додайте більше інтерфейсів. Для цього вам знадобиться неймовірна робота / сервер / NIC. Якщо сервер вийде з ладу, у вас буде офлайн 64k користувачів (і він легко вийде з ладу при такій кількості трафіку). Не забувайте, що пакет EACH, який проходить через вашу мережеву карту, перевірятиметься та класифікується фільтром та надсилається до чергового класу. Це багато роботи для NIC-шлюзу провайдера ISP з 64-тисячними клієнтами. В основному з усім відеопотоком, який ми маємо в наші дні (який важко встановити в чергу).

— Pabluez
джерело

Я забезпечую доступність послуг на якомусь іншому рівні, але дякую за турботу. Насправді, з хорошими NIC, не так складно мати маршрутизатор Linux, який може пересилати 10 Гбіт.

— exa

Для оригінального питання мене більше цікавили такі речі, як додавання 5 різних класів для кожного користувача, що дозволило б мені зробити дійсно гарну роботу з QOS (наприклад, обробляти потоки та трафік у режимі реального часу окремо), але це в основному немислимо в сучасних умовах (з моїми поточний випадок використання ~ 20k кінцевих точок, я вже за межі).

— exa

добре, переслати 10Gbits - це не будь-яка проблема, проблема полягає в тому, що багато 64k * 2 (ups downs) фільтрів і класів.

— Вдало

Ви можете розділити обробку трафіку на дві машини (використовуючи третю), а не обробляти весь трафік на одній машині. Трафік може бути спрямований просто на основі IP-адреси джерела. Таким чином, у вас буде оптимально 10 тис. Користувачів, якщо ви зможете розподілити IP-діапазон рівномірно.

Звичайно, за потреби можна використовувати більше двох машин. Я думаю, що це може бути краще, ніж виправлення ядра Linux і робити деякі інші хаки. Коротше кажучи, формування трафіку буде розподілено на декількох машинах. Центральний вузол просто перенаправить трафік до правого вузла обробки.

— Халед
джерело