Я хотел бы начать модернизировать свою сеть SOHO до гигабита (с 10/100) и немного слышал о Jumbo Frames.
Как лучше всего реализовать Jumbo Frames в сети? Насколько я могу судить, для правильной работы все сетевое оборудование в сети должно поддерживать Jumbo Frames. Это правда?
Если у меня есть определенное оборудование (например, сетевой принтер), которое не может быть обновлено до GB Ethernet, помешает ли это мне включить Jumbo Frames?
Каковы некоторые проблемы с включением Jumbo Frames?
Во-первых, лучше всего было бы объяснить, что такое Ethernet с большими кадрами. Ethernet - это сетевая технология уровня 2, а его блок данных протокола (PDU) - это фрейм. Для справки: L3PDU (уровень IP) - это пакет, а L4PDU (tcp / udp) - это сегмент.
Кадр Ethernet (существует несколько типов Ethernet, но мы можем обобщить здесь) состоит из заголовка (содержащего, среди прочего, MAC-адрес источника, MAC-адрес назначения, тег 802.1q VLAN и т. Д.) Данных или paylod-данных кадра и контрольной суммы CRC, используемой для проверки успешной передачи кадра.
Исходная сеть Ethernet указала размер кадра (значение данных во всем кадре, включая заголовок и контрольную сумму) как 1500 байт (или, возможно, 1518, необходимо его найти). Это число обеспечивает баланс между объемом данных для одновременной отправки и вероятностью сбоя или коллизии этой передачи и необходимости повторной передачи. С появлением быстрых полнодуплексных локальных сетей люди поняли, что производительность может быть улучшена за счет увеличения размера кадра Ethernet. Традиционный размер jumbo-фреймов составляет 9000 байт на фрейм, хотя это в основном условность.
В надежной, полнодуплексной LAN (или VLAN), в которой все элементы ожидают получения Ethernet-пакетов большого размера, это действительно улучшает производительность. Проблема с этим сценарием заключается в том, что вы вводите сетевой элемент или конечное устройство, которое этого не ожидает. В лучшем случае это приведет к снижению производительности, поскольку пакеты будут потеряны, поскольку принимающие устройства ожидают только 1518 байтов в кадре.
Теперь к вашим конкретным вопросам:
Как лучше всего реализовать Jumbo Frames в сети?
Это субъективный вопрос. В моем офисе мы решили внедрить его только там, где мы знали, что у нас есть все переменные под контролем, и знали, что это поможет. Для этого мы реализовали его в специальном «частном» vlan, к которому только определенные устройства могли получить доступ через свои вторые сетевые адаптеры. В частности, мы поместили вторую сетевую карту наших файловых серверов и серверов приложений в эту новую 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 с большим размером кадра, невозможно разговаривать с сетевым адаптером в VLAN с большим кадром), нам никогда не приходилось беспокоиться о конфигурации маршрутизатора.
Насколько я могу судить, для правильной работы все сетевое оборудование в сети должно поддерживать Jumbo Frames. Это правда?
Да, в значительной степени. Все сетевые «клиенты» (я имею в виду серверы / настольные компьютеры / IPKVM / IP-мониторы окружающей среды и т. Д.) Также должны говорить на нем, или, как упоминалось выше, у вас будет много полуодоступных машин (они будут пинговать, и любые L3 или L4PDU размером менее 1500 байтов будут успешными, что означает, например, что ваш почтовый сервер будет пинговать, и вы сможете вручную доставить то, что, вероятно, будет небольшим тестовым сообщением. Но когда вы попытаетесь доставить настоящее mail (тот, с вложением Excel, размер кадра которого превышает 1500 байт), он загадочным образом не сработает).
Если у меня есть определенное оборудование (например, сетевой принтер), которое не может быть обновлено до GB Ethernet, помешает ли это мне включить Jumbo Frames?
Если это так, вот что я бы сделал (при условии, что сетевое оборудование может с этим справиться):
Это означает, что в вашей сети больше не будет плоской топологии L2. Например, если с сервера с поддержкой jumbo-frame вы хотите распечатать на принтере без jumbo-кадров, пакеты должны быть маршрутизированы (проходят через ваш маршрутизатор, кадры переписываются в более традиционный размер, а затем отправляются на принтер в другой VLAN). Это означает, что связь между вашим jumbo-кадром и машинами без jumbo-кадра будет немного хуже, чем раньше, но скорость передачи данных между всеми устройствами в VLAN с jumbro-кадром будет лучше. Это действительно просто приговор.
Каковы некоторые проблемы с включением 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) на размер jumbo-кадра. Все vlan, поддерживающие jumbo-кадры, получают одинаковый mtu, vlans, которые не остаются с исходным, чаще всего 1500.
На самом деле vlan, у которых есть jumbo-говорящие и включена коммутация, смогут отправлять на локальный интерфейс vlan, даже если mtu на этом vlan меньше, чем один из базового интерфейса.
Также в Linux команда для тестирования: ping -s 4096 -M do
-s - это размер, -M действительно говорит «не фрагментировать». Если вы превысите местный mtu, вы получите ошибку. Если вы превысите удаленный mtu, вы ничего не получите обратно.