отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

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 суммы проверял, все ок)?

Теги (3)
1 УТВЕРЖДЕННОЕ РЕШЕНИЕ

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

Re: IOS 15

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

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

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

16 ОТВЕТ.

IOS 15

пробовали:

clear ip dhcp conflict *

clear ip dhcp binding *

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

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

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

IOS 15

По DHCP:

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

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

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

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

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

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

По LACP:

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

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

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

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

New Member

Re: IOS 15

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

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

Re: IOS 15

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, или что-то более осмысленное? Есть идеи по поводу природы поразительно небольшого количества входящего трафика? Какие-нибудь маки виднелись?

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

New Member

Re: IOS 15

Спасибо за статью по 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ого трафик шлет (судя по счетчикам), а обратно не приходит.

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

Re: IOS 15

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

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

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

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

New Member

Re: IOS 15

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

На счет 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 и портов вроде уже привел, на всех аналогичных портах коммутаторов все настроено идентично.

Re: IOS 15

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

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

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

Re: IOS 15

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

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.1SY/release_notes.html , искать по словам "Per-VLAN Spanning Tree (PVST) mode".

Рекомендую заранее перевести всех на RSTP командой spanning-tree mode rapid-pvst (можно и об MST задуматься). Конечно, у RSTP должна остаться обратная совместимость, иначе это было бы форменным свинством со стороны циски , но мало ли (комментарии со стороны сотрудников TAC приветствуются)... Моя догадка: после выполнения этого шага на всех свитчах в L2 домене проблема больше не возникнет. Да и вообще, это давно надо было сделать.

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

New Member

IOS 15

Спасибо за ссылку. Если получится, в воскресенье еще раз попробую обоновиться.

IOS 15

Если после перехода на RSTP что-то не заработает, то нужна подробная информация по всем транкам - на уровне физических интерфейсов, LACP и STP, а также логи.

New Member

IOS 15

Переключился на rstp. Обновил прошивки еще раз. C lacp проблема оказалась действительно в кольце. На 3ем port-channel не было явно указано encapsulation dot1q, и после обновления тут получалось кольцо. Странно, но до обновления все работало нормально. Пересобрал port-channel с явным указанием все заработало.

А с dhcp все таки что-то не так. После указания

ip device tracking probe delay 10

Количество конфликтов вроде уменьшилось, но все равно дубликаты появляются. Хочу попробовать wireshark'ом поискать кто с кем конфликтует.

IOS 15

"На 3ем port-channel не было явно указано encapsulation dot1q, и после обновления тут получалось кольцо. "

Странно как-то. Вы делали show int po3 switchport с обеих сторон во время проблемы? На конфиги портов и port-channel посмотреть можно?

"но все равно дубликаты появляются"

Дубликаты на 0.0.0.0, или на нормальные адреса?

New Member

Re: IOS 15

Во время проблемы(после обновления) делал:

interface Port-channel3

switchport

mls qos trust dscp

interface TenGigabitEthernet5/4

switchport

mls qos trust dscp

channel-protocol lacp

channel-group 3 mode active

!

interface TenGigabitEthernet5/5

switchport

mls qos trust dscp

channel-protocol lacp

channel-group 3 mode active

c6509_2#sh int po 3 switchport

Name: Po3

Switchport: Enabled

Administrative Mode: dynamic desirable

Operational Mode: trunk

Administrative Trunking Encapsulation: negotiate

Operational Trunking Encapsulation: isl

Operational Dot1q Ethertype:  0x8100

Negotiation of Trunking: On

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 1 (default)

Administrative Native VLAN tagging: enabled

Operational Native VLAN tagging: disabled

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Operational private-vlan: none

Trunking VLANs Enabled: ALL

Pruning VLANs Enabled: 2-1001

Unknown unicast blocked: disabled

Unknown multicast blocked: disabled

Вот текущий конфиг(то что сейчас работает)

interface Port-channel3

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

mls qos trust dscp

interface TenGigabitEthernet5/4

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

mls qos trust dscp

channel-protocol lacp

channel-group 3 mode active

interface TenGigabitEthernet5/5

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

mls qos trust dscp

channel-protocol lacp

channel-group 3 mode active

c6509_2#sh int po 3 switchport

Name: Po3

Switchport: Enabled

Administrative Mode: trunk

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Operational Dot1q Ethertype:  0x8100

Negotiation of Trunking: On

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 1 (default)

Administrative Native VLAN tagging: enabled

Operational Native VLAN tagging: disabled

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Operational private-vlan: none

Trunking VLANs Enabled: ALL

Pruning VLANs Enabled: 2-1001

Unknown unicast blocked: disabled

Unknown multicast blocked: disabled

-----

Конфликт на 0.0.0.0 - и это вроде как правильно в соответствии с RFC

http://www.itcertnotes.com/2011/08/windows-xp-and-windows-7-gratuitous.html

Я пока еще  до конца не уверен, но предполагаю, что проблема где-то в совместимости с виртуализацией.

У нас работает Citrix XenDesktop и Citrix Provisioning.

Виртуалки загружаются черех pxe. И тут я часто вижу странное поведение: при загрузке VM получает ip и начинает загружаться, когда загрузится винда и начинает пытаться получиться ip, тот адрес с которым VM загружалась, dhcp метит как BAD и выдает уже другой адрес.

Как я понимаю это связано именно с коммутаторами, так как подобное поведение присутствует на разных платформах (и XenServer и ESXi) и появилось только после обновления IOS на 4500.

Еще я не совсем понял, изменит ли что-то команда

ip device tracking probe delay 10

если

c6509_2#show ip device tracking all

IP Device Tracking = Disabled

Сообщение отредактировал: Vlad Vyakin

New Member

Re: IOS 15

Нашел такую же проблему с dhcp и это похоже затрагивает всю 4k платформу.

https://supportforums.cisco.com/thread/2239656

Это было оформлено как bug CSCuj04986, у которого в решении написано:

No release planned to fix this bug

По рекоммендации на всех 4500 на аплинках поставил

ip device tracking max 0

Проблема с dhcp решилась. Спасибо.

Re: IOS 15

Что-то я прозевал сообщение выше...  Ну да, DTP не отработал (отключен с той стороны?), эта сторона захотела ISL, та сторона - 802.1q, в результате линк не работает. Но странно, что это вызвало кольцо.  Рад, что проблема с DHCP решилась.

471
Просмотры
20
Полезный материал
16
Ответы