Ну дык а ARP разрешен где то? ARP кэш устаревает вот и отваливается...

И в профайле у вас поле протокола отмечено FFFF, в то время как в правиле там нули. Обратите внимание - в IP и ARP пакетах src IP на разных местах.

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

эм... а почему это у АРП и IP пакетов в разных местах мак и айпи? вот подсказали - если чистый АРП - там же айпишки нету вовсе. действительно если кеш устаревает и отпадает - это и должно быть ответом.

сейчас проверим

ну может там нету Dst IP, а Src IP должен быть всегда, а то это поддельный пакет какой-то, непонятно зачем нужный

Я это уже спрашивал. Выходит запись в FDB появляется до ACL.
Соответственно флуд src маком шлюза перекосит свич, а вот на магистраль уже не уйдет.

да но он же будет в основном нулевой - и это не поддельный пакет. машина без айпишки должна же как-то себя объявить и найти DHCP.

с загадочным пингом - действительно проблема была в том что я сглупил не подумав о том что по минимуму нужно открыть еще и ARP. делаю это вот так (в целях экономии профайла) можно конечно еще указать айпишку 0.0.0.0, но в некоторых случаях она в АРПе может быть из частного диапазона - 169.254.ххх.ххх. а это еще одно правило как ни крути...

$SNMPSET $switchip \
1.3.6.1.4.1.171.12.9.1.3.1.3.$p4 x FFFF0000000000000000000000000000 \
1.3.6.1.4.1.171.12.9.1.3.1.7.$p4 i 4

$SNMPSET $switchip \
1.3.6.1.4.1.171.12.9.2.3.1.4.$p4.0 x 08060000000000000000000000000000 \
1.3.6.1.4.1.171.12.9.2.3.1.13.$p4.0 i 2 \
1.3.6.1.4.1.171.12.9.2.3.1.14.$p4.0 x FFFFFF00 \
1.3.6.1.4.1.171.12.9.2.3.1.15.$p4.0 i 4

где p4 - номер профайла, FFFFFF00 - маска обозначающая порты 1-24 (клиентские)

При чем ARP к DHCP? Если конечно не используется какой нить древний RARP.
У себя я открываю DHCP первым правилом, т.к. там идет проверка на то что это IP UDP, правильный ли мак у клиента, проверяет порты чтоб именно дхцпэшные, а вот IP любой, т.к. там действительно возможны варианты.
И arp объеденить с чем то другим тоже не вижу вариантов - протокол там свой, даже не IP, поля другие и на других местах. Просто открыть arp по вышеизложенным правилам не подходит - зачем тогда вообще далать ACL?

не понял о чем речь.

я лишь уточнил что АРПе не всегда есть айпишка (в чистом АРПе), а если и есть - может быть как 0.0.0.0 так и с частной сети 169.254.xxx.xxx (оба случая для сети с DHCP ) так и валидный айпи клиента

а что бы узнать где находится DHCP сервер ему придется отправлять арпы

O_o

http://ru.wikipedia.org/wiki/DHCP#.D0.9 ... 0.B8.D0.B9

дык так и есть. в чем проблема?

подключаем сетевой кабель, пытаемся получить айпишку по DHCP. ну и какие пакеты подйдут первыми ? АРПы, и какой у них будет соурс айпи? 0.0.0.0 или с частной сети 169.254.ххх.ххх.

Это я к тому что какого-то одного айпишника указать в разрешающем фильтре на АРПы - недостаточно в случае когда в сети используется DHCP %)

проблема с 3028 при создании ACL через SNMP (IP и Ether)
рулю свичами посредством PHP, команды snmpset делаю по 1..
для 3526 нашел решение (IP):
1. срц ип
2. порт
3. пермит / дени
4. создать
(Ether)
1. срц мак
2. дст мак
3. пермит / дени
4. порт
5. создать
при этом писал в конце 0, т.е SNMPv2-SMI::enterprises.171.12.9.2.1.1.4.10.0
чтобы AccessID назначался автоматически..
Теперь перейдем к 3528.. начинаются проблемы. порядок команд от 3526 не подходит, AccessID автоматически не назначается (в мибах заявлено)
3528 (IP)
1. пермит / дени
2. порт
3. создание
4. ип
3528 (Ether)
1. пермит / дени
2. порт
3. создание
4. мак
С 3028 вообще непонятная ситуация, команды нормально принимаются свичем, после создания acl правила (IP) оно появляется в профиле, но с пустыми значениями порта и ипа.. автоназначение AccessID работает. ACLEther я вообще не смог создать отдельными snmpset командами
Собственно хотелось бы услышать решение этой проблемы.. либо порядок команд, либо еще что то
Уважаемые сотрудники длинк, накой буй менять оиды и вообще систему создания ACL в разных моделях свичей?!?! все же прекрасно работает на 3526.. ну скопируйте на другую модель и всё

Какой IP адрес будут искать эти арпы?
Первые важные сообщения от клиента: DHCPDISCOVER и DHCPREQUEST, они идут широковещательно на udp 67 порт, никакие арпы там не используются. Варианты src IP действительно разные. Ну а дальше у клиента уже нормальный IP появляется.

Единственное, в момент предложения адреса сервером, клиент проверяет не занят ли он, отправляя ARP запрос. В моем ACL, такое обнаружение не произойдет, но я считаю это плюсом - получить конфликт IP адресов на экране более наглядно, чем непонятно откуда возникающее "подключение ограничено" и поиск причины в логах на сервере.

так в вашем же случае как раз сообщение о конфликте адресов не выскочит.

и уж поверьте - броткастово то бродкастово, но очень часто в живой сети запросы на DHCP не такие как вам кажется VISTA - посылает их от айпишки 0.0.0.0, ХР в случае стечения обстоятельств (на практике достаточно часто) от диапазона частной сети 169.254.ххх.ххх.... да это не АРПы будут, а АРП тоже разный бывает, и поверх айпи он ходит много, и тут уже имеет значение какой у него соурс айпишник...

господи - я это у же трижды написал...

To Sin555:

Перезвоните пожалуйста в понедельник в офис по телефону 744-00-99 доб.390.