По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет, друг! Сегодня в статье мы расскажем, как рассчитать IP-адрес подсети с помощью инструмента ipcalc.
При управлении сетью, несомненно, придется иметь дело с подсетями. Некоторые сетевые администраторы могут довольно быстро выполнять двоичные вычисления, чтобы определить маску подсети. Тем не менее, другим может потребоваться некоторая помощь, и здесь инструмент ipcalc очень пригодится.
Ipcalc на самом деле делает намного больше - он принимает на вход IP-адрес и маску сети и на выходе вы получаете адрес сети, Cisco wildcard маску, широковещательный адрес, минимальный и максимальный хост и общее количество хостов. Вы также можете использовать его в качестве учебного пособия для представления результатов подсетей в простых для понимания двоичных значениях.
Некоторые из применений ipcalc:
Проверить IP-адрес
Показать рассчитанный широковещательный адрес
Отображение имени хоста, определенного через DNS
Показать сетевой адрес или префикс
Как установить ipcalc в Linux
Чтобы установить ipcalc, просто запустите одну из приведенных ниже команд в зависимости от используемого дистрибутива Linux.
$ sudo apt install ipcalc
Пакет ipcalc должен автоматически устанавливаться в CentOS / RHEL / Fedora, и он является частью пакета initscripts, но если по какой-то причине он отсутствует, вы можете установить его с помощью:
# yum install initscripts #RHEL/CentOS
# dnf install initscripts #Fedora
Как использовать ipcalc в Linux
Ниже вы можете увидеть несколько примеров использования ipcalc.
Получить информацию о сетевом адресе:
# ipcalc 192.168.20.0
Результат примера:
Address: 192.168.20.0 11000000.10101000.00010100. 00000000
Netmask: 255.255.255.0 = 24 11111111.11111111.11111111. 00000000
Wildcard: 0.0.0.255 00000000.00000000.00000000. 11111111
=>
Network: 192.168.20.0/24 11000000.10101000.00010100. 00000000
HostMin: 192.168.20.1 11000000.10101000.00010100. 00000001
HostMax: 192.168.20.254 11000000.10101000.00010100. 11111110
Broadcast: 192.168.20.255 11000000.10101000.00010100. 11111111
Hosts/Net: 254 Class C, Private Internet
Рассчитайте подсеть для 192.168.20.0/24.
# ipcalc 192.168.20.0/24
Результат:
Address: 192.168.20.0 11000000.10101000.00010100. 00000000
Netmask: 255.255.255.0 = 24 11111111.11111111.11111111. 00000000
Wildcard: 0.0.0.255 00000000.00000000.00000000. 11111111
=>
Network: 192.168.20.0/24 11000000.10101000.00010100. 00000000
HostMin: 192.168.20.1 11000000.10101000.00010100. 00000001
HostMax: 192.168.20.254 11000000.10101000.00010100. 11111110
Broadcast: 192.168.20.255 11000000.10101000.00010100. 11111111
Hosts/Net: 254 Class C, Private Internet
Рассчитайте одну подсеть с 10 хостами:
# ipcalc 192.168.20.0 -s 10
Результат:
Address: 192.168.20.0 11000000.10101000.00010100. 00000000
Netmask: 255.255.255.0 = 24 11111111.11111111.11111111. 00000000
Wildcard: 0.0.0.255 00000000.00000000.00000000. 11111111
=>
Network: 192.168.20.0/24 11000000.10101000.00010100. 00000000
HostMin: 192.168.20.1 11000000.10101000.00010100. 00000001
HostMax: 192.168.20.254 11000000.10101000.00010100. 11111110
Broadcast: 192.168.20.255 11000000.10101000.00010100. 11111111
Hosts/Net: 254 Class C, Private Internet
1. Requested size: 10 hosts
Netmask: 255.255.255.240 = 28 11111111.11111111.11111111.1111 0000
Network: 192.168.20.0/28 11000000.10101000.00010100.0000 0000
HostMin: 192.168.20.1 11000000.10101000.00010100.0000 0001
HostMax: 192.168.20.14 11000000.10101000.00010100.0000 1110
Broadcast: 192.168.20.15 11000000.10101000.00010100.0000 1111
Hosts/Net: 14 Class C, Private Internet
Needed size: 16 addresses.
Used network: 192.168.20.0/28
Unused:
192.168.20.16/28
192.168.20.32/27
192.168.20.64/26
192.168.20.128/25
Если вы хотите убрать двоичный вывод, вы можете использовать опцию -b, как показано ниже.
# ipcalc -b 192.168.20.100
Результат:
Address: 192.168.20.100
Netmask: 255.255.255.0 = 24
Wildcard: 0.0.0.255
=>
Network: 192.168.20.0/24
HostMin: 192.168.20.1
HostMax: 192.168.20.254
Broadcast: 192.168.20.255
Hosts/Net: 254 Class C, Private Internet
Чтобы узнать больше об использовании ipcalc, вы можете использовать:
# ipcalc --help
# man ipcalc
В первой части статей о протоколе Border Gateway Protocol (BGP) мы узнали и разобрали протокол BGP, а затем изучили типы сообщений BGP и состояния соседства. Сегодня, в этой статье, вы узнаете об одном из самых сложных аспектов BGP: как он принимает решение о выборе маршрута.
В то время как протоколы маршрутизации, такие как RIP, OSPF и EIGRP, имеют свои собственные метрики, используемые для выбора «лучшего» пути к целевой сети, BGP использует коллекцию атрибутов пути (PAs).
Предыдущие статьи цикла про BGP:
Основы протокола BGP
Видео: Основы BGP за 7 минут
BGP- атрибуты пути (Path Attributes)
Когда ваш спикер BGP получает BGP префикс, к нему будет прикреплено множество атрибутов пути, и мы знаем, что они будут иметь решающее значение, когда речь заходит о том, чтобы BGP выбрал самый лучший путь к месту назначения.
Все атрибуты BGP- маршрута, делятся на четыре основные категории.
Well-Known Mandatory
Well-Known Discretionary
Optional Transitive
Optional Non-Transitive
Обратите внимание, что две категории начинаются с термина Well-Known. Well-Known означает, что все маршрутизаторы должны распознавать этот атрибут пути. Две другие категории начинаются с термина Optional. Optional означает, что реализация BGP на устройстве вообще не должна распознавать этот атрибут.
Тогда у нас есть термины mandatory и discretionary, связанные с термином Well-Known. Mandatory означает, что обновление должно содержать этот атрибут. Если атрибута нет, тогда появится сообщение об ошибке уведомления, и пиринг будет удален. Discretionary, конечно, будет означать, что атрибута не должно быть в обновлении.
У необязательных категорий атрибутов есть- транзитивные и нетранзитивные. Если он транзитивен, то устройство должно передать этот атрибут пути своему следующему соседу. Если он не является транзитивным, то может просто игнорировать это значение атрибута.
Пример 1 показывает проверку нескольких атрибутов пути для префикса, который был получен маршрутизатором TPA1 от маршрутизатора ATL. Обратите внимание, что мы используем команду show ip bgp для просмотра этой информации, которая хранится в базе данных маршрутизации BGP. В частности, этот вывод показывает атрибуты Next Hop, Metric (MED), LocPrf (Local Preference), Weight, и Path (AS Path).
TPA1#show ip bgp
BGP table version is 4, local router ID is 10.10.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale
Origin codes^ I – IGP, e – EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 100.100.100.0/24 10.10.10.2 0 200 i
Атрибут Origin
Атрибут ORIGIN в BGP-это попытка записать, откуда пришел префикс. Существует три возможности, когда речь заходит о происхождении этого атрибута: IGP, EGP и Incomplete. Как видно из легенды примера 1, коды, используемые Cisco для этих источников, являются i, e, и ?. Для префикса, показанного в примере 1, можно увидеть, что источником является IGP. Это указывает на то, что префикс вошел в эту топологию благодаря сетевой команде внутри конфигурации этого исходного устройства. Далее в этой статье мы рассмотрим сетевую команду во всей ее красе. Термин IGP здесь предполагает, что префикс произошел от записи протокола внутреннего шлюза (Gateway Protocol). Допустим, у нас есть префикс в нашей таблице маршрутизации OSPF, а затем мы используем сетевую команду внутри BGP, чтобы поместить его в экосистему BGP. Конечно, IGP - не единственный источник префиксов, которые могут нести этот атрибут. Например, вы можете создать локальный интерфейс обратной связи на устройстве, а затем использовать сетевую команду для объявления этого локального префикса в BGP.
EGP ссылается на ныне устаревший протокол внешнего шлюза (Exterior Gateway Protocol), предшественник BGP. В результате вы не увидите этот исходный код.
Incomplete означает, что BGP не уверен в том, как именно префикс был введен в топологию. Наиболее распространенным сценарием здесь является то, что префикс был перераспределен в Border Gateway Protocol из какого-то другого протокола, обычно IGP.
Возникает вопрос, почему исходный код имеет такое значение. Ответ заключается в том, что это ключевой фактор, когда BGP использует свой алгоритм для выбора наилучшего пути к месту назначения в сети. Он может разорвать «связи» между несколькими альтернативными путями в сети. Мы также уделяем этому атрибуту большое внимание, потому что это действительно один из хорошо известных, обязательных атрибутов, которые должны существовать в наших обновлениях.
Атрибут AS Path
AS Path - это well-known mandatory атрибут. Он очень важен для наилучшего поиска пути, а также для предотвращения петель внутри Border Gateway Protocol.
Рассматривая нашу топологию, показанную на рисунке 1, рассмотрим префикс, возникший в TPA. Обновление отправляется в TPA1, и TPA не добавляет свой собственный AS 100 в AS Path, так как сосед, которому он отправляет обновление, находится в своем собственном AS в соответствии с пирингом iBGP.
Когда TPA1 отправляет обновления на ATL, он добавляет номер 100 в обновления. Следуя этой логике, ATL отправит обновления на ATL2 и не будет добавлять свой собственный номер в качестве AS. Это будет работать до тех пор, пока ATL2 не отправит обновления на какой-то другой AS, предшествующий AS 200. Это означает, что, когда мы рассматриваем образец AS path, как показано в примере 2, крайним правым в пути является AS, который первым создал префикс (100), а крайним левым- AS, который доставил префикс на локальное устройство (342).
Пример 2: Пример BGP AS Path
Атрибут Next Hop
На самом деле нет ничего удивительного в том, что префикс BGP имеет атрибут под названием Next Hop. В конце концов, маршрутизатор должен знать, куда отправлять трафик для этого префикса. Next Hop атрибут удовлетворяет эту потребность. Интересным моментом здесь, однако, является тот факт, что Next Hop в BGP работает не так же, как это происходит в большинстве IGP. Также следует отметить, что правила меняются, когда вы рассматриваете iBGP в сравнении с eBGP.
При рассмотрении протокола внутреннего шлюза, когда устройство отправляет обновление своему соседу, значением Next Hop по умолчанию является IP-адрес интерфейса, с которого отправляется обновление. Этот параметр продолжает сбрасываться каждым маршрутизатором по мере прохождения обновления через топологию. Next Hop принимает простую парадигму «hop-by-hop».
С помощью BGP, когда у нас есть пиринг eBGP и отправляется префикс, Next Hop действительно будет (по умолчанию) IP-адресом спикера eBGP, отправляющего обновление. Однако IP-адрес этого спикера eBGP будет сохранен в качестве Next Hop, поскольку префикс передается от спикера iBGP к спикеру iBGP. Очень часто мы видим атрибут Next Hop, являющийся IP-адресом, который не является устройством, передавшим нам обновление. Это действительно адрес, который представляет собой соседний AS, который предоставил нам префикс. Таким образом, правильно думать о BGP как о протоколе «AS-to-AS» вместо протокола «hop-to-hop».
Это может вызвать определенные проблемы. Основной вывод состоит в том, что вы должны гарантировать, что все ваши спикеры BGP могут достичь значения Next Hop указанного в атрибуте, чтобы путь считался допустимым. Иначе говоря, спикеры BGP будут считать префикс недопустимым, если они не смогут достичь значения Next Hop.
К счастью, эту проблему можно обойти. Вы можете взять устройство iBGP и проинструктировать его, установив себя в качестве значения Next Hop всякий раз, когда вам это нужно. Это делается с помощью манипуляции пирингом командой neighbor, как показано в примере 3.
ATL (config)# router bgp 200
ATL (config-router)# neighbor 10.10.10.1 next-hop-self
Атрибут BGP Weight (веса)
Weight (вес) - это очень интересный атрибут BGP, так как он специфичен для Cisco. Хорошая новость заключается в том, что, поскольку Cisco является гигантом в отрасли сетей, то многие другие производители будут поддерживать использование Weight в качестве атрибута.
Weight также является одним из самых уникальных атрибутов, поскольку это значение не передается другим маршрутизаторам. Weight - это значение, которое присваивается нашим префиксам как локально значимое значение. Weight - это простое число в диапазоне от 0 до 65535, и чем выше значение веса, тем выше предпочтение этого пути. Когда префикс генерируется локально, он будет иметь вес 32768. В противном случае вес префикса по умолчанию равен 0.
Как можно использовать вес? Поначалу это покажется странным, так как он не передается другим спикерам BGP. Однако все просто. Допустим, ваш маршрутизатор получает один и тот же префикс от двух разных автономных систем, с которыми он работает. Если администратор хочет предпочесть один из путей по какой-либо причине, он может манипулировать локальным значением веса на предпочтительном пути и мгновенно влиять на процесс принятия решения о наилучшем пути BGP.
BGP Best Path (выбор лучшего пути)
Как было сказано ранее, мы знаем, что у IGP есть метрическое значение, которое является ключевым для определения наилучшего пути к месту назначения. В случае с OSPF эта метрика основана на стоимости, которая основана на пропускной способности. У BGP существует множество атрибутов пути, которые может иметь префикс. Все они поддаются алгоритму выбора наилучшего пути BGP. На рисунке 2 показаны шаги (начиная сверху), которые используются в выборе наилучших путей Cisco BGP.
Изучая эти критерии выбора пути, вы можете сразу же задаться вопросом, почему он должен быть таким сложным. Помните, когда мы имеем дело с чем-то вроде интернета, мы хотим, чтобы было как можно больше регулировок для политики BGP. Мы хотим иметь возможность контролировать, насколько это возможно, как префиксы используются совместно и предпочтительно в такой большой и сложной сети.
Подключаем точку доступа к сети с DHCP сервером, узнаем IP адрес и подключаемся к ней по SSH. Логин/пароль: ubnt/ubnt. Далее запускаем обновление прошивки на точке доступа. Для этого переходим по ссылке https://www.ui.com/download/unifi и выбираем модель оборудования. В разделе Firmware нажимаем на значок закачки, принимаем условия лицензии и нажимаем на Copy url:
После этого в терминале вводим команду:
upgrade https://dl.ui.com/unifi/firmware/U7PG2/4.3.20.11298/BZ.qca956x.v4.3.20.11298.200704.1347.bin
Данная команда скачает прошивку и запустит обновление.
Шаг №2
Поднимаем контроллер на виртуальной машине. В качестве ОС выбираем Linux Debian 9, и устанавливаем Ubuntu 18.04 Server. Рекомендую на DNS сервере создать A запись для контроллера. Что-то вроде unifics.domain.com. Даем доступ серверу в Интернет. Подключаемся к серверу и вводим следующие команды:
sudo apt-get update && sudo apt-get install ca-certificates apt-transport-https
echo 'deb https://www.ui.com/downloads/unifi/debian stable ubiquiti' | sudo tee /etc/apt/sources.list.d/100-ubnt-unifi.list
wget -qO - https://www.mongodb.org/static/pgp/server-3.4.asc | sudo apt-key add -
echo "deb https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list
sudo apt-get update
sudo wget -O /etc/apt/trusted.gpg.d/unifi-repo.gpg https://dl.ui.com/unifi/unifi-repo.gpg
sudo apt-get update && sudo apt-get install unifi –y
Контроллер установлен. Состояние контроллера можно проверить следующей командой:
sudo service unifi status
Остановка, запуск и перезапуск:
sudo service unifi status
sudo service unifi start
sudo service unifi restart
Шаг №3
Теперь нужно подружить точки доступа с нашим контроллером. Для этого в Google Chrome скачиваем расширение Uni-Fi Discovery Tool.
Чтобы утилита определила подключенные к сети точки доступа (Access Point AP), компьютер с запущенной утилитой и AP должны находиться в одной подсети. Запускаем утилиту, нажимаем на кнопочку UniFi Family. Утилита найдет все устройства UniFi в сети. Нажимаем кнопку Action. Внимание, с первого раза кнопка может на отработать, так как там работает Java, поэтому стоит подождать. Далее в открывшемся окне в строке Inform URL вбиваем доменное имя нашего контроллера. Все остальное (порт, протокол) не меняем!
Шаг №4
Переходим на https://account.ui.com/register и регистрируемся в Облаке Uni-Fi. Это необходимо для удаленного управления устройствами с любой точки мира.
Шаг №5
Затем в браузере - рекомендуется Google Сhrome, открываем панель управления нашего новоиспеченного контроллера: https://unifics.domain.com:8443. У нас запросит название нашего сайта, то бишь Wi-Fi домена. Нажимаем Next. Вводим логин и пароль от облачного аккаунта, который зарегистрировали на предыдущем шаге:
Нажимаем Next. Контроллер отобразит точки доступа в сети, благодаря действия, которые проделали на третьем этапе (никакой магии).
Нажимаем Next. Задаем название (SSID) и пароль Wi-Fi сети. Всё это можно будет поменять. Переключатель Combine 2.4 GHz и 5 GHz Wi-Fi Network Names into one не трогаем.
Нажимаем Next. Выбираем часовой пояс, страну и нажимаем Finish. Контроллер начнёт применять изменения на точку доступа.
Шаг №6
Переходим в настройки кликнув на значок шестеренки в левом нижнем углу панели управления контроллером. В строке Controller Hostname/IP прописываем доменное имя нашего контроллера и обязательно ставим галочку перед Override inform host with controller hostname/IP.
Шаг №7
При добавлении новой точки доступа выполняем первый и третий шаг для каждого устройства. Затем среди доступных точек доступа появится AP со статусом Pending. Выбираем устройство и нажимаем Adopt. Контроллер применит все настройки на новое устройство.