Secondary ip address что это
Primary и secondary IPv4 адреса на интерфейсех ESR
Рассмотрим пример конфигурации нескольких IPv4 адресов на одном порту (возможно внести до 8-ми адресов):
interface gigabitethernet 1/0/20
ip firewall disable
ip address 192.0.2.1/24
ip address 192.0.2.254/24
ip address 192.0.2.10/30
exit
Все IPv4 адреса, принадлежащие разным подсетям, будут являться primary. В нашем примере это 192.0.2.1 и 192.0.2.10.
Если на интерфейсе включить VRRP, без указания source ip, например:
interface gigabitethernet 1/0/20
ip firewall disable
ip address 192.0.2.1/24
ip address 192.0.2.254/24
ip address 192.0.2.10/30
vrrp id 100
vrrp ip 192.0.2.2
vrrp
exit
То в качестве адреса источника vrrp ip будет использоваться первый IPv4 адрес с интерфейса, проверим это, используя команду monitor (будем фильтровать по IP адресу назначения,т.к. для VRRP выделен адрес 224.0.0.18):
esr-1000# monitor gigabitethernet 1/0/20 destination-address 224.0.0.18
17:19:13.591043 00:00:5e:00:01:64 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 255, id 18, offset 0, flags [none], proto VRRP (112), length 40)
192.0.2.1 > 224.0.0.18: vrrp 192.0.2.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 100, prio 100, authtype none, intvl 1s, length 20, addrs: 192.0.2.2
17:19:14.592882 00:00:5e:00:01:64 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 255, id 19, offset 0, flags [none], proto VRRP (112), length 40)
192.0.2.1 > 224.0.0.18: vrrp 192.0.2.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 100, prio 100, authtype none, intvl 1s, length 20, addrs: 192.0.2.2
17:19:15.593250 00:00:5e:00:01:64 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 255, id 20, offset 0, flags [none], proto VRRP (112), length 40)
192.0.2.1 > 224.0.0.18: vrrp 192.0.2.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 100, prio 100, authtype none, intvl 1s, length 20, addrs: 192.0.2.2
3 packets captured
3 packets received by filter
0 packets dropped by kernel
Плавающие IP-адреса для организации сети в публичных и частных облаках OpenStack
Недавно я описал, как работает VlanManager и как он обеспечивает масштабируемость сети и изолированность пользователей. Но до настоящего момента я говорил только о сетях с фиксированным IP-адресом, принадлежащих различным пользователям. И хотя по умолчанию экземплярам выделяются фиксированные IP-адреса, они не гарантируют немедленной доступности экземпляров из-за пределов сети (или из других ЦОД). Представьте себе следующий сценарий:
Вы запускаете небольшой веб-сайт с одним www-сервером, сервером базы данных, и брандмауэром, который выполняет трансляцию сетевых адресов (NAT) и фильтрацию трафика. Обычно вы применяете следующие настройки:
-Все серверы общаются внутри сети в рамках частного (немаршрутизируемого) сетевого диапазона (например, 192.168.0.0/24).
-Есть один публичный маршрутизируемый IP-диапазон, на котором виден www-сервер.
Вы делаете следующее:
-Присваиваете брандмауэру публичный IP-адрес.
-Создаете правило NAT на брандмауэре для маршрутизации трафика с публичного IP-адреса на частный IP-адрес www-сервера.
Фиксированные IP-адреса в OpenStack работают так же, как и сетевой диапазон 192.168.0.0/24 в примере выше. Они гарантируют только взаимодействие между экземплярами внутри одного кластера OpenStack. Но OpenStack также вводит другой пул IP-адресов под названием “плавающие IP-адреса”. Плавающие IP-адреса — это публично маршрутизируемые IP-адреса, которые вы покупаете у провайдера интернет-услуг (того, который помещается в указанный выше брандмауэр). Пользователи могут назначать IP-адреса своим экземплярам, делая их доступными из внешней сети.
Различия между плавающими и фиксированными IP-адресами
Плавающие IP-адреса не назначаются виртуальным машинам по умолчанию. Пользователи облака должны явным образом “взять” их из пула, настроенного администратором OpenStack, а затем назначить их своим виртуальным машинам. Как только пользователь забрал плавающий IP-адрес из пула, он становится его “владельцем” (то есть в любой момент он может открепить IP-адрес от виртуальной машины и прикрепить его к другой). Если виртуальная машина по каким-то причинам прекращает существование, пользователь не теряет плавающий IP-адрес — он может его затем назначить другому экземпляру. К сожалению, сейчас невозможно совместно использовать один плавающий IP-адрес несколькими виртуальными машинами для балансировки нагрузки, как например с эластичной балансировкой нагрузки на Amazon EC2.
С другой стороны фиксированные IP-адреса назначаются динамически компонентом nova-network при загрузке ВМ. Нет возможности приказать OpenStack назначить конкретный фиксированный IP-адрес виртуальной машине. Таким образом, вы можете оказаться в ситуации, когда при случайном завершении работы виртуальной машины после её восстановления из снимка новый экземпляр загружается с новым фиксированным IP-адресом.
Системные администраторы могут настраивать несколько пулов плавающих IP-адресов. Тем не менее, в отличие от пулов фиксированных IP-адресов, пулы плавающих IP-адресов нельзя соотнести с конкретными пользователями. Каждый пользователь может “взять” плавающий IP-адрес из любого пула плавающих IP-адресов. Но основная мотивация для создания нескольких пулов плавающих IP-адресов в том, чтобы каждый пул обслуживал свой поставщик доступа в интернет. Таким образом, мы можем гарантировать возможность подключения, даже при сбое у одного из поставщиков.
В итоге основные функции плавающих IP-адресов следующие:
-Плавающие IP-адреса не назначаются виртуальным машинам автоматически по умолчанию (их необходимо назначать инстансам вручную).
-Если виртуальная машина прекращает свое существование, пользователь может повторно использовать плавающий IP-адрес, назначив его другому инстансу.
-Пользователи могут брать плавающие IP-адреса из различных пулов, определяемых администратором облака, чтобы обеспечить возможность подключения к виртуальным машинам разными поставщиками интернет-услуг или из внешних сетей.
Плавающие IP-адреса—внутренние или внешние облака
“Публичная доступность” плавающего IP-адреса – это относительное понятие. Для публичных облаков вы, возможно, захотите определить пул плавающих IP-адресов как пул IP-адресов, публично доступных из интернета. Затем ваши клиенты смогу назначать их виртуальным машинам, чтобы заходить в них через SSH со своих домашних или рабочих компьютеров:
Если в вашем ЦОД запущено корпоративное облако, то пул плавающих IP-адресов может быть любым диапазоном IP-адресов, который предоставляет доступ к инстансам OpenStack из остального ЦОД.
Для трафика своего ЦОД вы можете определить следующий диапазон: 10.0.0.0/16.
Внутри OpenStack вы можете создать следующий диапазон фиксированных IP-адресов: 192.168.0.0/16, разбитый на подсети пользователей.
Чтобы сделать экземпляры OpenStack доступными из всего ЦОД вы можете определить пул плавающих IP-адресов как подсеть 10.0.0.0/8, (например, 10.0.0.0/16) и зарегистрировать её в OpenStack, чтобы пользователи могли брать оттуда IP-адреса.
Работа с плавающими IP-адресами
Таким образом, публичный пул становится доступным пользователям.
Теперь пользователи следуют данной процедуре:
-Загрузить экземпляр:
-Перечислить доступные пулы плавающих IP-адресов:
-Взять плавающий IP-адрес из пула “pub” (или при желании из пула “test”):
nova floating-ip-create pub
-Назначить плавающий IP-адрес экземпляру:
nova add-floating-ip 79935433-241a-4268-8aea-5570d74fcf42 172.24.4.225
(где первый аргумент — это uuid экземпляра, а второй – сам плавающий IP-адрес)
-Проверить правильность всех настроек:
Как работают плавающие IP-адреса
Что происходит внутри экземпляра после добавления плавающего IP-адреса? Правильный ответ – ничего. Если вы подключитесь к нему по SSH и посмотрите конфигурацию сети, вы увидите, что существует один интерфейс сети с настроенным фиксированным IP-адресом.
Вся настройка выполняется на вычислительном узле. Вся работа, связанная с плавающим IP-адресом, выполняется сервисом nova-network: организуется транслятор сетевых адресов (NAT) между фиксированным и плавающим IP-адресами экземпляра. Объяснение, как работает NAT, можно найти тут.
Взгляните на следующую диаграмму:
Схема отображает один вычислительный узел, настроенный в режиме сети c распределением узлов и VlanManager, используемый для настраивания фиксированных IP-сетей. Вычислительный узел оснащен двумя сетевыми интерфейсами: интерфейс eth0 выделен для трафика с фиксированным IP/VLAN, а eth1 – это интерфейс, по которому вычислительный узел подключается к внешней сети; в нем располагаются плавающие IP-адреса. (Информацию о том, как VlanManager настраивает фиксированные IP-сети см. в предыдущей статье)
Примите во внимание, что в то время как на интерфейсе eth0 (фиксированном/частном) не настроен адрес, интерфейсу eth1 назначен IP-адрес, который является шлюзом по умолчанию для вычислительного узла (91.207.15.105).
Когда пользователь назначает плавающий IP-адрес (91.207.16.144) инстансу VM_1, происходят две вещи:
-Плавающий IP-адрес настроен как вторичный адрес на интерфейсе eth1: это на выходе команды “ip addr show eth1″, содержащей следующие действия:
inet 91.207.15.105/24 scope global eth1 # primary eth1 ip
inet 91.207.16.144/32 scope global eth1 # floating ip of VM_1
-Код, ответственный за задание правил, располагается в nova/network/linux_net.py в функции:
def floating_forward_rules(floating_ip, fixed_ip):
Возвращаемся к диаграмме. Если пользователь хочет получить доступ к виртуальной машине по своему IP-адресу из внешней сети (например, “ping 91.20.16.144″):
-Трафик достигает публичного интерфейса (eth1) вычислительного узла. В nova-network-PREROUTING выполняется DNAT, меняющий IP-адрес назначения пакетов с 91.207.16.144 на 10.0.0.3.
-Вычислительный узел обращается к своей таблице маршрутизации и видит, что сеть 10.0.0.0 доступна на интерфейсе br100 (за исключением “ip route show” вычислительного узла):
10.0.0.0/24 dev br100
Таким он направляет пакет на интерфейс br100, затем пакет достигает виртуальной машины.
Если виртуальная машина отправляет пакет во внешний мир (например, “ping 8.8.8.8):
-Так как адрес назначения не находится в локальной сети виртуальной машины, пакеты отправляются на шлюз виртуальной машины по умолчанию с IP-адресом 10.0.0.1 (адрес устройства “br100″ на вычислительном узле).
-Вычислительный узел проверяет свои таблицы маршрутизации и обнаруживает, что в непосредственно подключенных сетях нет адреса 8.8.8.8, поэтому он переадресует пакет на шлюз по умолчанию (который является первичным адресом eth1 — 91.207.15.105 в данном случае).
-Пакет попадает в цепочку POSTROUTING и передается цепочке “nova-network-float-snat”, где его исходный IP-адрес переписывается на плавающий IP-адрес (91.207.16.144).
Примечания о безопасности
При использовании OpenStack системные администраторы передают полный контроль за таблицами iptables сервисам nova. Набор настраиваемых правил очень сложен и с легкостью нарушается любым вмешательством извне. Более того, при каждом перезапуске демона nova-network он применяет все правила в цепочках таблиц iptables, связанных с OpenStack. Если есть необходимость каким-либо образом изменить поведение таблиц iptables, это можно сделать, изменив код в соответствующих местах linux_net.py (для правил NAT это будут floating_forward_rules).
Также стоит сказать, что nova-network не отслеживает свои таблицы каким-либо образом. Таким образом, если мы вручную удаляем какие-либо правила из цепочек, связанных с OpenStack, они не восстановятся при следующем запуске nova-network.
Таким образом, весь трафик, направленный на 91.207.16.144, попадает на адрес 10.0.0.3.
Теперь давайте представим, что системный администратор ночью решал проблемы подключения к сети и случайно удалил все правила NAT, напечатав:
iptables –F –t nat
Указанное выше правило NAT было удалено, но интерфейсу eth1 все ещё присвоен вторичный IP-адрес 91.207.16.144. Таким образом, мы всё ещё можем обратиться к адресу 91.207.16.144 извне, но вместо того, чтобы попасть на виртуальную машину, у нас теперь есть доступ к самому вычислительному узлу (IP-адрес назначения более не транслируется по правилу DNAT, так как мы удалили все правила NAT). Эта дыра в безопасности не будет закрыта до следующего перезапуска процесса nova-network, который заново создаст правила.
Настройка плавающих IP-адресов
В сервисе nova.conf существуют флаги, которые влияют на поведение плавающих IP-адресов:
# the interface to which floating ips are attached
# as secondary addresses
public_interface=«eth1»
# the pool from which floating IPs are taken by default
default_floating_pool=«pub»
# we can add a floating ip automatically to every instance that is spawned
auto_assign_floating_ip=false
Итоговые комментарии
Кроме предоставления доступа к виртуальным машинам напрямую из интернета, механизм плавающих IP-адресов дает пользователям облака некоторую гибкость. После “забора” плавающего IP-адреса они могут менять их принадлежность, то есть на ходу назначать их различным виртуальным машинам и переназначать их, что значительно облегчает выпуск нового кода и обновления системы. Для системных администраторов это представляет потенциальную угрозу безопасности, так как лежащий в основе механизм (iptables) работает очень сложно и не отслеживается OpenStack. Поэтому очень важно, чтобы только программное обеспечение OpenStack могло менять политики брандмауэра и чтобы они не менялись вручную.
ARP: Нюансы работы оборудования Cisco и интересные случаи. Часть 1
Привет habr! Каждый будущий инженер в процессе изучения сетевых технологий знакомится с протоколом ARP (Address Resolution Protocol, далее ARP). Основная задача протокола – получить L2 адрес устройства при известном L3 адресе устройства. На заре профессиональной карьеры начинающий специалист, как мне кажется, редко сталкивается с ситуациями, когда нужно вспомнить про существование ARP. Создаётся впечатление, что ARP – это некоторый автономный сервис, не требующий никакого вмешательства в свою работу, и при появлении каких-либо проблем со связью многие по неопытности могут забыть проверить работу ARP.
Я помню свой порядок мыслей, когда я начинал работать сетевым инженером: «Так, интерфейс поднялся, ошибок по физике вроде как не видно. Маршрут, куда слать пакеты, я прописал. Списков доступа никаких нет. Так почему же не идёт трафик? Что маршрутизатору ещё не хватает?» Рано или поздно каждый сетевой инженер столкнётся с проблемой, причина которой будет лежать именно в особенностях работы/настройки ARP на сетевом оборудовании. Простейший пример: смена шлюза на границе сети (например, вместо сервера MS TMG устанавливаем маршрутизатор). При этом конфигурация маршрутизатора была проверена заранее в лабораторных условиях. А тут, при подключении к провайдеру никакая связь не работает. Возвращаем MS TMG — всё работает. Куда смотреть после проверки канального и физического уровня? Наиболее вероятный ответ – проверить работу ARP.
В данной заметке я не буду подробно описывать принципы работы ARP и протоколов этого семейства (RARP, InARP, UnARP и т.д.). На эту тему уже существует уйма статей в Интернете (например, здесь не плохо описаны разновидности ARP). Единственный теоретический момент, на котором я заострю чуть больше внимания, – механизм Gratuitous ARP (GARP).
Статья будет состоять из двух частей. В первой части будет немного теории и особенности работы ARP на маршрутизаторах Cisco, связанные с правилами NAT и с функцией Proxy ARP. Во второй части опишу отличия в работе ARP между маршрутизаторами Cisco и межсетевыми экранами Cisco ASA, а также поделюсь несколькими интересными случаями из практики, связанными с работой ARP.
Ниже представлен пример обмена ARP-запросом/ARP-ответом в программе-сниффере Wireshark:
ARP-запрос отправляется на широковещательный MAC-адрес ff:ff:ff:ff:ff:ff. В теле ARP-запроса поле с неизвестным значением Target MAC Address заполняется нулями.
ARP-ответ отправляется на MAC-адрес получателя, отправившего ARP-запрос. В поле Sender MAC Address указывается запрашиваемый MAC-адрес устройства.
Поле opcode в заголовке ARP может принимает значение 1 для ARP-запроса и значение 2 для ARP-ответа.
Чтобы два устройства могли начать передавать трафика между собой, в их ARP-таблицах должна существовать соответствующая запись о соседнем устройстве. Логично предположить, чтобы ARP-запись появилась в таблицах, для каждого устройства должна отработать процедура ARP-запрос/ARP-ответ. То есть перед передачей трафика в сети должны пройти по два ARP-запроса и два ARP-ответа (ARP-запрос/ARP-ответ для первого компьютера и ARP-запрос/ARP-ответ для второго компьютера). Однако, данное предположение верно не для всех случаев. Сетевое оборудование Cisco добавляет новую запись в ARP-таблицу сразу по приходу ARP-запроса от удалённого устройства.
Рассмотрим пример. В широковещательный домен добавляется новое устройство с адресом 198.18.0.200. Запустим пинг с нового устройства и посмотрим debug arp на маршрутизаторе Cisco:
Как видно, сразу по пришествии ARP-запроса от неизвестного IP-адреса (rcvd req src 198.18.0.200), маршрутизатор создаёт соответствующую запись в своей ARP-таблице (creating entry for IP address: 198.18.0.200, hw: 64e9.50c8.d6cd).
Для текущей статьи я не проводил подробного исследования по вопросу, какое именно сетевое оборудование добавляет ARP-запись по пришествии ARP-запроса. Однако, предполагаю, описанное поведение присуще не только сетевому оборудованию Cisco, но и сетевому оборудованию других производителей, так как данный механизм позволяет существенно сократить ARP-трафик в сети.
Описанное поведение присуще сетевому оборудованию. Конечное оборудование в большинстве случаев, получает запись в ARP-таблицу только после полноценной процедуры ARP-запрос/ARP-ответ. Для примера, я проверил процедуру на компьютере с операционной системой Windows 7. Ниже представлен дамп ARP-пакетов. В данном примере был очищен arp-cache на маршрутизаторе Cisco и на Windows-компьютере. После этого был запущен пинг от маршрутизатора к компьютеру.
Из представленного дапма видно, что сперва маршрутизатор отправляет ARP-запрос и получает ARP-ответ. Но ARP-запрос от маршрутизатора не приводит к появлению требуемой записи в ARP-таблице Windows-компьютера, поэтому, в свою очередь, компьютер отправляет ARP-запрос и получает ARP-ответ от маршрутизатора.
Механизм Gratuitous ARP используется для оповещения устройств в рамках широковещательного домена о появлении новой привязки IP-адреса и MAC-адреса. Когда сетевой интерфейс устройства получает настройки IP (вручную или по DHCP), устройство отправляет Gratuitous ARP сообщение, чтобы уведомить соседей о своём присутствии. Gratuitous ARP сообщение представляет собой особый вид ARP-ответа. Поле opcode принимает значение 2 (ARP-ответ). MAC-адрес получается как в заголовке Ethernet, так и в теле ARP-ответа является широковещательным (ff:ff:ff:ff:ff:ff). Поле Target IP Address в теле ARP-ответа совпадает с полем Sender IP Address.
Механизм Gratuitous ARP используется для многих целей. Например, с помощью Gratuitous ARP можно уведомить о смене MAC-адреса или обнаружить конфликты IP-адресов. Другой пример — использование протоколов резервирования первого перехода (First Hop Redundancy Protocols), например, HSRP у Cisco. Напомню, HSRP позволяет иметь виртуальный IP-адрес, разделённый между двумя или более сетевыми устройствами. В нормальном режиме работы обслуживание виртуального IP-адреса (ответы на ARP-запросы и т.д.) обеспечивает основное устройство. При отказе основного устройства обслуживание виртуального IP-адреса переходит ко второму устройству. Чтобы уведомить о смене MAC-адреса ответственного устройства, как раз отправляется Gratuitous ARP-сообщения.
В примере ниже представлено Gratuitous ARP сообщение при включении сетевого интерфейса маршрутизатора с настроенным IP-адресов 198.18.0.1.
Если на маршрутизаторе настроен secondary IP-адрес, при переходе интерфейса в состояние UP будут отправлены Gratuitous ARP уведомления для каждого IP-адреса интерфейса. В примере ниже представлены Gratuitous ARP сообщения, отправляемые при включении интерфейса маршрутизатора с основным IP-адресом 198.18.0.1 и secondary IP-адресом 198.18.2.1.
Безусловно, маршрутизатор будет отвечать на ARP-запросы как для основного, так и для secondary IP-адреса.
Логично предположить, что как только устройство получает Gratuitous ARP, сразу добавляется новая запись в ARP-таблицу. Однако это не так. Если в таблице устройства отсутствовала ARP-запись, связанная с IP-адресом из Gratuitous ARP сообщения, новая запись добавлена не будет. При необходимости отправить трафик будет сформирован ARP-запрос и получен ARP-ответ. Только после этой процедуры новая запись добавится в ARP-таблицу.
Пример на маршрутизаторе Cisco. Включим debug arp и подключим в широковещательный домен новое устройство с адресом 198.18.0.200. До подключения нового устройства ARP-таблица маршрутизатора выглядит следующим образом:
Включаем новое устройство с адресом 198.18.0.200. Получаем debug-сообщение о приходе Gratuitous ARP:
Новая запись не появилась. Делаем пинг до нового адреса:
Debug-сообщения показывают, что прошла процедура ARP-запрос/ARP-ответ. Проверяем ARP-таблицу:
Новая запись появилась.
ARP и NAT на маршрутизаторах Cisco
Примечание: для тестов использовался маршрутизатор C4321 с программным обеспечением 15.4(3)S3 и межсетевой экран Cisco ASA5505 c программным обеспечением 9.1(6)6.
Компьютер Wireshark с адресов 198.18.0.250 в нашем случае будет обозначать подключение к внешней сети (например, к Интернет-провайдеру). С помощью сниффера Wireshark будем просматривать обмен сообщениями ARP между маршрутизатором и компьютером.
Настройки интерфейсов маршрутизатора:
Добавим правило динамического NAT, чтобы транслировать адрес компьютера из LAN (192.168.20.5) во внутренний глобальный адрес 198.18.0.5 при обращении к компьютеру во вне (Wireshark). Добавим правило статического PAT для публикации TCP порта 3389 (RDP) компьютера из LAN под глобальным адресом 198.18.0.2.
Посмотрим ARP-таблицу на маршрутизаторе:
Видим, что в ARP-таблице присутствуют статические записи как для внешнего интерфейса маршрутизатора (198.18.0.1), так и для внутренних глобальных адресов из правил динамического и статического NAT.
Сделаем clear arp-cache на маршрутизаторе и посмотрим в Wireshark, какие Gratuitous ARP уведомления будут отправлены с внешнего интерфейса:
Как видно, маршрутизатор уведомил о готовности обслуживать адрес интерфейса, адрес из правила динамического NAT и адрес из правила статического NAT.
А теперь представим ситуацию, когда провайдер расширяет пул публичных адресов, выданных клиенту, за счёт другой подсети. Предположим, дополнительно к IP-подсети 198.18.0.0/24 на внешнем интерфейсе маршрутизатора мы получаем от провайдера новый пул 198.18.99.0/24 и хотим публиковать наши внутренние сервисы под новыми IP-адресами. Для наглядности приведу схему с провайдером:
Добавим правило статического PAT для публикации TCP порта 3389 (RDP) компьютера из LAN под новым глобальным адресом 198.18.99.2:
Если снова посмотреть ARP-таблицу маршрутизатора командой show arp, увидим, что статическая запись для IP-адреса 198.18.99.2 не добавилась.
Чтобы иметь возможность отправлять ARP-запросы в новую сеть 198.18.99.0/24 с компьютера Wireshark, расширим маску его сетевых настроек до 255.255.0.0 (/16). Напомню, для нашего примера компьютер Wireshark выступает в роли маршрутизатора Интернет-провайдера.
После ввода clear arp-cache сниффер по-прежнему показывает Gratuitous ARP только для трёх IP-адресов: 198.18.0.1, 198.18.0.2, 198.18.0.5. Для нового адреса 198.18.99.2 Gratuitous ARP не срабатывает. Попробуем открыть tcp-порт 3389 адреса 198.18.99.2 и одновременно посмотреть сниффер:
Неуспех. Проверим ARP-таблицу:
Настройка Proxy ARP на интерфейсе маршрутизатора:
Отключить Proxy ARP на всех интерфейсах маршрутизатора можно глобально:
Данная настройка имеет приоритет над настройками Proxy ARP, применёнными на интерфейсах.
Помимо команды ip proxy arp в настройках интерфейса существует команда ip local-proxy-arp. Данная команда работает только когда ip proxy arp включён на интерфейсе и позволяет маршрутизатору отвечать на ARP-запросы, даже если целевой IP-адрес находится в той же IP-подсети, откуда ARP-запрос поступил. Пример настройки:
Данная настройка может пригодится, если мы хотим, чтобы трафик в рамках одного широковещательного домена шёл через интерфейс нашего маршрутизатора. Данную задачу можно реализовать с использованием Protected port (PVLAN edge) настроек на L2-коммутаторе (switchport protected).
Включение Proxy ARP на внешнем интерфейсе маршрутизаторе позволит решить проблему с новым пулом адресов, выданных провайдером. Попробуем открыть tcp-порт 3389 адреса 198.18.99.2 после включения Proxy ARP на интерфейсе маршрутизатора и одновременно посмотреть сниффер:
Успех. Маршрутизатор отвечает на ARP-запрос и порт открывается. Таким образом, функциональность Proxy ARP также можно использовать при необходимости трансляции адресов в новый пул.