DES-3526

Boot PROM Version : Build 5.00.009
Firmware Version : Build 6.20.B07
Hardware Version : A4G

настраиваю multicast через ISM-vlan. Схема доступа - "vlan на абонента"

Соответственно в конфиге:

# SNOOP

enable igmp_snooping
create igmp_snooping multicast_vlan Multicast 49
config igmp_snooping multicast_vlan Multicast state enable replace_source_ip 0.0.0.0 member_port 1-24 source_port 25-26

После этого в логе после перезагрузки появляются сообщения:

25 00000 days 00:00:44 Configuration had 0 syntax error and 1 execute error

Изыскания показали, что "execute error" вызывает следующая строка в конфиге:

# MULTI FILTER

config max_mcast_group vlanid 49 max_group infinite


switch:admin#config max_mcast_group vlanid 49 max_group infinite
Command: config max_mcast_group vlanid 49 max_group infinite

Fail!

Но добавляется она в конфиг автоматически при создании ISM-vlan.
Как лечить? Аргумент "на работу свича это не влияет" - не удовлетворяет, т.к любая ошибка исполнения есть аномалия и никогда не знаеешь как, где и каким образом она еще может повлиять.


Вопрос номер 2:
На том же свиче непосредственно после загрузки никогда не синхронизируется время с SNTP.

switch:admin#sh sntp
Command: show sntp

Current Time Source : System Clock
SNTP : Enabled
SNTP Primary Server : 192.168.200.2
SNTP Secondary Server : 192.168.200.3
SNTP Poll Interval : 900 sec

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

Вопрос 3:

Можно ли надеяться, что в DES-3526/3200 появится Broadcast NTP ???

Господа Модераторы!
Народ безмолвствует...
Одна надежда на ВАС.
Что скажете?
Готов выложить любую доп. информацию.

1. Вижу на стенде, отпишу в ШК
2. Синхронизируется сразу после загрузки - с коммутатора летит NTP запрос.
Настройки:

3. Нет.

Настройки:

enable sntp
config time_zone operator + hour 4 min 0
config sntp primary 192.168.200.2 secondary 192.168.200.3 poll-interval 900
config dst disable


порт 25 подключен к циске WS-C3560G:

interface GigabitEthernet0/47
switchport trunk encapsulation dot1q
switchport mode trunk
mls qos vlan-based
no cdp enable

192.168.200.2 и .3 - два других "каталиста", которые в свою очередь синхронизируются от NTP.

К порту 26 подключен DES-3200 с точно такими же настройками SNTP.
3200 синхронизируется сразу же после после перезагрузки, а этот 3526 - только в следующем цикле.

Я на снифе отчетливо вижу запрос ntp сразу после загрузки, установленный у меня tftpd32 отдает коммутатору время, все в порядке.
Смотрите, отвечает ли циска ему, и в чем могут быть отличия пакетов DES-3200 и DES-3526 в вашей ситуации.

Не прилетает от него ни чего. Если делаю:
disable sntp
и сразу же
enable sntp

то пакеты прилетают и время синхронизируется.

Объяснение я вижу только одно: циска при включенном STP (no spanning-tree portfast) не сразу переводит порт в forwarding-режим. Это нормальное поведение. А д-линк видимо посылает запрос до того, как порт фактически активируется и не получив ответа не предпринимает попыток до следующего цикла синхронизации.

IMHO, не корректно поведение именно со стороны д-линка. Необходимо или контролировать и ждать пока по STP порты реально установятся в forwarding-режим, либо делать задержку между поднятием порта и отсылкой запроса. А слать запросы не весть куда - это как-то не адекватно

У вас настроен именно stp? У него длительное время поднятия порта - переходите на mstp, пусть даже и с одним instance - все таки в его основе лежит rstp.
Ситуацию посмотрю.

Поведение DES-3526 следующее.
Версия - стандартный STP. Вот что показывает лабный тест.
После загрузки коммутатора как только один из портов может передавать трафик - допустим это клиентский порт с выключенным stp - коммутатор генерирует ntp запрос в активные порты. Так как в этот момент аплинк еще находится в Discarding/Learning state, запрос в него не уходит. И коммутатор ждет polling-interval. Если отключить всех клиентов и оставить включенным только аплинк - ntp запрос будет сформирован спустя несколько секунд после перевода аплинка в Forwarding state, то есть сразу после того как у коммутатора появился порт, в который можно передать запрос.
Если использовать RSTP(MSTP) - аплинк переводится в forwarding state быстрее, чем формируется ntp запрос после загрузки коммутатора, и синхронизация происходит сразу после загрузки.
Резюме: используйте MSTP

У нас именно MSTP:

cisco#sh spanning-tree

MST0
Spanning tree enabled protocol mstp
Root ID Priority 32768
Address *************
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

cisco#sh spanning-tree mst

##### MST0 vlans mapped: 1-4094

Из вашего ответа следует, что при наличии подключенных клиентов (а кто же их отключать то ради этого будет???) данная проблема не решается... Т.о. IMHO все равно не корректно поведение коммутатора... зачем слать запрос клиентам, если порт, в котором управляющий в-лан, еще не поднят???

Отключил от тестового коммутатора всех клиентов (физически выдернул из портов). Оставил только аплинк.
Перезагрузил.
Время все равно не синхронизировалось.

Отслеживайте состояние портов у циски-длинка и смотрите снифером, когда формируется ntp запрос.
Как вариант - покрутите таймеры mstp

А по первому вопросу какой-то результатт будет?
Ответили, что отписались в ШК - и все....

Пофиксят к новому году.

Фикс execute error (6.20.B09) выложен в теме с прошивками.

Проверили.
Сейчас конфиг грузится без ошибок, спасибо.