00000001 + 00000001 = 00000011 альтернативный текст http://locobox.googlepages.com/red_x_round.png

Заблуждения о сети *

Время признаться! ... «в какой-то момент» вы подумали, что знаете что-то, и в итоге это было не правильно или не совсем правильно из-за неправильного представления о предмете.

Давайте создадим хороший список популярных заблуждений новичка И даже некоторых опытных ИТ-администраторов, явно о сети. Я надеюсь построить очень полезную «мозговую свалку», которая послужит хорошим ресурсом для членов этого сообщества.

Я начну с очень очевидного примера (пункты с наибольшим количеством голосов будут сверху) :

• Все адреса, начинающиеся с 169, поступают из системы аварийного переключения APIPA

  Только 169.254.0.0/16 зарезервировано для назначения APIPA, когда ОС не может найти назначенный адрес для сетевого интерфейса ( читай: rfc3927 ).

***** Не ошибаться с «ошибками, допущенными сисадминами»

Миф: разрешать ICMP небезопасно

Это моя любимая мозоль, и она достаточно распространена, чтобы вызвать серьезные проблемы в Интернете. Помимо удобной диагностики, которую мы все знаем и любим, есть Path MTU Discovery и другие вещи, которые ломаются, когда блокируется ICMP.

У некоторых людей есть религиозные убеждения относительно разрешенных и запрещенных IP-адресов. Вчера я видел в одном из ответов здесь, что «IP-адреса, оканчивающиеся на .0 или .255, являются недействительными», что явно неверно.

Другие все еще думают, что у нас есть только подсети размера A, B, C, в то время как CIDR долгое время управлял миром.

Некоторые утверждают, что отключение ответов ICMP сделает мою рабочую станцию ​​невидимой в ее сегменте локальной сети, что не соответствует действительности. Вы все еще можете отправлять запросы ARP, и в большинстве случаев машина будет отправлять ответ ARP, хотя на нем запущен брандмауэр уровня IP.

Другие говорят, что частные подсети - 192.168.0.0/16 или 10.0.0.0/8 - «не маршрутизируемые», что опять-таки неправильно.

Люди действительно удивляются, когда узнают, как насыщенность загрузки влияет на их скорость загрузки. Это очень сильно зависит от алгоритмов организации очередей на обоих концах узкого места, но в случае типичной загрузки ADSL-соединений это может существенно повлиять на загрузку.

Что смешно: некоторые все еще думают, что «Интернет - это серия трубок» .

Все интернет-соединения созданы равными, ака скорость загрузки - единственное, что имеет значение

«Я только что узнал, что такое T1, разве вы не знаете, что мой кабель Comcast дома в 6 раз быстрее, чем наше соединение на работе? Почему у нас его нет?»

Это больше не подходит, но дошло до того, что я предпочел бы проглотить скрепки, чем пытаться объяснить SLA еще одному маркетологу. (Хорошо, у меня был тот же вопрос, когда я был специалистом по поддержке рабочих станций, я признаю это!)

Джеймс Гослинг цитирует Питера Дойча с благодарностью за восемь ошибок распределенных вычислений :

По сути, каждый, кто впервые создает распределенное приложение, делает следующие восемь предположений. Все они оказываются ложными в долгосрочной перспективе, и все они вызывают большие неприятности и болезненный опыт обучения.

1. Сеть надежна
2. Задержка равна нулю
3. Пропускная способность бесконечна
4. Сеть безопасна
5. Топология не меняется
6. Есть один администратор
7. Транспортная стоимость равна нулю
8. Сеть однородна

У меня есть это на стене моего куба, обращенного к коридору. Иногда я чувствую, что спотыкаюсь о более чем одном из них в день .

Старый, но хороший,

• BPS (бит в секунду) и BAUD - это одно и то же, но это не так. BAUD - символьная скорость. Во многих системах символы каждый кодируют 2 или более битов. например,

  + 2v = 11
  + 1v = 10
  -1v = 01
  -2v = 00

На практике...

802.11A! = 54 Мбит / с, 802.11A ~ 27 Мбит / с

802.11B! = 11 Мбит / с, 802.11B ~ 5 Мбит / с

802.11G! = 54 Мбит / с, 802.11G ~ 22 Мбит / с

Ненавижу, когда в сети что-то обвиняют, когда приложение работает медленно.

Когда все работает, кроме Outlook, прекратите обновление заявки на сетевую команду, сообщающую, что сеть не работает. Невежественные работники службы поддержки - проклятие существования многих администраторов.

То, что работа в «железе» всегда лучше, чем в «программном».

(что приводит к очевидному вопросу о том, где можно провести черту между этими двумя, или есть вообще хорошее различие?)

Что «Мбит / с» и «Мбит / с» являются взаимозаменяемыми. Даже если бы я мог контекстуально различить, что «миллибиты» не являются действительной единицей измерения, между ними все равно разность в 8 раз.

И даже не заводите меня на mebibits.

В среде Enterprise LAN многие люди все еще полагают, что маршрутизация между vlans медленнее, чем переключение. В современных современных коммутаторах и коммутация, и маршрутизация обрабатываются аппаратно, которые могут обрабатывать / пересылать эти пакеты с одинаковой скоростью.

Идея, заключающаяся в том, что выделенные аппаратные устройства всегда лучше, надежнее и более производительны, чем обычные аппаратные средства и / или ПК, на практике при сегодняшних затратах.

Это в основном то, что Cisco хочет, чтобы вы верили; Конечно, NPE в шасси маршрутизатора имеет только процессор ARM ~ 300 МГц, но у него есть все эти ASIC (специализированные интегральные схемы) только для быстрой пересылки пакетов, поиска маршрутизации FIB и так далее.

Хотя это может быть правдой, и я, как правило , предпочитаю использовать проприетарные устройства подобного типа для маршрутизаторов и коммутаторов по различным административным причинам и причинам, связанным с MTBF, но в эпоху процессоров с тактовой частотой 3 ГГц и 8 ГБ ОЗУ часто присутствие ASIC и CAM просто не имеет значения - ПК все еще может курить этот маршрутизатор. Конечно, все это делается в ЦПУ, а не в автономном режиме для выделенного оборудования, и, конечно же, все это в процессах, подверженных разрушительному воздействию конкурентной среды планирования пространства пользователя в ОС общего назначения, но когда у вас 20-кратная мощность ЦП, иногда это не имеет значения - это все еще выходит далеко вперед, и намного дешевле.

Недавно я снова узнал об этом, когда имел дело с довольно высококлассным изгибом PIX для увеличения нагрузки на обработку пакетов в растущей среде VoIP (урезанные маршрутизаторы с высокой скоростью передачи пакетов в секунду гораздо больше, чем общая пропускная способность как таковая, а аудиопотоки VoIP состоят из очень большое количество очень маленьких пакетов); брандмауэр Linux, который я установил в качестве временной меры для маршрутизации между VLAN, тем временем взорвал эту штуку из воды.

То же самое для BGP. В мире Cisco все еще ведутся оживленные дебаты о минимальных спецификациях маршрутизаторов, необходимых для хранения одного или нескольких полных представлений BGP постоянно растущей таблицы маршрутизации IPv4, поскольку многие модели маршрутизаторов способны на это, если они не экономят на ОЗУ. , Ну, вы знаете, Quagga и надежный сервер Linux с отличной сетевой картой и тонкими настройками ввода / вывода могут творить чудеса. :-)

Такое дублирование MAc-адреса невозможно. Это просто чертовски маловероятно.

Неправильное представление о том, что использование беспроводного доступа означает, что доступ к Интернету намного медленнее, поскольку он показывает 54 МБ / с, тогда как при использовании соединения Ethernet - 100 МБ / с.

Само собой разумеется, было трудно объяснить пользователю, что это была только скорость локальной сети, и на самом деле скорость Интернета для сайта составляла всего 8 Мбит / с / 900 КБ / с.

Или, в качестве альтернативы, пользователи, которые требуют от вас предоставления широкополосного соединения, затем, когда вы говорите им, что беспроводное соединение, которое они используют, подключены к широкополосному интернет-соединению, они восклицают: «Нет, я имею в виду синий кабель!»

Тип кабеля не имеет значения для сети, если он профессионально обжат. Это объясняется администратором, который интересуется, почему совершенно новые компьютеры все еще имеют медленный доступ к Интернету благодаря своим адаптерам 100Base-T. Сетевой кабель был Cat-3 IIRC.

Заблуждение, что сеть с коммутацией Ethernet == безопасная сеть. Это не так.

Помимо повсеместного присутствия инструментов отравления арпами, таких как «Cain & Abel» и им подобных, тот факт, что таблица CAM будет время от времени истекать (по умолчанию 5 минут на коммутаторе Cisco ) и, таким образом, затопляет одноадресный трафик как концентратор, переводится в утечка пакетов и, следовательно, потенциальная утечка информации.

Вы можете изменить значение тайм-аута на управляемых коммутаторах, чтобы компенсировать, сколько затопления вы хотите разрешить, но, учитывая, что это часть того, как работает коммутация Ethernet, вы не можете полностью его уменьшить.

Для подключения двух компьютеров с гигабитным Ethernet необходим перекрестный кабель. Вы не делаете! Патч делает свое дело!

Миф: Удвоение скорости передачи в два раза увеличивает полезную пропускную способность.

Как и во многих мифах, это может быть правдой в некоторых ограниченных обстоятельствах, но при этом игнорируется задержка канала и ограничения производительности конечных систем и протоколов.

Увеличение числа бит / с сокращает время, необходимое системе для передачи данных на ссылку, это не заставляет данные перемещаться по ссылке быстрее. Время начала первого бита до другого конца такое же, как и раньше, но задержка до прибытия последнего бита уменьшается.

У меня есть несколько мифов, связанных с частными сетями (10.xxx, 192.168.xx и т. Д.).

Миф 1. Частные IP-адреса никогда не могут появляться в общедоступной сети. Следовательно, частный IP-адрес, который не принадлежит вам, не может появиться, скажем, в списке traceroute или в заголовках SMTP «Получено».

Миф 2: DNS-сервер, подключенный к Интернету, не может раздавать IP-адреса частных сетей.

Оба эти мифа основаны на одном и том же заблуждении: частные IP-адреса являются действительно частными и никогда не смешиваются с общедоступными. Я считаю, что в спецификации говорится только о том, что частные IP-адреса никогда не должны маршрутизироваться в общедоступной сети. То есть, если вы попытаетесь найти маршрут к некоторому случайному частному IP-адресу (при условии, что он не находится в вашей собственной сети), вы ничего не получите.

Но это не исключает возможности появления частных IP-адресов в выводе или результате какого-либо запроса. Внутренние почтовые серверы, например, не имеют общедоступного IP-адреса, поэтому какой другой IP-адрес они могут включить в заголовок Received-By, кроме своего собственного?

Аналогичным образом, большая институциональная сеть может использовать различные частные сети среди своих многочисленных локальных сетей. Пакеты, которые проходят через их сеть, получат частные IP-адреса маршрутизаторов, даже если пакет в конечном итоге вернется в общедоступную сеть. Таким образом, трассировка может включать частный IP-адрес маршрутизатора в свой вывод.

Миф 3. Поскольку адреса частных сетей не маршрутизируются, две сети с общим адресным пространством в частных сетях могут быть подключены через мост (например, VPN) без каких-либо проблем.

Это не сработает - по крайней мере, по моему опыту. Допустим, ваша работа использует сеть 192.168.1.x, и вы используете ту же сеть дома (как это типично для потребительских маршрутизаторов). Вы устанавливаете VPN-соединение с вашего домашнего компьютера для работы. В какой-то момент вы хотите отправить задание на печать на рабочий принтер с IP-адресом 192.168.1.10. Ваш домашний компьютер просматривает таблицу маршрутизации, чтобы выяснить, куда отправить этот пакет. Какая локальная сеть должна получить его: ваша домашняя сеть или ваша рабочая сеть? Ответ: не знаю. Может быть, этот, может быть, тот. Один из них получит его, но, вероятно, это зависит от вашей ОС и программного обеспечения VPN, чтобы определить, какой из них получает приоритет. Если это похоже на программное обеспечение VPN, с которым у меня был опыт, ваша домашняя локальная сеть получит его, и если на 192.168.1.10 не будет устройства, пакет будет в конечном итоге отброшен.

Решение: при использовании VPN убедитесь, что обе локальные сети используют разные сетевые пространства.

Я думаю, что самое большое заблуждение, которое я вижу, состоит в том, что сетевые технологии на базе IP могут решить все наши ИТ или технические потребности.

Самый большой пример, который я вижу, это VOIP. Это телекоммуникационная инфраструктура, которая невероятно дорогая, ресурсоемкая и трудная в управлении. Конечно, развертывания работают ... вроде, но я уверен, что могут быть гораздо лучшие системы с выделенными протоколами / инфраструктурой.

Что домашняя беспроводная точка доступа (или две) может заменить проводную сеть в многопользовательской среде. Конечно, ваше беспроводное соединение в домашних условиях поддерживает до 5 или около того компьютеров, но вы пытаетесь заставить его работать с двумя классными комнатами из 30 детей, которые все пытаются использовать ноутбуки для одновременного входа в домен Windows. Вам нужна управляемая беспроводная система или несколько фиксированных проводных точек для обработки некоторой (ну, большей части) нагрузки. И небольшое замечание для продавцов управляемых беспроводных систем: да, я уверен, что ваша система имеет лучшую производительность, чем у конкурентов, но она не бесконечна - пропускная способность настолько ограничена, что вы можете выжать из ограниченного набора частот доступны для беспроводной связи 802.11, вы не можете изменить законы физики!

То, что если SMB File Sharing / NetBIOS не работает, то больше ничего не будет работать в сети (включая просмотр WWW), и вся сеть не работает.

Бывший веб-проводник-педагог обратился к сисадминам, подумав, когда я учился в старшей школе. Я не знаю, была ли она разочарована вышеуказанным понятием.

Как насчет неправильного представления о том, что вы можете разделить полосу пропускания канала (в битах / с) на 8, чтобы точно смоделировать, сколько байтов будет проходить. Я всегда делаю ставку на 75% (максимум) от восьми десятых скорости соединения (т. Е. Для канала со скоростью 10 Гбит / с я делаю ставку на скорости до 600 Мбит / с).

Хорошо, вот кое-что, что я только что разработал, что до того, как меня ускользнули, для каждого отправляемого пакета появляется средняя служебная нагрузка 38 байтов, включая IP-заголовок и заголовок TCP (конечно, это значение предполагает, что все поля в заголовке TCP используются до максимума, размер IP-заголовка является общим значением, то есть без значений DSCP и т. д., и т. д.), поэтому для передачи, скажем, 2 МБ (с размерами пакетов в 64 КБ, увеличивающими ваши пакеты в секунду [большие пакеты в секунду = меньшие издержки] ) вы смотрите на 1,2 КБ служебных данных, не так много, но это равняется 6,78 МБ на каждые 10 ГБ переданных и 607,8 МБ на каждый 1 ТБ.

Я чувствую себя лучше: D

Миф: увеличение пропускной способности соединения всегда будет ускорять процесс.

Не так много. Если ваша ссылка не насыщена, и вы пытаетесь получить данные из Китая в США, возможно, вы просто едете так быстро, как можете. Чтобы добраться из США в Китай, требуется время (даже со скоростью света), и создание ссылки не будет происходить быстрее, если между сайтами будет только один поток данных.

Слегка настраиваю сокет с SO_LINGERопцией предотвращения состояния TCP, TIME_WAITпотому что « TIME_WAITэто, вы знаете, так, вы знаете, старое и, вы знаете, как, хреново ».

То, что ваше руководство / начальник, «Сетевой администратор СР» знает что-либо о реальной сети. - недовольный младший сетевой администратор.