Ответ:
Рекомендуется ознакомиться:
http://ru.wikipedia.org/wiki/ARP
Примеры применения ACL типа Packet Content Filtering
Дано:
DES-3550 (установки заводские) - IP = 10.90.90.90
Сервер - IP = 10.0.0.1 (порт 48, MAC=00-50-04-29-6E-C4)
Клиент - IP = 10.0.0.2 (порт 2, MAC=00-0A-E6-6D-8C-FD)
Сеть 10.0.0.0/8
Задача:
Исключить конфликт ip-адресов на сервере в случае неправильной настройки ip-адреса на клиенте.
Решение:
1. Анализ данной ситуации:
Arp-пакеты при правильной настройке клиента:
arp who-has 10.0.0.1 tell 10.0.0.2
| 0x0000: | ffff | ffff | ffff | 000a | e66d | 8cfd | 0806 | 0001 | |
| 0x0010: | 0800 | 0604 | 0001 | 000a | e66d | 8cfd | 0a00 | 0002 | |
| 0x0020: | 0000 | 0000 | 0000 | 0a00 | 0001 | 05ea | 09c6 | 5010 | |
| 0x0030: | ffff | 6e01 | 0000 | 0000 | 0054 | ff53 |
arp reply 10.0.0.1 is-at 00:50:04:29:6e:c4
| 0x0000: | 000a | e66d | 8cfd | 0050 | 0429 | 6ec4 | 0806 | 0001 | |
| 0x0010: | 0800 | 0604 | 0002 | 0050 | 0429 | 6ec4 | 0a00 | 0001 | |
| 0x0020: | 000a | e66d | 8cfd | 0a00 | 0002 |
Пакеты arp при конфликте адресов:
arp who-has 10.0.0.1 tell 10.0.0.1
| 0x0000: | ffff | ffff | ffff | 000a | e66d | 8cfd | 0806 | 0001 | |
| 0x0010: | 0800 | 0604 | 0001 | 000a | e66d | 8cfd | 0a00 | 0001 | |
| 0x0020: | 0000 | 0000 | 0000 | 0a00 | 0001 | 93f0 | 2ba9 | 5011 | |
| 0x0030: | fde0 | 9356 | 0000 | 0000 | 003b | ff53 |
arp reply 10.0.0.1 is-at 00:50:04:29:6e:c4
| 0x0000: | 000a | e66d | 8cfd | 0050 | 0429 | 6ec4 | 0806 | 0001 | |
| 0x0010: | 0800 | 0604 | 0002 | 0050 | 0429 | 6ec4 | 0a00 | 0001 | |
| 0x0020: | 000a | e66d | 8cfd | 0a00 | 0001 |
Вывод: необходимо разрешить arp-запросы на клиентском порту (№ 2) только при допустимом ip-адресе клиента (10.0.0.2) и запретить при недопустимых ip-адресах, в том числе и при назначении ip-адреса совпадающего с ip-адресом сервера.
2. Настройка ACL
Построим таблицу смещений для разрешенного arp-запроса:
| 0x0000: | ffffffff | ffff000a | e66d8cfd | xxxxxxxx |
| 0x0010: | 08060001 | 08000604 | 0001000a | e66d8cfd |
| 0x0020: | 0a000002 | 00000000 | 00000a00 | 000105ea |
| 0x0030: | 09c65010 | ffff6e01 | 00000000 | 0054ff53 |
Получим разрешающий профиль:
| offset_16-31: | FFFF0000 | 00000000 | 000F0000 | 00000000 |
| offset_32-47: | FFFFFFFF | 00000000 | 00000000 | 00000000 |
или в синтаксисе CLI (здесь символ \ введен только для удобства чтения и означает продолжение строки):
create access_profile packet_content_mask \
offset_16-31 0xFFFF0000 0x0 0xF0000 0x0 \
offset_32-47 0xFFFFFFFF 0x0 0x0 0x0 \
profile_id 30
Строим разрешающее правило:
config access_profile profile_id 30 add access_id 1 packet_content_mask \
offset_16-31 0x8060000 0x0 0x10000 0x0 \
offset_32-47 0xA000002 0x0 0x0 0x0 \
port 2 permit
Запрещающий профиль:
offset_16-31: FFFF0000 00000000 000F0000 00000000
и соответствующая команда:
create access_profile packet_content_mask \
offset_16-31 0xFFFF0000 0x0 0xF0000 0x0 \
profile_id 40
Запрещающее правило:
config access_profile profile_id 40 add access_id 2 packet_content_mask \
offset_16-31 0x8060000 0x0 0x10000 0x0 \
port 2 deny
Проверяем arp-кеш коммутатора:
#sh arp
Command: show arpentry
ARP Aging Time : 20
| Interface | IP Address | MAC Address | Type |
| ------------- | --------------- | ----------------- | --------------- |
| System | 10.0.0.0 | FF-FF-FF-FF-FF-FF | Local/Broadcast |
| System | 10.0.0.1 | 00-50-04-29-6E-C4 | Dynamic |
| System | 10.0.0.2 | 00-0A-E6-6D-8C-FD | Dynamic |
| System | 10.90.90.90 | 00-19-5B-6C-5A-63 | Local |
| System | 10.255.255.255 | FF-FF-FF-FF-FF-FF | Local/Broadcast |
| Total Entries: | 5 |
3 Тестирование
Сменим ip-адрес на клиенте на 10.0.0.1. Конфликт ip-адресов не обнаружен ни на сервере, ни на клиенте. С клиента запустим ping на коммутатор (10.90.90.90). На стороне клиента обнаружится конфликт ip-адресов (что вполне логично), а на стороне сервера - нет. Однако в результате этого arp-кеш коммутатора получит неверный mac-адрес, что приведет к потере связи сервера с коммутатором:
#sh arp
Command: show arpentry
ARP Aging Time : 20
| Interface | IP Address | MAC Address | Type |
| ------------- | --------------- | ----------------- | --------------- |
| System | 10.0.0.0 | FF-FF-FF-FF-FF-FF | Local/Broadcast |
| System | 10.0.0.1 | 00-0A-E6-6D-8C-FD | Dynamic |
| System | 10.0.0.2 | 00-0A-E6-6D-8C-FD | Dynamic |
| System | 10.90.90.90 | 00-19-5B-6C-5A-63 | Local |
| System | 10.255.255.255 | FF-FF-FF-FF-FF-FF | Local/Broadcast |
| Total Entries: | 5 |
4 Ограничение доступа
Для исключения подобной ситуации, ограничим доступ к коммутатору со стороны клиента(ов).
Строим разрешающий профиль для доступа к коммутатору на основе mac-адреса сервера:
create cpu access_profile ethernet source_mac FF-FF-FF-FF-FF-FF profile_id 1
строим разрешающее правило:
config cpu access_profile profile_id 1 add access_id 1 ethernet source_mac 00-50-04-29-6E-C4 permit
и включаем фильтрацию доступа к коммутатору:
enable cpu_interface_filtering
5 Повторное тестирование
Возвращаем клиенту правильный ip-адрес (10.0.0.2) и повторно изменяем его на неправильный (10.0.0.1). Конфликта ip-адреса на стороне сервера не возникает, связь с коммутатором со стороны сервера не рвется, а на стороне клиента периодически всплывают окна, предупреждающие о конфликте ip-адреса и свидетельствующие, о неправильной настройке клиента.
Вывод:
В результате проделанной настройки исключится, как конфликт ip-адресов сервера с клиентом в случае его неправильной настройки, так и паразитное прохождение arp-запросов через порт клиента.
Выражаем благодарность за предоставленный материал Владимиру Дойкину (Vladimir Doykin), г. Челябинск.