Оновлення до гігабітної мережі - включення Jumbo Frames


21

Я хотів би почати модернізувати свою мережу SOHO до гігабіту (з 10/100) і трохи почув про Jumbo Frames.

Який був би найкращий спосіб впровадити Jumbo Frames в мережу? З того, що я можу сказати, для того, щоб воно працювало належним чином, всі мережеві передачі в мережі повинні підтримувати Jumbo Frames. Це правда?

Якщо у мене є спеціальна передача (наприклад, мережевий принтер), яку не можна оновити до ефірної мережі GB, чи це не дозволить мені включити Jumbo Frames?

Назвіть кілька моментів, що дозволяють створити Jumbo Frames?

Відповіді:


20

По-перше, можливо, найкраще пояснити, що таке ефірна мережа jumbo frame. Ethernet - мережева технологія рівня 2, а її блок даних про протокол (PDU) - це кадр. Для довідки, L3PDU (IP-шар) - це пакет, а L4PDU (tcp / udp) - сегмент.

Кадр Ethernet (є кілька типів Ethernet, але ми можемо узагальнити тут) складається із заголовка (містить, серед іншого, вихідний MAC, MAC призначення, тег VLAN 802.1q та ін.) Дані, або paylod, кадр і контрольна сума CRC, що використовується для перевірки успішної передачі кадру.

Оригінальний Ethernet визначав розмір кадру (об'єм даних у всьому кадрі, включаючи заголовок і контрольну суму), як 1500 байт (або, можливо, 1518, повинні шукати його). Це число знайшло рівновагу між кількістю даних, що надсилаються одночасно, та ймовірністю того, що передача вийде з ладу або зіткнеться, і доведеться повторно передавати. З появою швидких, повних дуплексних локальних мереж люди зрозуміли, що продуктивність може бути покращена за рахунок збільшення розміру кадру Ethernet. Традиційний розмір джамбо-кадрів становить 9000 байт на кадр, хоча це здебільшого умовне.

На твердій, повнодуплексній локальній мережі (або VLAN), в якій всі елементи очікують отримання ефірної мережі jumbo frame, це фактично покращує продуктивність. Проблема з цим сценарієм полягає в тому, якщо ви введете мережевий елемент або кінцевий пристрій, який цього не очікує. У кращому випадку це призведе до погіршення продуктивності, оскільки пакети втрачаються, оскільки приймаючі пристрої очікують лише 1518 байт у кадрі.

Тепер до ваших конкретних питань:

Який був би найкращий спосіб впровадити Jumbo Frames в мережу?

Це суб’єктивне питання. У моєму місці бізнесу ми вирішили застосувати його лише там, де ми знали, що ми маємо під контролем всю змінну, і ми знали, що це допоможе. Для цього ми реалізували його у спеціальній "приватній" версії, до якої лише певні пристрої могли отримувати доступ через свої другі NIC. Зокрема, ми помістили другий NIC наших файлових серверів і серверів додатків у цю нову VLAN, а потім змінили всі посилання на IP-схему, що використовується в цій VLAN. Це дозволяє нам вузько орієнтуватися (ніхто не збирається підключати настільну машину до цієї VLAN) на конкретну область, яку ми знаємо, найбільше піде на користь (найвищі посилання даних щодо використання в нашій інфраструктурі). Це максимально збільшує прибуток, мінімізуючи ризик.

Більш конкретно, на стороні мережі (за допомогою IOS) ми побудували VLAN, присвячені пристроям jumbo frame, потім додали "mtu 9000" до їх визначення vlan. Кожен інтерфейс на комутаторі, який би використовував цю мережу, був поставлений у цю vlan, використовуючи щось на кшталт "комутатор доступу vlan 11". На машинах linux (які eth0 підключені до стандартної мережі та eth1 підключені до мережі jumbo frame), ми додали "MTU = 9000" до / etc / sysconfig / network-skripts / ifcfg-eth1. Оскільки ми ніколи не здійснюємо маршрутизацію цих пакетів (неможливо, щоб щось, що не було безпосередньо пов’язане з VLAN рамкою jumbo, розмовляло з NIC на VLAN рамки jumbo), нам ніколи не довелося турбуватися про конфігурацію маршрутизатора.

З того, що я можу сказати, для того, щоб воно працювало належним чином, всі мережеві передачі в мережі повинні підтримувати Jumbo Frames. Це правда?

Так, досить багато. Усі мережеві "клієнти" (під якими я маю на увазі сервери / настільні ПК / IPKVM / IP-монітори для навколишнього середовища тощо) повинні також говорити про це, або, як було сказано вище, у вас буде багато напівдоступних машин (вони будуть пінг, і будь-які L3 або L4PDU, що становить менше 1500 байтів, матимуть успіх, це означає, що, наприклад, ваш поштовий сервер пінг, і ви зможете передати те, що, ймовірно, буде невеликим тестовим повідомленням. пошта (той, з вкладенням excel, на який висунуто розмір кадру> 1500 байт), він таємниче вийде з ладу).

Якщо у мене є спеціальна передача (наприклад, мережевий принтер), яку не можна оновити до ефірної мережі GB, чи це не дозволить мені включити Jumbo Frames?

Якщо це так, ось що я б робив (якщо припустити мережеву передачу, яка може це впоратися):

  • побудуйте дві VLAN, одну з jumbo frame та одну без
  • призначити всі ваші мережеві пристрої одному або іншому vlan
  • у вашому маршрутизаторі та комутаторах реалізуйте vlan frame jumbo frame та змініть розмір кадру на будь-яких мережевих клієнтах.

Це означає, що у вас більше не буде плоскої топології L2 у вашій мережі. Наприклад, якщо з вашого сервера, що підтримує jumbo-кадр, ви хочете надрукувати на недругому принтері фрейму, пакети доведеться перенаправити (подорожувати через маршрутизатор, кадри переписати на більш звичайний розмір, а потім надіслати на принтер на іншій VLAN). Це означає, що зв'язок між вашим джамбо-кадром та не-джембо-фреймовими машинами буде дещо біднішим, ніж це було раніше, але швидкість передачі даних між усіма пристроями на VLAN-кадрі jumbro буде кращою. Це справді лише виклик судового рішення.

Назвіть кілька моментів, що дозволяють створити Jumbo Frames?

Сподіваємось, висвітлено вище. Удачі!


Це справді так погано? В Інтернеті відкриття MTU шляху визначить, чи може якийсь маршрутизатор вздовж шляху пропустити лише 500 байт і відповідно налаштувати. Чи не повинно це працювати в локальній мережі?
joeforker

1
Він не працюватиме, якщо обидві кінцеві точки знаходяться в одній області зіткнення. Це тому, що відправник не може визначити, увімкнено чи для кадрів, які приймають, увімкнено чи ні. Якщо система прийому не ввімкнула джомбові кадри, пакет буде мовчки скинутий. Оскільки між ними немає маршрутизатора, виявлення MTU контуру також не буде працювати. Я вважаю, що виявлення MTU контуру може не вдатися також, якщо вихідний інтерфейс останнього маршрутизатора ввімкнено перемикання кадрів, а інтерфейс прийому кінцевої точки - ні.
Потік

11

Ви можете прочитати публікацію Джеффа Етвуда на Jumbo Frames.

Основні моменти допису:

  • 20% підвищення продуктивності
  • Щоб великий кадр залишався недоторканим, кожен пристрій, через який він проходить, повинен підтримувати цей розмір кадру
  • Перемикачі, які не підтримують Jumbo Frames, відкинуть їх

5

Ви можете використовувати ping.exe, щоб перевірити максимальний розмір пакетів і порівняти його з вашими налаштуваннями Jumbo Frames.

ping -l 4096 -f server

Відрегулюйте розмір пакетів, який використовується -l, і використовуйте -f, щоб встановити прапор DO_ NOT_FRAGMENT. Коли ви досягнете максимального розміру пакетів, ви отримаєте "Пакет потрібно фрагментарно, але встановити DF".

Це дасть вам вказівку, чи працює Jumbo Frames чи ні.


3

Так, все повинно підтримувати Jumbo Frames - трактуйте це як перемикання між дзвінками маркера та мережею. Єдина відмінність полягає в тому, що деякі пристрої можуть працювати ненадовго або періодично - це також може бути головним болем, якщо ви не стежите за тим, які пристрої ви налаштували у великій мережі (тобто через 2 тижні ви отримаєте проблемний квиток від якогось користувача з принтером, наповненим у задній частині їхньої кабіни, який "тільки зараз" перестав працювати. Те саме стосується будь-яких нових речей - вам потрібно буде встановити процедуру перенастроювання будь-яких нових пристроїв та комп'ютерів з джамбо-кадрами, щоб уникнути викликів підтримки, коли вони не працюють за межі початкового завантаження.


1

У Linux я виявив, що працює так: Якщо ви використовуєте теги vlans, встановіть mtu для базового пристрою (наприклад, eth1) на розмір рамки jumbo. Усі влани, які підтримують рамки jumbo, отримують одне і те ж mtu, влани, які не відповідають оригіналу, найчастіше 1500.

Насправді влани з увімкненими динаміками jumbo та перемиканням зможуть надіслати локальний інтерфейс vlan, навіть якщо mtu на цьому vlan якщо менший, ніж у базового інтерфейсу.

Також на linux командою для тестування є: ping -s 4096 -M do

-s - розмір, -M do каже "не фрагмент". Якщо ви перевищили локальний mtu, ви отримаєте помилку. Якщо перевищити віддалений mtu, ви нічого не отримаєте назад.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.