Я хотел бы начать модернизацию моей сети SOHO до гигабитной (с 10/100) и услышал немного о Jumbo Frames.
Как лучше всего реализовать Jumbo Frames в сети? Из того, что я могу сказать, чтобы он работал правильно, все сетевые устройства в сети должны поддерживать Jumbo Frames. Это правда?
Если у меня есть конкретное устройство (например, сетевой принтер), которое не может быть обновлено до ГБ Ethernet, это помешает мне включить Jumbo Frames?
Каковы некоторые особенности включения Jumbo Frames?
Ответы:
Во-первых, лучше всего объяснить, что такое jumbo frame ethernet. Ethernet - это сетевая технология уровня 2, а его блок протокольных данных (PDU) - это фрейм. Для справки, L3PDU (уровень IP) является пакетом, а L4PDU (tcp / udp) является сегментом.
Фрейм Ethernet (есть несколько типов Ethernet, но мы можем обобщить его здесь) состоит из заголовка (содержащего, помимо прочего, MAC-адрес источника, MAC-адрес назначения, тег VLAN 802.1q и т. Д.), Или данные о выплате, кадр и контрольная сумма CRC, используемая для проверки успешной передачи кадра.
Исходная сеть Ethernet указала размер кадра (значение данных во всем кадре, включая заголовок и контрольную сумму) как 1500 байт (или, возможно, 1518, должны искать его). Это число достигло баланса между количеством данных для одновременной отправки и вероятностью сбоя или коллизии при передаче и необходимости повторной передачи. С появлением быстрых полнодуплексных локальных сетей люди поняли, что производительность можно улучшить, увеличив размер кадра Ethernet. Традиционный размер больших кадров составляет 9000 байт на кадр, хотя это в основном соглашение.
В надежной, полнодуплексной локальной сети (или VLAN), в которой все элементы ожидают приема Ethernet с большим количеством кадров, это фактически повышает производительность. Проблема в этом сценарии заключается в том, что вы вводите сетевой элемент или конечное устройство, которое этого не ожидает. В лучшем случае это приведет к снижению производительности, поскольку пакеты теряются, поскольку приемные устройства ожидают только 1518 байтов в кадре.
Теперь к вашим конкретным вопросам:
Как лучше всего реализовать Jumbo Frames в сети?
Это субъективный вопрос. В моем офисе мы решили реализовать его только тогда, когда знали, что все переменные находятся под контролем, и мы знали, что это поможет. Для этого мы реализовали его в специальном «закрытом» vlan, к которому только определенные устройства могли получить доступ через свои вторые NIC. В частности, мы поместили второй сетевой адаптер наших файловых серверов и серверов приложений в эту новую VLAN, а затем изменили все ссылки на схему IP, используемую в этой VLAN. Это позволяет нам узко ориентировать (никто не собирается подключать настольный компьютер к этой VLAN) конкретную область, которая, как мы знаем, принесет наибольшую пользу (каналы передачи данных с наибольшим использованием в нашей инфраструктуре). Это максимизирует прибыль при минимизации риска.
Точнее говоря, на стороне сети (с использованием IOS) мы создали VLAN, выделенные для устройств Jumbo Frame, а затем добавили «mtu 9000» к их определению vlan. Каждый интерфейс коммутатора, который будет использовать эту сеть, был помещен в этот vlan с использованием чего-то вроде «switchport access vlan 11». На машинах linux (у которых eth0 подключен к стандартной сети, а eth1 подключен к сети Jumbo Frame), мы добавили «MTU = 9000» в / etc / sysconfig / network-scripts / ifcfg-eth1. Поскольку мы никогда не маршрутизируем эти пакеты (невозможно, чтобы все, что не было напрямую подключено к VLAN с большим количеством кадров, говорило с NIC на VLAN с большим количеством кадров), нам никогда не приходилось беспокоиться о конфигурации маршрутизатора.
Из того, что я могу сказать, чтобы он работал правильно, все сетевые устройства в сети должны поддерживать Jumbo Frames. Это правда?
Да, в значительной степени. Все сетевые «клиенты» (под которыми я подразумеваю серверы / рабочие столы / IPKVMs / IP-мониторы среды и т. Д.) Также должны говорить на этом языке, или, как уже упоминалось выше, у вас будет много полу-доступных машин (они будут пинговать и любые L3 или L4PDU, которые меньше 1500 байт, будут успешными, что означает, что, например, ваш почтовый сервер будет пинговать, и вы сможете вручную доставить то, что, вероятно, будет небольшим тестовым сообщением. Но когда вы попытаетесь доставить реальное mail (та, что с вложением Excel, которое выдвигает размер кадра> 1500 байт), таинственным образом потерпит неудачу).
Если у меня есть конкретное устройство (например, сетевой принтер), которое не может быть обновлено до ГБ Ethernet, это помешает мне включить Jumbo Frames?
Если это так, вот что я бы сделал (если предположить, что сетевое оборудование может с этим справиться):
Это означает, что у вас больше не будет плоской топологии L2 в вашей сети. Например, если с вашего сервера с поддержкой jumbo-frame вы хотите печатать на свой не-jumbo frame принтер, пакеты должны будут маршрутизироваться (проходить через маршрутизатор, кадры переписываются в более обычный размер, а затем отправляются на принтер на другой VLAN). Это означает, что связь между вашим jumbo frame и машинами, не поддерживающими jumbo frame, будет несколько хуже, чем была раньше, но скорость передачи данных между всеми устройствами в VLAN jumbro frame будет лучше. Это на самом деле просто вызов.
Каковы некоторые особенности включения Jumbo Frames?
Надеюсь, что выше. Удачи!
Вы можете найти пост Джеффа Этвуда о Jumbo Frames информативным.
Основные моменты поста:
Вы можете использовать ping.exe, чтобы проверить максимальный размер пакетов и сравнить его с вашими настройками Jumbo Frames.
ping -l 4096 -f server
Настройте размер пакета, используемый -l, и используйте -f, чтобы установить флаг DO_ NOT_FRAGMENT. Когда вы достигнете максимального размера пакета, вы получите «Пакет должен быть фрагментирован, но DF установлен».
Это даст вам представление о том, работает Jumbo Frames или нет.
Да, все должно поддерживать Jumbo Frames - относитесь к нему как к переключению между Token Ring и Ethernet. Единственное отличие состоит в том, что некоторые устройства могут по-прежнему работать в течение короткого времени или с перерывами - это также может быть большой головной болью, если вы не отслеживаете, какие устройства вы перенастроили в большой сети (то есть через 2 недели вы получаете сообщение о неисправности от какого-то пользователя с принтером, вставленным в заднюю часть их кабины, которая "только сейчас" перестала работать) То же самое относится и к любому новому компоненту: вам нужно будет настроить процедуру для перенастройки любых новых устройств и компьютеров с jumbo-кадрами, чтобы избежать обращений в службу поддержки, когда они не работают после начальной загрузки.
В Linux я нашел следующее: если вы используете vlans с тегами, установите mtu для базового устройства (например, eth1) в размер большого кадра. Все vlans, которые поддерживают jumbo-кадры, получают один и тот же mtu, vlans, которые не остаются с исходным, чаще всего 1500.
На самом деле, виртуальные локальные сети, в которых включены громкие разговоры и коммутация, смогут отправлять данные на локальный интерфейс виртуальной локальной сети, даже если значение mtu этого виртуальной сети меньше, чем у базового интерфейса.
Также в Linux команда для тестирования: ping -s 4096 -M do
-s это размер, -Му говорит "не фрагментируй". Если вы превысите местное значение mtu, вы получите ошибку. Если вы превысите дистанционное значение mtu, вы ничего не получите обратно.