Jump to content
Калькуляторы

DHCP Snooping + ARP Inspec Периодическая блокировка адресов

Коллеги, добрый день.

Подскажите плиз, в чем может быть трабла?

В сети поднят DHCP сервер (isc-dhcp). Народ сидит в групповых виланах (один вилан, один комутатор доступа). Агрегируем все виланы каталистом 3560G с dhcp хелтером на наш DHCP сервер.

На каталисте включен DHCP Snooping и ARP Inspecting для этих виланов.

Клиенты получают адреса, но в какое-то время похоже что случается и у клиентов пропадает доступ к своему шлюзу (каталист). Похоже срабатывает ARP Inspecting.

В логах каталиста видны подобные записи.

Sep  9 14:05:00 gw-srv 523472: 1w1d: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi0/4, vlan 4.([001a.4d43.5138/172.16.202.1/0000.0000.0000/10.4.0.103/14:05:00 MSK Wed Sep 9 2009])

 

Где 10.4.0.103 - адрес интерфейса клиента, а вот 172.16.202.1 это интерфейс VMWare установленного на этой машинке. Не понятно как оно вылезло в сетку, т.к. там по сути должен быть NAT, но суть не в этом. Основной интерфейс машинки не может достучаться до интерфейса на каталисте. Запросы DHCP какое-то время не проходят. Через пару-тройку минут все восстанавливается после получаняи IP адреса заново.

 

Что это может быть?

Share this post


Link to post
Share on other sites
Коллеги, добрый день.

Подскажите плиз, в чем может быть трабла?

В сети поднят DHCP сервер (isc-dhcp). Народ сидит в групповых виланах (один вилан, один комутатор доступа). Агрегируем все виланы каталистом 3560G с dhcp хелтером на наш DHCP сервер.

На каталисте включен DHCP Snooping и ARP Inspecting для этих виланов.

Клиенты получают адреса, но в какое-то время похоже что случается и у клиентов пропадает доступ к своему шлюзу (каталист). Похоже срабатывает ARP Inspecting.

В логах каталиста видны подобные записи.

Sep  9 14:05:00 gw-srv 523472: 1w1d: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi0/4, vlan 4.([001a.4d43.5138/172.16.202.1/0000.0000.0000/10.4.0.103/14:05:00 MSK Wed Sep 9 2009])

 

Где 10.4.0.103 - адрес интерфейса клиента, а вот 172.16.202.1 это интерфейс VMWare установленного на этой машинке. Не понятно как оно вылезло в сетку, т.к. там по сути должен быть NAT, но суть не в этом. Основной интерфейс машинки не может достучаться до интерфейса на каталисте. Запросы DHCP какое-то время не проходят. Через пару-тройку минут все восстанавливается после получаняи IP адреса заново.

 

Что это может быть?

А ip dhcp snooping trust порт_на_котором_дхцп_сервер есть?

Share this post


Link to post
Share on other sites
Коллеги, добрый день.

Подскажите плиз, в чем может быть трабла?

В сети поднят DHCP сервер (isc-dhcp). Народ сидит в групповых виланах (один вилан, один комутатор доступа). Агрегируем все виланы каталистом 3560G с dhcp хелтером на наш DHCP сервер.

На каталисте включен DHCP Snooping и ARP Inspecting для этих виланов.

Клиенты получают адреса, но в какое-то время похоже что случается и у клиентов пропадает доступ к своему шлюзу (каталист). Похоже срабатывает ARP Inspecting.

В логах каталиста видны подобные записи.

Sep  9 14:05:00 gw-srv 523472: 1w1d: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi0/4, vlan 4.([001a.4d43.5138/172.16.202.1/0000.0000.0000/10.4.0.103/14:05:00 MSK Wed Sep 9 2009])

 

Где 10.4.0.103 - адрес интерфейса клиента, а вот 172.16.202.1 это интерфейс VMWare установленного на этой машинке. Не понятно как оно вылезло в сетку, т.к. там по сути должен быть NAT, но суть не в этом. Основной интерфейс машинки не может достучаться до интерфейса на каталисте. Запросы DHCP какое-то время не проходят. Через пару-тройку минут все восстанавливается после получаняи IP адреса заново.

 

Что это может быть?

А ip dhcp snooping trust порт_на_котором_дхцп_сервер есть?

На порту смотрящем на DHCP сервер траст включен

 

interface GigabitEthernet0/10
description Servers and Farms
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 63,64
switchport mode trunk
ip dhcp snooping trust

Share this post


Link to post
Share on other sites
Коллеги, добрый день.

Подскажите плиз, в чем может быть трабла?

В сети поднят DHCP сервер (isc-dhcp). Народ сидит в групповых виланах (один вилан, один комутатор доступа). Агрегируем все виланы каталистом 3560G с dhcp хелтером на наш DHCP сервер.

На каталисте включен DHCP Snooping и ARP Inspecting для этих виланов.

Клиенты получают адреса, но в какое-то время похоже что случается и у клиентов пропадает доступ к своему шлюзу (каталист). Похоже срабатывает ARP Inspecting.

В логах каталиста видны подобные записи.

Sep  9 14:05:00 gw-srv 523472: 1w1d: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi0/4, vlan 4.([001a.4d43.5138/172.16.202.1/0000.0000.0000/10.4.0.103/14:05:00 MSK Wed Sep 9 2009])

 

Где 10.4.0.103 - адрес интерфейса клиента, а вот 172.16.202.1 это интерфейс VMWare установленного на этой машинке. Не понятно как оно вылезло в сетку, т.к. там по сути должен быть NAT, но суть не в этом. Основной интерфейс машинки не может достучаться до интерфейса на каталисте. Запросы DHCP какое-то время не проходят. Через пару-тройку минут все восстанавливается после получаняи IP адреса заново.

 

Что это может быть?

А ip dhcp snooping trust порт_на_котором_дхцп_сервер есть?

На порту смотрящем на DHCP сервер траст включен

 

interface GigabitEthernet0/10
description Servers and Farms
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 63,64
switchport mode trunk
ip dhcp snooping trust

Может тогда поможет на том же интерфейсе

ip arp inspection trust

 

Share this post


Link to post
Share on other sites
Может тогда поможет на том же интерфейсе

ip arp inspection trust

Спасибо, попробую. Просто не совсем понимаю происходящее. По сути, адрес ведь у клиента остается. По крайней мере в интерфейсе его видать. Новый не получить - да, похоже доступ к dhcp серверу накрывается.

Прописал arp trust - посмотрим.

Share this post


Link to post
Share on other sites

Не спасло.

 

Еще есть варианты?

Share this post


Link to post
Share on other sites
Не спасло.

 

Еще есть варианты?

А дхцп снупинг с ип сурс гуардом используете?

ip verify source на интерфейсах не стоит?

Share this post


Link to post
Share on other sites
Не спасло.

 

Еще есть варианты?

А дхцп снупинг с ип сурс гуардом используете?

ip verify source на интерфейсах не стоит?

Ммм, да вроде нет.

 

#sh ip dhcp snooping 
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
2-7
DHCP snooping is operational on following VLANs:
2-7
DHCP snooping is configured on the following L3 Interfaces:

Insertion of option 82 is enabled
   circuit-id default format: vlan-mod-port
   remote-id: 0025.b42d.3280 (MAC)
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:

Interface                  Trusted    Allow option    Rate limit (pps)
-----------------------    -------    ------------    ----------------   
GigabitEthernet0/1         yes        yes             unlimited
  Custom circuit-ids:
GigabitEthernet0/10        yes        yes             unlimited
  Custom circuit-ids:
GigabitEthernet0/16        yes        yes             unlimited
  Custom circuit-ids:

 

#sh ip arp inspection 

Source Mac Validation      : Disabled
Destination Mac Validation : Disabled
IP Address Validation      : Disabled

Vlan     Configuration    Operation   ACL Match          Static ACL
----     -------------    ---------   ---------          ----------
    2     Enabled          Active                         
    3     Enabled          Active                         
    4     Enabled          Active                         
    5     Enabled          Active                         
    6     Enabled          Active                         
    7     Enabled          Active                         

Vlan     ACL Logging      DHCP Logging      Probe Logging
----     -----------      ------------      -------------
    2     Deny             Deny              Off          
    3     Deny             Deny              Off          
    4     Deny             Deny              Off          
    5     Deny             Deny              Off          
    6     Deny             Deny              Off          
    7     Deny             Deny              Off          

Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops
----      ---------        -------     ----------      ---------
    2           4147          19323          19323              0
    3          32483         268216         268216              0
    4         117073         128289         128289              0
    5          12752          15037          15037              0
    6           3568            766            766              0
    7              0              0              0              0

Vlan   DHCP Permits    ACL Permits  Probe Permits   Source MAC Failures
----   ------------    -----------  -------------   -------------------
    2           4114              0             33                     0
    3          30971              0           1512                     0
    4         116538              0            535                     0
    5          12725              0             27                     0
    6           3536              0             32                     0
    7              0              0              0                     0

Vlan   Dest MAC Failures   IP Validation Failures   Invalid Protocol Data
----   -----------------   ----------------------   ---------------------
    2                   0                        0                       0
    3                   0                        0                       0
    4                   0                        0                       0
    5                   0                        0                       0
    6                   0                        0                       0
    7                   0                        0                       0

На самих клиентских интерфейсах ничего дополнительно не указывал.

Share this post


Link to post
Share on other sites
Ммм, да вроде нет.
Глупый вопрос, а зачем тогда дхцп снупинг включать? Если потом включить на порту верифи сурс - получим эффект - кто не получил адреса по дхцп, тот не работает. У кого статика - биндим вручную. А просто так включать - ради чего, ради вывода #sh ip dhcp snooping binding?

Или я чего не понимаю :(

 

 

Share this post


Link to post
Share on other sites
Ммм, да вроде нет.
Глупый вопрос, а зачем тогда дхцп снупинг включать? Если потом включить на порту верифи сурс - получим эффект - кто не получил адреса по дхцп, тот не работает. У кого статика - биндим вручную. А просто так включать - ради чего, ради вывода #sh ip dhcp snooping binding?

Или я чего не понимаю :(

Да вроде так и работает - не получил по dhcp адрес, в сетку не пущаем.

По сути требовался как раз такой эффект. На DHCP все адреса статиком раздаем - специфика такая.

 

Т.е. получается DHCP snooping не доконца отконфигурен чтоли?

Share this post


Link to post
Share on other sites
Ммм, да вроде нет.
Глупый вопрос, а зачем тогда дхцп снупинг включать? Если потом включить на порту верифи сурс - получим эффект - кто не получил адреса по дхцп, тот не работает. У кого статика - биндим вручную. А просто так включать - ради чего, ради вывода #sh ip dhcp snooping binding?

Или я чего не понимаю :(

Да вроде так и работает - не получил по dhcp адрес, в сетку не пущаем.

По сути требовался как раз такой эффект. На DHCP все адреса статиком раздаем - специфика такая.

 

Т.е. получается DHCP snooping не доконца отконфигурен чтоли?

Т.е. если я выставлю на интерфейсе раб. станции вручную ип не занятый и все правильно настрою - работать не должно?

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

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

Edited by casperrr

Share this post


Link to post
Share on other sites
Ммм, да вроде нет.
Глупый вопрос, а зачем тогда дхцп снупинг включать? Если потом включить на порту верифи сурс - получим эффект - кто не получил адреса по дхцп, тот не работает. У кого статика - биндим вручную. А просто так включать - ради чего, ради вывода #sh ip dhcp snooping binding?

Или я чего не понимаю :(

Да вроде так и работает - не получил по dhcp адрес, в сетку не пущаем.

По сути требовался как раз такой эффект. На DHCP все адреса статиком раздаем - специфика такая.

 

Т.е. получается DHCP snooping не доконца отконфигурен чтоли?

Т.е. если я выставлю на интерфейсе раб. станции вручную ип не занятый и все правильно настрою - работать не должно?

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

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

Вообще была задача

 

1. Запретить безконтрольное подключеие машинок в сеть

2. Обеспечить защиту от ручного указания адреса (по сути тот же п.1)

 

Что нужно использовать для обеспечения такого эффекта не подскажите?

 

Share this post


Link to post
Share on other sites
Вообще была задача

 

1. Запретить безконтрольное подключеие машинок в сеть

2. Обеспечить защиту от ручного указания адреса (по сути тот же п.1)

 

Что нужно использовать для обеспечения такого эффекта не подскажите?

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

Share this post


Link to post
Share on other sites
Вообще была задача

 

1. Запретить безконтрольное подключеие машинок в сеть

2. Обеспечить защиту от ручного указания адреса (по сути тот же п.1)

 

Что нужно использовать для обеспечения такого эффекта не подскажите?

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

Ок, смысл понял - поштуирую сегодня IP Source Guard. Но похоже мы немного отклонились от сути проблемы. Ведь сейчас у народа пропадает доступ. Как это может быть связано с IP Source Guard? По умолчанию он отключен и поэтому отсутствует дополнительная проверка, что по сути наоборот должно способствовать свободному прохождению трафика.

Share this post


Link to post
Share on other sites
Вообще была задача

 

1. Запретить безконтрольное подключеие машинок в сеть

2. Обеспечить защиту от ручного указания адреса (по сути тот же п.1)

 

Что нужно использовать для обеспечения такого эффекта не подскажите?

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

Ок, смысл понял - поштуирую сегодня IP Source Guard. Но похоже мы немного отклонились от сути проблемы. Ведь сейчас у народа пропадает доступ. Как это может быть связано с IP Source Guard? По умолчанию он отключен и поэтому отсутствует дополнительная проверка, что по сути наоборот должно способствовать свободному прохождению трафика.

Приведите относящиеся к теме куски конфига.

Share this post


Link to post
Share on other sites
Приведите относящиеся к теме куски конфига.

Включен Snooping и Inspection

ip dhcp snooping vlan 2-7
ip dhcp snooping
ip dhcp-server 100.0.0.252
ip arp inspection vlan 2-7

 

Клиентский порт

interface GigabitEthernet0/2
switchport access vlan 2
!
interface Vlan2
ip address 100.2.0.1 255.255.0.0
ip access-group 102 in
ip helper-address 100.0.0.252

 

На этом интерфейсе DHCP

interface GigabitEthernet0/10
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 63,64
switchport mode trunk
ip arp inspection trust
ip dhcp snooping trust

Share this post


Link to post
Share on other sites

А порт не кладется/восстанавливается по errdisable ?

btw с arp inspection есть засада, ограничен pps.

 

Limiting the Rate of Incoming ARP Packets

The switch CPU performs dynamic ARP inspection validation checks; therefore, the number of incoming ARP packets is rate-limited to prevent a denial-of-service attack.

 

When the rate of incoming ARP packets exceeds the configured limit, the switch places the port in the error-disabled state. The port remains in that state until you intervene unless you enable error-disable recovery so that ports automatically emerge from this state after a specified timeout period.

 

Share this post


Link to post
Share on other sites

Ограничения броадкаста тоже могут влиять.

Видел как винда XP отослав dhcp запрос и не получив ответа отправила Arp запрос к шлюзу. Ответ пришел и винда радостно рапортовала "Получен по dhcp"

Share this post


Link to post
Share on other sites

http://www.google.ru/url?q=http://supportw...5NmtAfzoYXwtrxA

 

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

ip source binding xxxx.xxxx.xxxx vlan x ipxx interface xx

Edited by casperrr

Share this post


Link to post
Share on other sites
http://www.google.ru/url?q=http://supportw...5NmtAfzoYXwtrxA

 

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

ip source binding xxxx.xxxx.xxxx vlan x ipxx interface xx

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

Видать что-то не докрутил. Помнится была опция, которая управляла таким поведением. Может кто помнит?

 

Ограничения броадкаста тоже могут влиять.

Видел как винда XP отослав dhcp запрос и не получив ответа отправила Arp запрос к шлюзу. Ответ пришел и винда радостно рапортовала "Получен по dhcp"

Вряд ли, т.к. по симптомам интерфейс просто блокируется на какое-то время.

 

А порт не кладется/восстанавливается по errdisable ?

btw с arp inspection есть засада, ограничен pps.

 

Limiting the Rate of Incoming ARP Packets

The switch CPU performs dynamic ARP inspection validation checks; therefore, the number of incoming ARP packets is rate-limited to prevent a denial-of-service attack.

 

When the rate of incoming ARP packets exceeds the configured limit, the switch places the port in the error-disabled state. The port remains in that state until you intervene unless you enable error-disable recovery so that ports automatically emerge from this state after a specified timeout period.

А можно тут по-подробней? :) errdisable были когда подключал комутатор группы в порт каталиста. Интерфейс отрубался - приходилось передергивать его. Из за чего это было не понял, но после передергивания интерфейс оживал.

Share this post


Link to post
Share on other sites
Глупый вопрос, а зачем тогда дхцп снупинг включать?

В его конфиге приведённом есть

 

ip arp inspection vlan 2-7

 

будет почти тот же эффект: если dhcp и шлюз - одна циска, она не будет отвечать на arp запросы и работать клиент не будет, а ip source guard на 3750, по крайней мере, включается на физическом интерфейсе сразу во всех vlan. Прописывать ручками в вланы с оборудованием, которая уходит в транке на микрорайон и без всякого DHCP ой как не хочется.

Есть варианты решения проблемы?

 

А можно тут по-подробней? :) errdisable были когда подключал комутатор группы в порт каталиста. Интерфейс отрубался - приходилось передергивать его. Из за чего это было не понял, но после передергивания интерфейс оживал.

 

no errdisable detect cause dhcp-rate-limit

no errdisable detect cause arp-inspection

 

К примеру

Share this post


Link to post
Share on other sites

Подобная проблема. Только не с компьютерами, а с IP телефонами. Планируем настроить DHCP Snooping и DAI на всех аксес свитчах, их довольно много, и поэтому чтобы не наломать дров решили запустить потестить пока на одном. Все в общем работает, отрабатывает так как нужно, однако вылезла следующая проблема. Иногда какой-нибудь IP телефон или компьютер подключенный через IP телефон, не могут попасть в таблицу DHCP snooping binding и в лог начинает сыпать ошибки типа %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req). И причем нет никакой закономерности, перегружаю порт, все поднимается, рядом стоит телефон и комп через него работающий, и с ними все нормально, оба IP и MAC'а в базе. Перегружаю свитч, те что не работали поднялись, те что работали повылетали. А компьютеры подключенные напрямую отлично работают. Никто с таким не сталкивался? В чем примерно может быть трабла? Как с этим бороться? Ведь не буду же я на каждом свитче биндить маки и айпи руками, их много слишком.

 

На свитч добавлены такие строчки:

 

!Добавляем все виланы в которых будет включен DHCP Snooping

!вилан принтеров со статикой

ip dhcp snooping vlan 1

!вилан телефонов

ip dhcp snooping vlan 71

!вилан компьютеров

ip dhcp snooping vlan 110

 

!Прописываем доверенный порт, ведущий к дистрибьюшен свитчу.

int g1/0/1

ip dhcp snooping trust

 

!Включаем DHCP Snooping

ip dhcp snooping

 

!Отключаем опцию 82

no ip dhcp snooping information option

 

!Добавляем все виланы в которых будет работать ARP Inspection

ip arp inspection vlan 1

ip arp inspection vlan 71

ip arp inspection vlan 110

 

!Прописываем доверенный порт, ведущий на дистрибьюшен свитч

int g1/0/1

ip arp inspection trust

 

!Прописываем аксес лист для статических IP адресов, это два принтера.

arp access-list printers

permit ip host 10.191.121.49 mac host 0011.0af1.3aaa

permit ip host 10.191.121.52 mac host 0021.5a7c.28b4

 

ip arp inspection filter printers vlan 1

 

!отключаем errdisable

no errdisable detect cause dhcp-rate-limit

no errdisable detect cause arp-inspection

 

 

Share this post


Link to post
Share on other sites

Раз уже подняли эту тему. Была такая фигня, врубаем снупинг на 3550, при этом не включаем ни arp инспекцию ни ip source guard. Некоторые из клиентов получают IP, некоторые нет. При этом запрос до DHCP сервера доходит, ответ он тоже посылает, но ответ до клиента не доходит (сниф врубали), т.е. получается циска что ли его рубит? Почему выборочно?

 

Какие есть идеи? Что может влиять на это?

 

И еще вопрос, есть ли смысл включать arp инспекцию + ip source guard или достаточно только ip source guard? Нужно чтобы клиент работал по связке IP+MAC на циске.

Edited by SokolovS

Share this post


Link to post
Share on other sites
Раз уже подняли эту тему. Была такая фигня, врубаем снупинг на 3550, при этом не включаем ни arp инспекцию ни ip source guard. Некоторые из клиентов получают IP, некоторые нет. При этом запрос до DHCP сервера доходит, ответ он тоже посылает, но ответ до клиента не доходит (сниф врубали), т.е. получается циска что ли его рубит? Почему выборочно?

 

Какие есть идеи? Что может влиять на это?

 

И еще вопрос, есть ли смысл включать arp инспекцию + ip source guard или достаточно только ip source guard? Нужно чтобы клиент работал по связке IP+MAC на циске.

Когда я тестил DHCP Snooping без ARP Inspection у меня клиент не получал ип пока я не отключил опцию 82. По умолчанию она включается при активации DHCP Snooping, попробуй её отключить.

 

no ip dhcp snooping information option

Edited by sight

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this