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

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

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

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

Некоторые утверждают, что отключение ответов ICMP сделает мою рабочую станцию ​​невидимой в ее сегменте LAN, что неверно. Вы по-прежнему можете отправлять запросы 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
  + 1в = 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 раз.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сейчас мне лучше: D

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

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

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

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

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

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

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

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

С любовью настраивая сокет с SO_LINGER возможность предотвратить TCP TIME_WAIT состояние, потому что "TIME_WAIT это, вы знаете, так, вы знаете, старый и, знаете, вроде, противный".

Что ваше руководство / босс, "сетевой администратор SR", знает что-нибудь о реальных сетях. - недовольный администратор сети.