Петлевой адрес в ipv4 в мониторе ресурсов: Петлевой адрес в IPv4 что это

Содержание

Клиенты получают неверные настройки (IP-адреса) по DHCP | GeekBrains

Что делать, чтобы определить причину и решить проблемы

https://d2xzmw6cctk25h.cloudfront.net/post/2436/og_image/937798a9599f5339e64a422c8c4d2dda.png

Чтобы взаимодействовать с другими, каждому устройству в сети необходимо иметь четыре основные настройки на сетевом адаптере — IP-адрес, маску, шлюз по умолчанию и адреса DNS-серверов (хотя последнее на самом деле опционально). Есть два основных способа назначения сетевых настроек — статически (вручную) и динамически (автоматически по протоколу DHCP от DHCP-сервера).

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

Симптомы

Обычно всё начинается с жалоб на неработающий интернет или отсутствие доступа к локальным сетевым ресурсам.

Иногда достаточно провести диагностику только на стороне клиента, но может понадобиться полная диагностика и со стороны сервера в том числе. Начнём с первой опции. 

Диагностика на стороне клиента

Чтобы понять, что происходит, первым делом, конечно, следует проверить, подключён ли клиент физически к проводной или беспроводной сети. Если да, то самое время приступать к проверке сетевых настроек на устройстве клиента с помощью утилит ipconfig /all (в командной строке Windows), ifconfig или ip addr (в терминале Linux).

Вывод команд покажет текущий IP-адрес и другие настройки на сетевом адаптере (или всех адаптерах, если их несколько). При этом, если на сетевом адаптере нет корректного IP-адреса, возможных вариантов его настроек может быть немного. 

Вариант 1. Текущий IP-адрес имеет вид 169.254.Х.Х

Скорее всего, на клиентской машине при этом установлена ОС Windows. Это значит, что клиенту действительно не удалось получить сетевые настройки, потому что DHCP-сервер не отвечал, и адрес был сгенерирован службой APIPA (Automatic Private IP Addressing) из диапазона 169.

254.0.0 – 169.254.255.255. Если клиент — Linux-машина, адрес может принимать вид 0.0.0.0, либо отсутствовать в принципе.

Пожалуй, самое очевидное действие в такой ситуации — попытаться снова получить IP-адрес, отправив повторно DHCP-запрос, а заодно убедиться, что на устройстве запущен DHCP-клиент. Это можно сделать несколькими способами:

  • отключиться от сети на 10–30 секунд и подключиться снова; 
  • перезагрузить устройство; 
  • выполнить последовательно команды. В командной строке Windows: ipconfig /release, затем ipconfig /renew. В терминале Linux: dhclient -v -r, потом dhclient или dhcpcd -k, затем dhcpcd ().

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

Проще всего это сделать с помощью команды ping 127.0.0.1 (так называемая проверка внутренней обратной петли). Если в результате выполнения команды ответ от собственного сетевого адаптера получен, можно считать диагностику на стороне клиента завершённой и переходить к диагностике со стороны DHCP-сервера.

Вариант 2. Текущий IP-адрес не из диапазона 169.254.0.0 – 169.254.255.255, но и не из того диапазона адресов, которые должен выдавать DHCP-сервер

Как известно, чудес не бывает. Если настройки, которые получает клиент, не от доверенного DHCP-сервера в сети, значит, их раздаёт кто-то другой. Тот, кто случайно или специально подключил к сети DHCP-сервер со своей конфигурацией. Возможно, это обычный Wi-Fi-роутер, к которому кабель по ошибке подключили через один из LAN-портов. Тогда ваша задача — найти недоверенный DHCP-сервер и предотвратить такие попытки в будущем.

Здесь нужно вспомнить, как работает DHCP-протокол. Клиент отправляет широковещательный запрос (DHCPDISCOVER), который получат все DHCP-серверы в сети и отправят в ответ свои предложения IP-адреса (DHCPOFFER).

При этом клиент примет первое полученное предложение (DHCPOFFER), скорее всего, от ближайшего DHCP-сервера, а остальные отклонит.

Очевидно, что предложение от доверенного DHCP-сервера приходит позже, скорее всего, потому, что он дальше от клиента. Для последующей диагностики на устройстве клиента нужно установить анализатор сетевого трафика (Wireshark или tcpdump), запустить его, отфильтровав трафик по типу протокола DHCP или портам 67–68, и посмотреть в DHCP-ответах IP и MAC адрес DHCP-сервера, который их отправляет: 

Дальше дело за малым. Во-первых, можно воспользоваться сервисом macvendors.com или аналогичным и по MAC-адресу определить производителя оборудования этого устройства. У Wireshark есть такая функция. Во-вторых, если есть управляемые коммутаторы в сети, найти по MAC, в какой порт какого коммутатора подключено это устройство. После нейтрализации недоверенного DHCP-сервера клиенту, скорее всего, удастся получить верные настройки.

Для предотвращения таких инцидентов в будущем рекомендуется внедрить методы защиты от атак на DHCP на сетевом оборудовании.

Вариант 3. Текущий IP-адрес корректный, но доступа к интернету и другим сетевым ресурсам по-прежнему нет 

Если это так, то стоит вернуться к проверке не только самого IP-адреса, но и всех остальных настроек. И особенно к проверке маски, адреса шлюза по умолчанию и адресов DNS-серверов, так как именно через шлюз устройству предстоит связываться с другими сетями, а с помощью DNS-серверов — преобразовывать доменные имена в IP-адреса.

Следует помнить, что DHCP-сервер может раздавать настройки выборочно, а сам клиент может выборочно их применять. Например, только IP-адрес, маску и шлюз. Это скорее исключение, но в таком случае адреса DNS придётся прописать руками. Гораздо хуже, если настройки адресов DNS-серверов от DHCP-сервера игнорируются просто потому, что их переопределяет стороннее ПО или неверные статические настройки. Такое тоже бывает.  

Диагностика на стороне сервера 

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

Запущен ли DHCP как сервис?

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

Приходят ли запросы от клиентов на DHCP-сервер? 

Чтобы определить это, нужно снова запустить анализатор сетевого трафика. На этот раз на сервере. После запуска на сервере tcpdump, dhcpdump или Wireshark клиенту, у которого проблемы с получением адреса, необходимо попытаться получить его снова любым способом, описанным в начале статьи. Если DHCP-сервер работает в штатном режиме, то должны быть и запросы, и ответы. Но всё может быть иначе.

Нет ни запросов, ни ответов? 

Предположим, что у нас есть по крайней мере один клиент, которому не удаётся получить настройки, и запрос от него точно должен был прийти на сервер. Если этого не произошло, очевидно, что клиент либо сам не отправляет запрос, либо запрос не доходит до сервера по разным причинам. Может, он блокируется на промежуточном сетевом оборудовании или в сети некорректно работает ретрансляция DHCP-запросов dhcp_relay.

Чтобы это проверить, можно в первом случае вернуться к диагностике на стороне клиента и проследить с помощью анализатора сетевого трафика, что клиент отправляет DHCP-запрос. Во втором — проверить настройки на промежуточном сетевом оборудовании. 

Запрос(ы) есть, ответа(ов) нет? 

Самая простая и очевидная причина в этом случае — закончился пул свободных адресов. Это легко проверить на самом DHCP-сервере по списку выделенных IP-адресов (leases). Если причина действительно в этом — задумайтесь: возможно, пришло время для увеличения пула пригодных для использования IP-адресов на сервере. Чтобы решить проблему прямо сейчас, можно почистить список существующих адресов, выданных в аренду клиентам, уменьшить время аренды и перезапустить сервис DHCP. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.

Сетевые IPv4-адреса. Сетевой адрес, адрес узла и широковещательный адрес. CCNA Routing and Switching.

Рисунок 1 — Типы адресов в сети.

  1. Адрес и маска подсети ссылаются на сеть. Все узлы в сети имеют один сетевой адрес. В узловой части — одни нули.
  2. Уникальные IP-адреса, назначаемые узлам и устройствам. В узловой части могут быть нули и единицы, но не могут быть только нули или только единицы.
  3. IP-адрес первого доступного узла в сети. Узловая часть всегда содержит одни нули и заканчивается на 1.
  4. IP-адрес последнего доступного узла в сети. Узловая часть всегда содержит одни единицы и заканчивается на 0.
  5. Специальный адрес, обменивающийся данными со всеми узлами в сети. Например, если узел отправляет пакет на сетевой IPv4-адрес, пакет получат все другие узлы в этой сети. Для широковещательной рассылки используется верхний адрес диапазона сети. В узловой части — одни единицы.

Каждый сетевой адрес содержит (или определяет) адреса узлов и широковещательный адрес, как описано на рисунке 1.

  • На рисунке 2 перечислены и описаны конкретные адреса в сети 192.168.10.0 /24.

Рисунок 2 — Типы адресов в сети 192.168.10.0/24

  • Другие примеры приведены на рисунках 3–7. На этих рисунках обратите внимание, что сетевая часть адреса остается неизменной, а меняется только узловая часть.
  • На рисунке 3 показан сетевой адрес 10.1.1.0 /24. Биты узла — все нули.

Рисунок 3 — Сетевой адрес.

  • На рисунке 4 показан IPv4-адрес узла 10.1.1.10. Биты узла представляют собой сочетание нулей и единиц.

Рисунок 4 — Адрес узла.

  • На рисунке 5 показан IPv4-адрес первого узла 10.1.1.1. Биты узла — все нули и одна единица. Обратите внимание, что он назначен интерфейсу маршрутизатора и поэтому станет шлюзом по умолчанию для всех узлов в этой сети.

Рисунок 5 — Адрес первого узла.

  • На рисунке 6 показан IPv4-адрес последнего узла 10.1.1.254. Биты узла — все единицы и один ноль.

Рисунок 6 — Адрес последнего узла.

  • На рисунке 7 показан широковещательный адрес 10.1.1.255. Биты узла — все единицы.

Рисунок 7 — Широковещательный адрес.

Источник: Академия Cisco.

Теги: CCNA, Cisco, Routing and Switching.

Как определить белый или серый IP адрес, какая разница 💻

Вот с такого весёлого заголовка начинаю эту статью про IP-адреса. Надеюсь, что такое IP объяснять не нужно? Но на всякий случай, IP-адрес – это цифровой адрес каждого устройства, подключённого к сети, например к локальной или Интернет.

Если более конкретно, то это набор из четырёх цифр от 0 до 255, разделённых с помощью точки, например «193. 126.243.10»  Т.е. у каждого из нас есть свой IP и от этих цифр может многое зависеть. Айпишники бывают разные: внешние и внутренние, статические и динамические,  белые и серые (не путайте с MAC-адресами!). Сейчас я хочу поговорить именно о последней классификации.

Белые и серые IP-адреса

Так уж сложилось в современном мире Интернет, что несмотря на огромное число возможных IP-адресов, а это чуть больше четырёх миллиардов, на всех их не хватает! В идеале, у каждого пользователя сети Интернет должен быть свой уникальный IP-адрес. А это не только компьютеры, но и телефоны, камеры слежения, телевизоры и даже холодильники с доступом в интернет! Вот и получается, что некоторые провайдеры интернета идут на некую «хитрость».

Они резервируют под себя один или несколько адресов, и все кто к нему подключён, выходят в сеть только под этими адресами. Чтобы было понятней, приведу пример. Допустим, у провайдера адрес «193.126.243.10», тогда у всех кто подключён к этому провайдеру будет такой же IP-адрес в интернете «193. 126.243.10». При этом во внутренней (локальной) сети у каждого клиента будет свой собственный внутренний адрес, но в интернете — у всех общий. Это и есть серый IP-адрес, т.е. не уникальный.

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

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

Зачем нужен белый IP-адрес

Возникает закономерный вопрос: а зачем мне платить за белый айпишник? Тут проще рассказать что происходит, если ваш IP серый.

Во-первых, при большом количестве «сидящих» на одном адресе может возникнуть нелепая ситуация. Например, на каком-то ресурсе участника забанили навечно по ip-адресу, и когда вы заходите на этот же ресурс, то видите милое сообщение «Вы ЗАБАНЕНЫ!». Хотя вы туда зашли впервые, но адрес у вас тот же, что и у заблоченого человека! Вероятность такого исхода событий не высока, но гораздо более частая проблема – это невозможность скачать файлы с некоторых крупных файлообменников, например таких как DepositFiles или Turbobit. Там стоит ограничение на бесплатную закачку, и привязано оно всё так же к айпи.

В итоге, вы хотите скачать файл, а там пишет «С вашего IP-адреса уже идёт скачивание!» 🙂 весело, не так ли? А после того, как «тот парень» докачает свой файл мы видим другое сообщение «Превышен лимит скачиваний для вашего IP-адреса, зайдите через 258 минут 47 секунд…» ваще афигеть! Вобщем, если файл очень нужен, приходится его искать по другим файлопомойкам или подключаться через прокси-серверы и VPN. Думаю смысл этого недостатка понятен.

Второй минус, а он же и плюс (да, плюс у серого ип тоже есть) – это невозможность подключиться к компьютеру из интернета напрямую. Наиболее часто от этого страдают геймеры, когда не могут участвовать в онлайн-игре. Ещё потребность возникает при необходимости удалённого управления компьютером с помощью таких программ как Remote Administrator, Dameware Utilities или VNC Viewer. Есть способы обойти это ограничение, например настроив VPN-канал между компьютерами, но требуют лишних телодвижений.

А можно использовать программу TeamViewer, если нужно просто получить доступ к рабочему столу удалённого компьютера. Она позволяет соединяться компьютерам с серыми адресами. Именно её используют такие мастеры-ломастеры, как я 🙂 чтобы помочь решить проблему на другом компьютере, который может находиться в тысячах километров. Кстати, если у вас есть нерешённые проблемы, то я смогу подключиться к вашему компьютеру и разобраться что к чему, обращайтесь 😉

Как я уже сказал, что это и есть плюс серых адресов: к ним невозможно достучаться из интернета, если ваш компьютер сам не установит внешнее соединение. Это значит, что пока вы не поймали вирусняк, то хакеры не смогут узнать как вас найти в интернете. Но ваш компьютер легко можно найти в локальной подсети провайдера. Это смогут сделать те самые люди, которые «сидят» вместе с вами под одним IP-адресом. Забавно, не правда ли? Но всё-равно, видимость для миллионов или для пары сотен соседей это две большие разницы.

В-третьих, есть догадки что при одновременном выходе в сеть большого числа пользователей с одного адреса, может просесть ваша скорость.

Как узнать какой у вас адрес, белый или серый

Главное узнать ваш IP-адрес в сети провайдера. Способ зависит от того, как вы подключены к интернету: напрямую кабелем или через роутер (по кабелю или Wi-Fi).

В любом случае, у вас серый адрес, если ваш IP-адрес у провайдера подходит под маску:

  • 192.168.xxx.xxx
  • 172.16.xxx.xxx
  • 10.xxx.xxx.xxx
  • 127.xxx.xxx.xxx
  • 169.254.xxx.xxx

Прямое подключение компьютера к кабелю провайдера

Посмотреть это можно в Windows 7/8/10 если пройти в . Также его можно открыть если кликнуть правой кнопкой по значку соединения и выбрать «Центр управления сетями и общим доступом»

Далее, кликаем по своему соединению:

и переходим на вкладку «Подробно» или кнопка «Сведения» (в Windows 10). Нам нужно поле IPv4-адрес клиента. Как видим, у меня серый IP.

Белый не может начинаться с цифры 172 (см. выше). Посмотрите видео:

Если у вас Wi-Fi роутер

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

Я покажу на примере роутера TP-Link. Сначала заходим через любой браузер в админ-панель своего роутера по его IP, вбив его в адресную строку. По умолчанию он равен 192.168.0.1 или 192. 168.1.1. Далее нужно будет ввести логин и пароль. По умолчанию это admin/admin. В самой панели на начальной странице обычно есть суммарная информация о состоянии устройства. Вот здесь нужно найти раздел «WAN» и прочитать значение «IP Address»:


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

Связь с динамическими и статическими адресами

Динамические IP адреса меняются при каждой перезагрузке роутера, поэтому он в 99% случаев не бывает белым. Статический адрес всегда один и тот же. Поэтому скорее всего он будет белым, т.к. в этом есть смысл и это логично.

Подведём итоги

  • В зависимости от выбранного тарифа провайдера, или от его жадности, ваш IP-адрес в интернете может быть белым или серым
  • Под белым айпи вы – хозяин интернета, а под серым – можете оказаться не у дел ни за что
  • Безопасность в интернете для серого адреса выше чем для белого
  • Проще всего позвонить своему провайдеру и спросить что у вас 🙂

Структура IPv4 адреса, сети и подсети, разделение сети на подсети

Структура IP-адреса

IP-адрес представляет собой число размером 32 бита (или 4 байта), которое может быть записано в любой системе счисления (тут речь про адрес протокола IP version 4, в IPv6 он имеет размер 128 бит).

Например, адрес в десятичной системе 127.0.0.1 можно записать так:

01111111.00000000.00000000.00000001

Адрес делится на 4 октета, по 8 бит каждый, которые могут иметь значение от 0 (00000000) до 255 (11111111):

IP-адрес содержит в себе две основных части — адрес сети и адрес хоста в этой сети.

К примеру, адрес 77.120.120.20 представляет собой сеть 77.120.120.0, в которой находится хост с адресом 20.

Сети и маска сети

Помимо указания самого IP-адреса, на сетевом интерфейсе так же указывается его маска сети. Маска не передаётся в заголовках TCP/IP пакетов, но используется сетевой картой для определения дальнейшего маршрута пакета — если адрес назначения находится в одной сети с адресом отправителя — он будет отправлен напрямую, если же в отдельной сети — пакет будет передан маршрутизатору, согласно таблице маршрутизации пакетов.

Рассмотрим адрес 77.120.120.20 с маской 255.255.255.0.

В двоичном представлении этот адрес можно записать так:

адрес:

01001101.01111000.01111000.00010100

маска:

11111111.11111111.11111111.00000000

Для первых трёх октетов в IP-адресе установлен (или «включён«) «бит маски» (иначе — «битовая маска«), следовательно — первые три октета адреса являются адресом сети, а последние 8 бит — адресом хоста.

Таким образом, адрес 77.120.120.20 с маской 255.255.255.0 является в сетью 77.120.120.0, которая является классом С (которая, в свою очередь, является подсетью сети 77.120.0.0 класса В, которая является подсетью сети 77.0.0.0, которая является сетью верхнего уровня — А, хотя с появлением CIDR (см. ниже) понятие «классы сети» фактически потеряло актуальность).

Что бы сократить запись о сети  77.120.120.0 с маской 255.255.255.0 — можно использовать сокращённую форму: 77.120.120.0/24.

«/24» называется «префикс сети«, и указывает на количество «битов маски«. Таким образом, из 32 бит адреса 24 указаны как адрес сети, а 8 — остаются для адресов хостов в этой сети.

Если взять, к примеру, сеть 77.120.120.0/28 — мы получим только 4 бита, выделенных для адресов, т.е. маска сети будет выглядеть как 11111111.11111111.11111111.11110000, или 255.255.255.240.

Такое описание сетей и подсетей называется «бесклассовой классификацией» (Classless Inter-Domain Routing — CIDR).

Использование CIDR даёт возможность отказаться от традиционного разбиения на сети различных классов (А, B, C и т.д.) , и создавать подсети необходимого размера.

К примеру, подсеть 77. 120.120.0/28 (которую можно перевести в маску сети 11111111.11111111.11111111.11110000 в двоичном виде (4 последних бита «сброшены»)или 255.255.255.240 в десятичном) содержит 4 бита адресов хостов. В 4 бита можно «вместить» 24 адресов — 16. Из этих 16 стоит вычесть первый (сам адрес 77.120.120.0, так он является адресом самой сети) и последний (77.120.120.255, так как он является широковещательным, или broadcast, адресом сети, на который в теории должны отвечать все хосты сети), таким образом — из 16 адресов сети для хостов остаётся 14 адресов.

Маска подсети Альтернативный
формат записи
Последний октет
(в двоичном виде)
Последний октет
(в десятичном виде)
255.255.255.0 /24 0000 0000 0
255. 255.255.128 /25 1000 0000 128
255.255.255.192 /26 1100 0000 192
255.255.255.224 /27 1110 0000 224
255.255.255.240 /28 1111 0000 240
255.255.255.248 /29 1111 1000 248
255.255.255.252 /30 1111 1100 252

 

Маска подсети Размер идентификатора хоста   Максимальное
количество хостов
8 бит 255.0.0.0 24 бит 224 – 2 16777214
16 бит 255.255.0.0 16 бит 216 – 2 65534
24 бит 255.255.255.0 8 бит 28 – 2 254
29 бит 255. 255.255.248 3 бит 23 – 2 6

Более полные таблицы сетей можно найти в статье Сети, подсети, классы подсетей. Таблица подсетей.

Разделение сети на подсети

Допустим, имеется сеть 77.120.120.0/24, или сеть 77.120.120.0 с маской 255.255.255.0 — из которой необходимо выделить две различные сети. Сеть 77.120.120.0/24 включает в себя адреса от 77.120.120.0 до 77.120.120.255.

Представим эту сеть и её маску в двоичном виде:

адрес сети:

1001101.1111000.1111000.00000000

маска:

11111111.11111111.11111111.00000000

Займём на один бит больше в последнем октете маски сети — 11111111.11111111.11111111.10000000 (или 255.255.255.128 в десятичном виде). У нас осталось (32 бита IP-адреса — 7 бит под адреса хостов) = 25 бит — под маску. Следовательно, первая сеть в десятичном виде будет выглядеть как 77. 120.120.0/25, и включает в себя адреса от 77.120.120.0 до 77.120.120.127 (7 бит под адреса: 27 = 128 адресов, включая первый адрес 0 — получаем 127 всего), а вторая сеть получит адреса от 77.120.120.128 до 77.120.120.255, или 77.120.120.128/25.

Ещё один способ рассчитать максимальное значение (последний адрес для сети): в 25-ти битной маске мы имеем 7 бит под адреса; следовательно — адрес первой сети в двоичном виде будет выглядеть так: 1001101.1111000.1111000.00000000 — где жирным выделен адрес сети, а курсивом — «свободные» биты под адреса хостов. Максимальное значение, которое можно вместить в семь бит — 01111111 = 127.

Для второй сети мы имеем вид 77.120.120.128, или 1001101.1111000.1111000.10000000, а максимальное значение последнего октета будет 11111111 = 255.

Ссылки по теме

http://www.adminsub.net

http://www. shunsoft.net

https://en.wikipedia.org

http://habrahabr.ru

http://planetcalc.ru

http://zyxel.ua


Руководство по настройке IP-адресов и служб Cisco IOS XR для маршрутизатора Cisco CRS, выпуск 4.3.x - реализация сетевого стека IPv4 и IPv6 [программное обеспечение Cisco IOS XR (окончание продажи)]

Значение 135 в поле Тип заголовка пакета ICMP идентифицирует сообщение запроса соседа. Сообщения запроса соседей отправляются по локальному каналу, когда узел хочет определить адрес канального уровня другого узла в том же локальном канале. (См. Рис. 1.) Когда узел хочет определить адрес канального уровня другого узла, адрес источника в сообщении запроса соседа является IPv6-адресом узла, отправляющего сообщение запроса соседа.Адрес назначения в сообщении с запросом соседа - это групповой адрес запрошенного узла, который соответствует IPv6-адресу узла назначения. Сообщение запроса соседей также включает в себя адрес канального уровня исходного узла.

Рисунок 9. IPv6 Neighbor Discovery - Neighbor Solicitation Message

После получения сообщения запроса соседа узел назначения отвечает, отправляя сообщение с объявлением соседа, которое имеет значение 136 в поле Тип заголовка пакета ICMP на локальном компьютере. ссылка.Исходный адрес в сообщении с объявлением соседа - это IPv6-адрес узла (более конкретно, IPv6-адрес интерфейса узла), отправляющего сообщение с объявлением о соседнем узле. Адрес назначения в сообщении с объявлением соседа - это IPv6-адрес узла, который отправил сообщение запроса соседа. Часть данных сообщения объявления соседа включает в себя адрес канального уровня узла, отправляющего сообщение объявления соседа.

После того, как узел источника получает объявление о соседе, узел источника и узел назначения могут обмениваться данными.

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

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

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

Сосед считается достижимым, когда от соседа возвращается положительное подтверждение (указывающее, что пакеты, ранее отправленные соседу, были получены и обработаны). Положительное подтверждение - от протокола верхнего уровня (например, TCP) - указывает на то, что соединение продвигается вперед (достигает места назначения) или что получено сообщение с объявлением соседа в ответ на сообщение запроса соседа. Если пакеты достигают однорангового узла, они также достигают соседнего узла источника.Следовательно, продвижение вперед также является подтверждением того, что сосед на следующем переходе доступен.

Для пунктов назначения, которые не находятся в локальном канале, прогресс пересылки означает, что маршрутизатор первого перехода доступен. Когда подтверждения от протокола верхнего уровня недоступны, узел проверяет соседа, используя одноадресные сообщения запроса соседа, чтобы убедиться, что прямой путь все еще работает. Возврат запрошенного сообщения с объявлением соседа от соседа является положительным подтверждением того, что прямой путь все еще работает.(Соседние рекламные сообщения, для которых установлен флаг запрошенного значения 1, отправляются только в ответ на сообщение с запросом соседа.) Незапрошенные сообщения подтверждают только односторонний путь от источника к узлу назначения; Запрошенные рекламные сообщения о соседях указывают, что путь работает в обоих направлениях.


Примечание


Сообщение с объявлением о соседнем узле, для которого установлен флаг запрошенного значения 0, не следует рассматривать как положительное подтверждение того, что прямой путь все еще работает.


Сообщения запроса соседей также используются в процессе автоконфигурации без сохранения состояния для проверки уникальности одноадресных IPv6-адресов до того, как адреса будут назначены интерфейсу. Обнаружение повторяющегося адреса выполняется сначала на новом, локальном для канала IPv6-адресе до того, как адрес будет назначен интерфейсу. (Новый адрес остается в предварительном состоянии, пока выполняется обнаружение повторяющегося адреса.) В частности, узел отправляет сообщение запроса соседа с неуказанным исходным адресом и предварительным локальным адресом ссылки в теле сообщения.Если другой узел уже использует этот адрес, узел возвращает сообщение объявления соседа, которое содержит предварительный локальный адрес ссылки. Если другой узел одновременно проверяет уникальность того же адреса, этот узел также возвращает сообщение запроса соседа. Если в ответ на сообщение запроса соседа не получено никаких сообщений с запросом соседа и не получены сообщения запроса соседа от других узлов, которые пытаются проверить тот же предварительный адрес, узел, который отправил исходное сообщение запроса соседа, считает предварительный локальный адрес канала быть уникальным и присваивает адрес интерфейсу.

Каждый одноадресный адрес IPv6 (глобальный или локальный для связи) должен быть проверен на уникальность на канале; однако до тех пор, пока уникальность локального адреса ссылки не будет проверена, обнаружение дублирующихся адресов не выполняется ни на каких других адресах IPv6, связанных с локальным адресом ссылки. Реализация Cisco обнаружения повторяющихся адресов в программном обеспечении Cisco IOS XR не проверяет уникальность произвольных или глобальных адресов, которые генерируются из 64-битных идентификаторов интерфейса.

RHEL7: Настройте адреса IPv4 и выполните базовое устранение неполадок IPv4.

Примечание. Это цель экзамена RHCSA 7.

Презентация

Хотя по-прежнему можно определить конфигурацию сети через файлы в каталоге / etc / sysconfig / network-scripts , это больше не является предпочтительным способом (не забудьте выполнить # nmcli con reload , если вы вручную изменить файлы!).

С RHEL 7 вся сетевая конфигурация теперь в основном выполняется через NetworkManager (журнал изменений NetworkManager доступен здесь).

Вы можете использовать:

  • nmtui команда и T ext U ser I nterface,
  • команда nmcli на интерфейсе C L ine I nterface,
  • или графический интерфейс.

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

Изменения, сделанные с помощью команды nmcli , являются постоянными.

Внимание: Чтобы практиковать это руководство в наилучших условиях, подключитесь к машине через консоль (иначе вы можете потерять соединение!).

Конфигурация сети

Чтобы отобразить конфигурацию сети, введите:

 #  nmcli con показать 
НАЗВАНИЕ ТИП UUID УСТРОЙСТВО
  ethernet-eth0   8d83684f-cd22-42cc-9fff-7704945a5c36  802-3-ethernet eth0
 

Примечание: con - это ярлык для соединения (вы даже можете ввести только c ).

Или , вы можете ввести:

 #  Статус разработчика nmcli 
ТИП УСТРОЙСТВА СОСТОЯНИЕ СОЕДИНЕНИЕ
eth0 ethernet подключен ethernet-eth0
lo loopback неуправляемый -
 

Чтобы удалить соединение (здесь ethernet-eth0 ), введите:

 #  nmcli с ethernet-eth0  

Примечание 1. Если в имени интерфейса появляется пробел (например, System eth0 ), поместите все в кавычки: nmcli con del «System eth0» .
Примечание 2: del - это ярлык для удаления .

или

 #  нмcli с 8d83684f-cd22-42cc-9fff-7704945a5c36  

Управление подключением

Чтобы создать соединение с именем ethernet-eth0 , IPv4-адресом 192.168.1.10/24 и шлюзом по умолчанию 192.168.1.1 , введите:

 #  nmcli con add con-name net-eth0 ifname eth0 type ethernet ip4 192.168.1.10/24 gw4 192.168.1,1 
Подключение net-eth0 (441085a4-4155-417b-ad8f-78a888d89988) успешно добавлено.
 

Примечание 1. Если вы не укажете con-name net-eth0 , соединение будет называться ethernet-eth0 .
Примечание 2: если вы не укажете часть ip4 192.168.1.10/24 gw4 192. 168.1.1 , вы получите соединение, автоматически настроенное через DHCP .
Примечание 3: nmcli con up net-eth0 не требуется при первоначальной настройке соединения.
Примечание 4: ip4 и gw4 используются соответственно для IP-адреса и шлюза по умолчанию. Ниже вы увидите, что при изменении соединения используется другой синтаксис: в этом случае используется ipv4.addresses и пробел между IP-адресом и шлюзом по умолчанию.

Чтобы проверить конфигурацию, введите:

 #  ip a 
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
    ссылка / петля 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    инет 127.0.0.1 / 8 объем хоста lo
       valid_lft навсегда предпочтительный_lft навсегда
    inet6 :: 1/128 хост области
       valid_lft навсегда предпочтительный_lft навсегда
2: eth0:  mtu 1500 qdisc pfifo_fast состояние UP qlen 1000
    ссылка / эфир 00: 00: 00: 00: 00: 00 brd ff: ff: ff: ff: ff: ff
    inet  192. 168.1.10/24  brd 192.168.1.255 область действия global eth0
       valid_lft навсегда предпочтительный_lft навсегда
    inet6 fe80 :: 0000: 00: 0000: 0000/64 ссылка области
       valid_lft навсегда предпочтительный_lft навсегда
#  ip r 
по умолчанию через 192.168.1.1  dev eth0 proto static metric 1024
  192.168.1.0/24  dev eth0 proto kernel scope link src  192.168.1.10
  

Примечание 1: ip a - это ярлык для ip address show , ip r ярлык для ip route show .
Примечание 2: больше не используйте команду ifconfig . Эта команда устарела и больше не отображает правильную конфигурацию сети (вторичные IP-адреса и т. Д.).

Чтобы получить всю информацию о подключении (здесь net-eth0 ), введите:

 #  nmcli con show net-eth0 
подключение.идентификатор: net-eth0
connection. uuid: 441085a4-4155-417b-ad8f-78a888d89988
connection.interface-имя: eth0
тип подключения: 802-3-ethernet
connection.autoconnect: да
connection.timestamp: 1427832564
connection.read-only: нет
connection.permissions:
connection.zone: -
connection.master: -
подключение.раб-тип: -
connection.secondaries:
connection.gateway-ping-timeout: 0
802-3-ethernet.port: -
802-3-ethernet. Скорость: 0
802-3-ethernet.duplex: -
802-3-ethernet.auto -gotiate: да
802-3-ethernet.mac-адрес: -
802-3-ethernet.cloned-mac-адрес: -
802-3-ethernet.mac-адрес-черный список:
802-3-ethernet.mtu: авто
802-3-Ethernet.s390-подканалы:
802-3-ethernet.s390-nettype: -
802-3-ethernet.s390-варианты:
ipv4.method: руководство
ipv4.dns:
ipv4.dns-поиск:
ipv4.addresses: {ip = 192.168.1.10/24, gw = 192.168.1.1}
ipv4.routes:
ipv4.ignore-auto-routes: нет
ipv4.ignore-auto-dns: нет
ipv4.dhcp-client-id: -
ipv4.dhcp-send-hostname: да
ipv4.dhcp-имя хоста: -
ipv4. Never-default: нет
ipv4.may-fail: да
ipv6.method: auto
ipv6. dns:
ipv6.dns-поиск:
ipv6.адреса:
ipv6.routes:
ipv6.ignore-auto-routes: нет
ipv6.ignore-auto-dns: нет
ipv6. Never-default: нет
ipv6.may-fail: да
ipv6.ip6-privacy: -1 (неизвестно)
ipv6.dhcp-имя хоста: -
GENERAL.NAME: net-eth0
GENERAL.UUID: 441085a4-4155-417b-ad8f-78a888d89988
ОБЩИЕ УСТРОЙСТВА: eth0
GENERAL.STATE: активировано
ОБЩИЕ ПО УМОЛЧАНИЮ: да
ГЕНЕРАЛЬНЫЙ.ПО УМОЛЧАНИЮ6: нет
GENERAL.VPN: нет
GENERAL.ZONE: -
GENERAL.DBUS-PATH: / org / freedesktop / NetworkManager / ActiveConnection / 0
GENERAL.CON-PATH: / org / freedesktop / NetworkManager / Settings / 0
GENERAL.SPEC-ОБЪЕКТ: -
GENERAL.MASTER-PATH: -
IP4.ADDRESS [1]: ip = 192.168.1.10/24, gw = 192.168.1.1
IP6.АДРЕС [1]: ip = fe80 :: 0000: 00: 0000: 0000/64, gw = ::
 

Или , вы можете ввести:

 #  nmcli dev показать eth0 
ГЕНЕРАЛЬНОЕ УСТРОЙСТВО: eth0
ОБЩИЙ ТИП: Ethernet
GENERAL.HWADDR: 00: 00: 00: 00: 00: 00
GENERAL.MTU: 1500
GENERAL.STATE: 100 (подключено)
ОБЩИЕ СВЕДЕНИЯ: net-eth0
ГЕНЕРАЛЬНЫЙ. CON-PATH: / org / freedesktop / NetworkManager / ActiveConnection / 0
ПРОВОДНАЯ-СВОЙСТВА. ПЕРЕВОЗЧИК: вкл.
IP4.АДРЕС [1]: 192.168.1.10/24
IP4.ШЛЮЗ: 192.168.4.10
IP4.DNS [1]: 192.168.4.1
IP6.АДРЕС [1]: fe80 :: 0000: 00: 0000: 0000/64
IP6.ШЛЮЗ:
 

Чтобы отключить сетевое соединение (здесь net-eth0 ), введите:

 #  nmcli con down net-eth0 
#  nmcli con счет 
НАЗВАНИЕ ТИП UUID УСТРОЙСТВО
net-eth0 441085a4-4155-417b-ad8f-78a888d89988 802-3-ethernet  - 
 

Примечание 1: показывает, что соединение больше не активно (добавьте параметр –активный , чтобы отображались только активные соединения).
Примечание 2: вы можете указать UUID (здесь 441085a4-4155-417b-ad8f-78a888d89988 ) вместо имени сетевого подключения.
Примечание 3: после перезагрузки соединение по-прежнему перезапускается автоматически, для свойства connection. autoconnect установлено значение yes , что эквивалентно ONBOOT = yes .

Чтобы начать сетевое соединение (здесь net-eth0 ), введите:

 #  nmcli con up net-eth0 
Соединение успешно активировано (активный путь D-Bus: / org / freedesktop / NetworkManager / ActiveConnection / 1)
 

Примечание. Как и раньше, вы можете указать UUID (здесь 441085a4-4155-417b-ad8f-78a888d89988 ) вместо имени сетевого подключения.

Чтобы предотвратить перезапуск соединения (здесь net-eth0 ) после перезагрузки, введите:

 #  nmcli con mod net-eth0 connection.autoconnect no  

Примечание: mod - это ярлык для модификации .

Чтобы изменить IP-адрес и шлюз по умолчанию для соединения net-eth0 на 192.168.2.10/24 и 192.168. 2.1 соответственно, введите:
In RHEL 7.0 :

 #  nmcli с модом net-eth0 ipv4.адреса "192.168.2.10/24 192.168.2.1 "
#  nmcli con mod net-eth0 ipv4.method manual
  #  nmcli для подключения net-eth0 
Соединение успешно активировано (активный путь D-Bus: / org / freedesktop / NetworkManager / ActiveConnection / 2) 

с RHEL 7.1 по:

 #  nmcli con mod net-eth0 ipv4.addresses 192.168.2.10/24
  #  nmcli с модом net-eth0 ipv4.gateway 192.168.2.1
  #  nmcli с модом net-eth0 ipv4.методическое руководство 
#  nmcli con up net-eth0 
Соединение успешно активировано (активный путь D-Bus: / org / freedesktop / NetworkManager / ActiveConnection / 2) 

Внимание : Команда nmcli con mod net-eth0 ipv4.addresses «192.168.2.10/24 192.168.2.1» с пробелом между IP-адресом и шлюзом по умолчанию, все в кавычках , работала в RHEL 7. 0 / CentOS 7.0 , но не в RHEL 7.1 / CentOS 7.1 и новее из-за изменений NetworkManager ( v0.9.9.1 -> v1.0.0 ).
Примечание 1: вы можете использовать синтаксис + ipv4.addresses или -ipv4.addresses , чтобы соответственно добавить другие IP-адреса или удалить некоторые ранее установленные (включая начальный).
Примечание 2: синтаксис отличается от того, который вы использовали для первоначальной установки соединения с ip4 и gw4 .
Примечание 3: Согласно документации nmcli RedHat, файл ipv4.Свойство method может иметь разные значения: auto означает, что для интерфейса будет использоваться соответствующий автоматический метод (DHCP, PPP и т.д.), link-local относится к локальному адресу ссылки в диапазоне 169.254 / 16, который будет быть назначенным интерфейсу, manual означает, что используется статическая IP-адресация, и по крайней мере один IP-адрес должен быть указан в свойстве Address , shared указывает, что соединение предоставит сетевой доступ к другим компьютерам, и интерфейс будет присвоил адрес в 10. 42.x.1 / 24 с запущенным DHCP-сервером и DNS-сервером переадресации, а интерфейс настроен через NAT для текущего сетевого подключения по умолчанию, отключен. означает, что IPv4 не будет использоваться в этом подключении.

В выпуске RHEL 7.3 NetworkManager теперь выполняет проверку для обнаружения повторяющихся адресов IPv4 при активации нового соединения. Если адрес в локальной сети уже назначен, активация соединения не выполняется. По умолчанию эта функция отключена, но вы можете включить ее с помощью IPv4 .dad-timeout или переменная ARPING_WAIT в файлах ifcfg .

Чтобы назначить подключение net-eth0 к зоне work , введите:

 #  firewall-cmd --permanent --zone = work --change-interface = eth0
  успех
#  nmcli con mod net-eth0 connection.zone работа
  #  nmcli для подключения net-eth0
  Соединение успешно активировано (активный путь D-Bus: / org / freedesktop / NetworkManager / ActiveConnection / 3) 

Примечание 1: Вместо использования команды nmcli con mod вы также можете отредактировать файл / etc / sysconfig / network-scripts / ifcfg-eth0 (здесь для сетевого интерфейса eth0 ), добавить ZONE = рабочий оператор и перезапустите сетевой интерфейс с помощью команды nmcli con up net-eth0 .
Примечание 2: Дополнительные сведения о команде firewall-cmd и концепции зоны см. На странице «Приступая к работе с Firewalld».

Конфигурация имени хоста

В RHEL 7 существует три типа имен хостов: статических , довольно и переходных .
«Статическое имя хоста , - это традиционное имя хоста, которое может быть выбрано пользователем и хранится в файле / etc / hostname . Временное имя хоста - это динамическое имя хоста, поддерживаемое ядром.По умолчанию он инициализируется статическим именем хоста, значение которого по умолчанию - localhost . Его можно изменить с помощью DHCP или mDNS во время выполнения. Имя хоста pretty - это имя хоста UTF8 в свободной форме для представления пользователю ». Источник: Руководство по сети RHEL 7.

Чтобы получить имена хостов серверов, введите:

 #  hostnamectl 
   Статическое имя хоста: centos7.example.com
         Название иконки: компьютер
           Шасси: н / д
        Идентификатор машины: 8f56e45764474b668b0db97b4127a01b
           ID загрузки: 2ae7e6c78331414b82aa89a0ffcfa9fa
    Виртуализация: kvm
  Операционная система: CentOS Linux 7 (Core)
       Имя ОС CPE: cpe: / o: centos: centos: 7
            Ядро: Linux 3.10.0-123.el7.x86_64
      Архитектура: x86_64
 

В качестве альтернативы вы можете использовать команду hostname , чтобы получить только имя хоста (это читает файл / etc / hostname ):

 #  имя хоста 
centos7.example.com 

Примечание: вы даже можете получить тот же результат с помощью команды nmcli gen host .

Чтобы навсегда назначить серверу имя хоста rhel7 , введите:

 #  hostnamectl set-hostname rhel7  

Примечание 1. С этим синтаксисом все три имени хоста ( статический , довольно и переходный ) принимают значение rhel7 одновременно.Тем не менее, можно установить три имени хоста отдельно, используя параметры –pretty , –static и –transient .
Примечание 2: Команда nmcli gen host rhel7 даст тот же результат.

Внимание: В выпуске RHEL 7.3 NetworkManager теперь использует службу systemd-host named для чтения и записи статического имени хоста, которое хранится в файле / etc / hostname .Из-за этого изменения ручные изменения, внесенные в файл / etc / hostname , больше не обрабатываются автоматически NetworkManager . Пользователи должны изменить имя хоста системы с помощью утилиты hostnamectl . Кроме того, теперь не рекомендуется использовать переменную HOSTNAME в файле / etc / sysconfig / network .

Разрешение имени хоста

Разрешение имени хоста

основывается на файле /etc/nsswitch.conf , где по умолчанию вы можете найти следующую строку:

  хосты: файлы dns  

Это означает, что разрешение имени хоста сначала выполняется с помощью файлов (статическое разрешение ), затем dns (разрешение динамическое ).

Разрешение статического имени хоста происходит через файл / etc / hosts :

  192.168.1.10 centos7.example.com centos7  

Примечание: Всегда указывайте IP-адрес, F ull Q ualified D omain N и, возможно, некоторые псевдонимы в этом порядке, иначе некоторые службы, такие как Kerberos , не будут работать!

Разрешение динамического имени хоста основано на файле / etc / resolv. conf файл:

  # Создано NetworkManager
поиск example.com
сервер имен 192.168.1.1  

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

Чтобы добавить DNS-сервер (здесь 8.8.8.8 ) в конфигурацию соединения (здесь net-eth0 ), введите:

 #  nmcli с модом net-eth0 + ipv4.DNS 8.8.8.8 
#  nmcli con up net-eth0 
Соединение успешно активировано (активный путь D-Bus: / org / freedesktop / NetworkManager / ActiveConnection / 4)
#  подробнее /etc/resolv.conf 
# Создано NetworkManager
поиск example.com
сервер имен 192.168.1.1
  сервер имен 8.8.8.8 
 

Примечание 1. Используйте + ipv4.dns , чтобы добавить новый DNS-сервер , -ipv4. dns , чтобы удалить DNS-сервер и ipv4.dns для замены текущего сервера DNS .
Примечание 2: изменение только происходит после соединение перезапускается.
Примечание 3: используйте параметр ipv4.dns-search , чтобы изменить имя домена, если необходимо. Будьте осторожны, чтобы установить правильное полное доменное имя перед командой hostnamectl set-hostname .

Чтобы добавить доменное имя в список поиска (здесь example2.com ), введите:

 #  nmcli с модом net-eth0 + ipv4.dns-search example2.com 
#  nmcli con up net-eth0 
Соединение успешно активировано (активный путь D-Bus: / org / freedesktop / NetworkManager / ActiveConnection / 5)
#  подробнее /etc/resolv.conf 
# Создано NetworkManager
поиск  example2.com  example.com
сервер имен 192. 168.1.1
сервер имен 8.8.8.8 

Невозможно удалить сервер DNS , предоставленный через DHCP , с помощью предыдущей команды (с -ipv4.dns ), вы получите следующее сообщение об ошибке: «Ошибка: не удалось удалить значение из ipv4.dns: свойство не содержит DNS-сервер« 192.168.1.1 »». .
Если вы хотите установить свою собственную конфигурацию DNS в этом контексте, введите:

 #  nmcli con mod net-eth0 ipv4.ignore-auto-dns да  

Примечание: Вы получите тот же результат, указав PEERDNS = no в файлах конфигурации сети.

с RHEL 7.3 имеет свойство ipv4.dhcp-timeout или параметр IPV4_DHCP_TIMEOUT в файлах ifcfg . В результате NetworkManager теперь ожидает ответа от DHCP-сервера только в течение заданного времени.

Дополнительные ресурсы

Вы можете посмотреть видео Ralph Nyberg о настройке конфигурации сети (15 мин. / 2015).
Вы также можете посмотреть презентацию Берта Ван Врекема об устранении неполадок сетевых служб на EL7 (38 мин / 2018) (док),

Помимо целей экзамена, вас может заинтересовать настройка сетевого интерфейса 10 ГБ.
IBM написала документ об отключении IPv6 в RHEL 7.

Адресация

IPv4 - Основы адресации IPv4 ⋆ IpCisco

Адресация IPv4

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

Давайте начнем с распределения IP-адресов и посмотрим, откуда эти ценные числа поступают на наши устройства.


Как контролируются IP-адреса?

IP-адреса контролируются и распределяются IANA (Internet Assigned Numbers Authority) . Этот орган предоставляет IP-адреса региональным интернет-регистратурам (RIR) , и они распространяют их по регионам или континентам, за которые он несет ответственность.

В мире существует 5 различных региональных интернет-реестров (RIR) . Эти RIR:

  • RIPE NCC (Сетевой координационный центр Réseaux IP Européens)
  • APNIC (Азиатско-Тихоокеанский сетевой информационный центр)
  • AFRINIC (Африканский сетевой информационный центр)
  • ARIN (Американский реестр интернет-номеров)
  • ACNIC (Реестр интернет-адресов Латинской Америки и Карибского бассейна)

В настоящее время существует две версии IP-адресов.Это:

Как мы уже говорили, в этом уроке мы сосредоточимся на IPv4. IPv6 объясняется в другой серии уроков.


Адреса IPv4

Адреса IPv4 - это 32 бита (8 байтов) адресов. Эти адреса отображаются с четырьмя десятичными числами, разделенными точками, например 192.168.2.1.

Здесь все десятичные числа могут быть от 0 до 255 . Это основная математика.Если у вас есть 8 бит для каждого числа, вы можете получить число от 0 до 255.

Мы подробно поговорим об этом в этом уроке.

IP-адреса состоят из двух частей. Первая часть - это сетевая часть, а вторая - хост-часть. Это определяется в соответствии с маской подсети.

Маска подсети также представляет собой серию чисел, такую ​​как IP-адрес, которая показывает сетевую часть IP-адреса. Маски подсети используются вместе с IP-адресами.Маска подсети может иметь вид 255.255.255.0. В двоичном виде это 11111111.11111111.11111111.00000000. Здесь единицы представляют сторону сети. 0 представляют сторону хоста.

Без Маски подсети мы не можем знать, какой сети принадлежит этот IP-адрес. Мы подробно поговорим об этом с Subnetting .


Вы также можете проверить Шпаргалку по подсетям , чтобы получить помощь по подсетям.


Давайте покажем это с IP-адресом 192.168.2.1. Например, мы будем использовать маску подсети 255.255.255.0 . Записанный двоичный код этой маски подсети выглядит как 11111111.11111111.11111111.00000000 . Это говорит о том, что первые 3 октета (первые 24 бита) показывают сетевую часть. Потому что там полно единиц. Последний октет заполнен нулями. И шоу хозяев. 1 для сети, а 0 для хост-устройств в этой сети.

Итак, в последнем случае мы можем сказать, что все устройства в этой сети будут использовать одну и ту же сетевую часть (192.168,2 ).

Но часть хоста может изменяться от 0 до 255, как показано ниже:

192.168.2.0
192.168.2.1
192.168.2.2
192.168.2.3
….
192.168.2.255

Здесь;

  • Первый адрес 192. 168.2.0 - это сетевой адрес.
  • Последний адрес 192.168.2.255 - это широковещательный адрес.
  • Другие адреса от 192.168.2.1 до 192.168.2.254 могут использоваться для устройства в той же сети.


Классы IP-адресов

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

Что это за классы IP-адресов , и диапазоны IP-адресов? Это:

класс A (от 1.0.0.0 до 126.255.255.255)
класс B (от 128.0.0.0 до 191.255.255.255)
класс C (от 192.0.0.0 до 223.255.255.255)
, класс D (от 224.0.0.0 до 239.255.255.255)
, класс E (от 240.0.0.0 до 254.255.255.255)

Сетевая и узловая части этих сетей:

Class A имеет сети 126 (первый октет). Остальное используется для хостов.
Класс B имеет 16 384 сетей (первый и второй октеты). Остальное используется для хостов.
Класс C имеет сети 2 097 152 (первый, второй и третий октеты).Остальное используется для хостов.
Класс D используется для операций Multicast .
Класс E - зарезервированный класс .

Здесь адреса 0.0.0.0, 127.0.0.0 и 255.255.255.255 зарезервированы для различных ролей. Эти зарезервированные роли адресов:

  • 0.0.0.0 - используются для маршрутов по умолчанию
  • 127.0.0.0 - используются для обратной связи
  • 255.255.255.255 - используются для широковещательной передачи

Этот бесклассовый IP-адрес это только теоретическая информация для вас.На самом деле вы не можете увидеть эти классы.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *