00000001 + 00000001 = 00000011 alt текст 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, зупиніть оновлення квитка на команду мережі, яка каже, що мережа працює. Невідомі службовці служби підтримки - це основа існування багатьох адміністраторів.

Те, що робити речі "апаратними засобами" завжди краще, ніж робити це в "програмному забезпеченні".

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

Це "MBps" і "mbps" взаємозамінні. Навіть якщо я міг би контекстуально визначити, що "мілібіти" не є дійсною одиницею вимірювання, все одно є коефіцієнт 8 різниці між ними.

І навіть не запускай мене на мебіти.

У середовищі Enterprise LAN багато людей все ще припускають, що маршрутизація між вланами відбувається повільніше, ніж комутація. З сучасними сучасними комутаторами, як комутація, так і маршрутизація обробляються апаратними засобами, які можуть обробляти / пересилати ці пакети з однаковою швидкістю.

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

Це в основному те, що Cisco хоче, щоб ви повірили; звичайно, NPE в шасі маршрутизатора має лише ARM-процесор ~ 300 МГц, але він має всі ці ASIC (інтегральні схеми, що застосовуються до програми) лише для швидкого пересилання пакетів, пошуку маршрутів FIB тощо.

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

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

Дітто для BGP. У світі Cisco досі триває бурхлива дискусія щодо мінімальних специфікацій маршрутизатора, необхідних для зберігання одного або декількох повних уявлень BGP про постійно зростаючу таблицю маршрутизації IPv4, оскільки так багато моделей маршрутизаторів, як правило, на це здатні, якщо вони не скупі на оперативку . Ну, ви знаєте, Quagga і надійний сервер Linux з чудовим NIC і низьким перериванням вводу / виводу можуть творити чудеса. :-)

Копіювання адреси MAc неможливо. Це так, просто навряд чи затято.

Помилкове уявлення про те, що використання бездротових засобів доступу до Інтернету набагато повільніше, оскільки він показує 54 Мб / с, тоді як використання з'єднання Ethernet показує 100 Мб / с.

Потрібно сказати, що важко було пояснити користувачеві, що це лише швидкість локальної мережі, а фактично швидкість Інтернету для сайту становила лише 8 mbps / 900 KB / s.

Або ж, користувачі, які вимагають від вас широкосмугового з'єднання, тоді, коли ви скажете їм бездротовий зв'язок, який вони використовують, підключений до широкосмугового підключення до Інтернету, вони вигукують "Ні, я маю на увазі синій кабель!"

Тип кабелю не має значення для мережі, якщо він професійно обтиснутий. Це походить від адміністратора, цікаво, чому нові комп'ютери все ще повільно отримують доступ до Інтернету зі своїми адаптерами 100Base-T. Мережевий кабель був Cat-3 IIRC.

Помилкове уявлення про те, що мережа з комутацією Ethernet == захищена мережа. Це не так.

Крім всюдисущої присутності засобів для отруєння арпами, таких як "Каїн та Абель", та їхнього подібного, той факт, що таблиця CAM буде вимикатись так часто (за замовчуванням 5 хвилин на комутаторі Cisco ) і, таким чином, затоплює одноразовий трафік, як концентратор витік пакетів і, таким чином, потенційний витік інформації.

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

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

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

Як і у багатьох міфах, це може бути правдою в деяких обмежених обставинах, але вона ігнорує затримку зв'язку та обмеження продуктивності кінцевих систем та протоколів.

Збільшення bps скорочує час, який потрібен системі для отримання даних на посилання, але це не змушує дані швидше рухатися по каналу. Час початку першого біта до іншого кінця такий же, як і раніше, але затримка до надходження останнього біта зменшується.

У мене є кілька міфів, пов’язаних із приватними мережами (10.xxx, 192.168.xx тощо).

Міф 1: Приватні IP-адреси ніколи не можуть з’являтися в загальнодоступній мережі. Отже, неможливо, щоб приватний IP, який не є вашим власним, з’являвся у, скажімо, в списку прослідкувань або в заголовках SMTP, "отриманих".

Міф 2: Неможливо, щоб інтернет-сервер DNS роздавав 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, переконайтеся, що обидві локальні мережі використовують різні мережеві простори.

Я думаю, що найбільша помилка, яку я бачу, полягає в тому, що мережа на основі IP може вирішити всі наші ІТ або технічні потреби.

Найбільший приклад, який я бачу в цьому, - це VOIP. Це інфраструктура телекомунікацій настільки неймовірно дорога, ресурсомістка і її важко правильно керувати. Впевнені, що розгортання працюють ... як би там не було, але я впевнений, що можуть бути набагато кращі системи з виділеними протоколами / інфраструктурою.

Що домашня бездротова точка доступу (або дві) може замінити дротову мережу в середовищі для багатьох користувачів. Звичайно, ваше бездротове з'єднання в домашніх умовах обробляє до 5 комп'ютерів, але ви намагаєтеся впоратися з двома аудиторіями по 30 дітей, які все одно намагаються використовувати ноутбуки для входу в домен Windows одночасно. Вам потрібна керована бездротова система або кілька фіксованих провідних точок, щоб обробляти частину (ну, більшу частину) навантаження. І коротка примітка для продавців керованих бездротових систем там: так, я впевнений, що ваша система має кращі показники, ніж конкуренція, але це не безмежно - є лише стільки пропускної здатності, яку ви можете вичавити з обмеженого набору частот доступний для бездротового зв’язку 802.11, ви не можете «змінити закони фізики!

Якщо обмін файлами SMB / 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можливістю запобігати TIME_WAITстану TCP, оскільки " TIME_WAITви знаєте, значить, ви знаєте, старий і, ви знаєте, як, юкі ".

Про те, що ваш керівник / начальник, адміністратор мережі "СР" знає що-небудь про реальні мережі. - незадоволений молодший адміністратор мережі.