отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
cancel
1312
Просмотры
20
Полезный материал
16
Ответы
Vladislav Vyakin
Beginner

IOS 15

Здравствуйте.

Пытался обновить 4500 до IOS 152-1.E1.

После обновления, на dhcp серверах всех vlan начали валится dhcp decline события, у пользователей начала постоянно выскакивать ошибка о дублироваии адресов в сети, в событиях "... обноруже конфликт IP-адресов 0.0.0.0 с системой ...."

откатил IOS, все стало нормально.

Пытался 6500 коммутаторы до 151-2.SY.

После обновления перестали работать LACP подключения к HP Flex-10 модулям и между 6500 и 4500 (хотя между двумя 6500 lacp работал).

откатил IOS, все стало нормально.

Подскажите, это какие-то новые настройки требуются или что-то не так пошло с обновлением(хотя все hash суммы проверял, все ок)?

1 УТВЕРЖДЕННОЕ РЕШЕНИЕ

Утвержденные решения

Кольцо после обновления вполне вероятно, иных объяснений такому количеству броадкастов не вижу.

То есть после обновления разблокировало po42, хотя должно было оставить его заблокированным при той же топологии. Это интересно. Проблем с линками вроде нет. Надо проверить, приходят ли BPDU на po42 c4510_2, и отправляются ли они с той стороны, есть подозрение, что нет.

Имеет смысл зарыться в bug toolkit и release notes на предмет багов в STP.

Просмотреть решение в исходном сообщении

16 ОТВЕТ 16
Vitaliy Zinatov
Rising star

пробовали:

clear ip dhcp conflict *

clear ip dhcp binding *

Насчет LACP с HP у васинтерфейс в сторону HP настроен как Active/Passive или в режиме ON?

-----------------------------------------------------------
Прошу вас оценивать и отмечать полезные для вас сообщения.
Please rate helpful answers.

----------------------------------------------------------- Прошу вас оценивать и отмечать полезные для вас сообщения. Please rate helpful answers.
Dmitriy Zhiznevskiy
Contributor

По DHCP:

1) Какова конфигурация?

2) Конфликт был именно на адрес 0.0.0.0?

3) Какой-нибудь специфический функционал вроде ISE, DHCP snooping и т.д. настроен?

4) База DHCP куда-нибудь сливается? (если нет, то эту недоработку имеет смысл первым делом поправить)

5) Клиенты должны отзываться на пинги со свитча?

6) Дебаги удалось снять?

По LACP:

1) Какова конфигурация?

2) Какую информацию удалось снять на момент наличия проблемы? В каком состоянии согласования были интерфейсы?

По обоим: насколько сложно будет воспроизвести проблему?

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

65 и 45 обновлял одновременно в НГ праздники, когда народу было мало, проблема c lacp всплыла сразу и решение было понятно, а  проблему с dhcp обнаружил не сразу. Влияло это на всех по разному, на некоторых компах сообщение о дублировании ip всплывало чуть ли не каждые 3 часа, некотрые ни чего не обычного не заметили, и только вчера разобрался, что это все таки ios, когда нашел даты с которых начались проблемы и откатился.

DHCP для основной сети на 2012 сервере. DHCP для ip телефонов на комутаторах. После некоторых поисков, обнаружил, что Wireshark на сервере ловит именно от клиентов dhcp decline, а не сам находит конфликты. Потом начал смотреть на коммутаторах там тоже появились адреса в ip dhcp conflict.

Да, в виндовых журналах конфликт именно с адресом 0.0.0.0

Специфичных настроек нет.

Не совсем понял про слив dhcp базы? что это и зачем?

Все клиенты друг друга видят.

Дебаги не снимал.

По LACP толком времени нет было разбираться, большое время простоя поиметь не очень хорошо.

Как я говорил lacp перестал работать так же между 65 и 45, и именно это соединения я просматривал.

В приложении логи которые остались.

Терущая (рабочая конфигурация)

6500:

interface Port-channel41

description Link c6509_1 to c4510_2

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

mls qos trust dscp

interface TenGigabitEthernet4/1

switchport

switchport mode trunk

mls qos trust dscp

channel-protocol lacp

channel-group 41 mode active

interface TenGigabitEthernet4/5

switchport

switchport mode trunk

mls qos trust dscp

channel-protocol lacp

channel-group 41 mode active

4500:

interface Port-channel41

description Link c4510_2 to c6509_1

switchport

switchport mode trunk

interface TenGigabitEthernet5/1

switchport mode trunk

flowcontrol receive off

channel-protocol lacp

channel-group 41 mode active

interface TenGigabitEthernet6/1

switchport mode trunk

flowcontrol receive off

channel-protocol lacp

channel-group 41 mode active

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

DHCP:

Похоже, в 15.0 все-таки были некоторые изменения... В общем, попробуйте сделать глобально "ip device tracking probe delay 10". Подробнее -  http://www.cisco.com/en/US/products/ps6638/products_white_paper09186a0080c1dbb1.shtml .

"Слив базы" - это http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfdhcp.html#wp1018925 . Причина: после ребута свитча он по умолчанию забывает все аренды, начинает выдавать их заново вслепую, и в определенных сценариях может выдать кому-то уже ранее выданный адрес.

LACP:

Судя по приложенным выводам, LACP в полном порядке.

1) Вы проверяли состояние STP с обеих сторон? Какой вид STP задействован, в какой стороне рут?

2) В логах никаких странностей не было?

3) 23 мегабита исходящего трафика - это broadcast и unknown unicast, или что-то более осмысленное? Есть идеи по поводу природы поразительно небольшого количества входящего трафика? Какие-нибудь маки виднелись?

Если никакой иной информации собрано не было, то у меня нет идей кроме "повторить обновление и без спешки посмотреть, что происходит".

Спасибо за статью по DHCP, по ходу это мой случай, при случае еще раз попробую обновиться.

по LACP

STP смотрел только со стороны 45ого. Root для всех 6509_1, Altn 6509_2.

на 45

spanning-tree mode pvst

на 65_1

spanning-tree mode pvst

spanning-tree vlan 1-1001 priority 24576

на 65_2

spanning-tree mode pvst

spanning-tree vlan 1-1001 priority 28672

Схема соединения

6509_1  ==== 6509_2

   ||        >X<       ||            (то что в центре, это изображает lacp между 6509_1 - 4510_2  и 6509_2 - 4510_1)

4510_1           4510_2

Не могу сейчас уже сказать почему, но когда смотрел stp 65_2 был Desg. Хотя сейчас, в рабочем состоянии, он Altn. Еще нашел немного логов, во вложении.

Еще, что мне показалось странным, это то что 65й в сторону 45ого трафик шлет (судя по счетчикам), а обратно не приходит.

То что трафика нет, это нормально, это НГ праздники, никого не было

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

"но когда смотрел stp 65_2 был Desg"

Desg - состояние порта, а не .

Можете дать настройки всех транков между свитчами и конфигурацию STP на каждом из свитчей? А по схеме - что значит ">X<"? В идеале, стоило бы нарисовать нормальную схему STP домена, обозначив положение рута и состояние всех портов.

Кольцо вроде мало вероятно, уже давно бы всплыло.

На счет Desg, я вот что имел ввиду

Когда обновил IOS

c4510_2#sh spanning-tree

Po41                Root FWD 1         128.1321 P2p

Po42                Desg FWD 1         128.1322 P2p

Сейчас (в рабочем состоянии)

c4510_2#sh spanning-tree

Po41                Root FWD 1         128.1321 P2p

Po42                Altn BLK 1         128.1322 P2p

Схема текущая.

sh.png

Цифрами обозначены номера port-channel'ов. Конфиг STP и портов вроде уже привел, на всех аналогичных портах коммутаторов все настроено идентично.