Jump to content

Recommended Posts

Posted

Где-то с неделю назад началась проблема - одновременно, несколько раз в день перезагружаются 30-40-50 свичей. Сначала не придали этому значение, подумали, что свет моргает, какие-то проблемы с электропитанием. Однако, проблема стала повторяться периодически - день работает нормально, на следующий день 5-6 раз в день перегрузятся свичи. Стали подозревать ЛанБиллинг ( внем есть модуль, который опрашивает свичи), отключили его - не помогло. Сегодня отключили совсем управляющий VLAN, тоже не дало результата. Свичи доступа используем FoxGate 6224 (по железу аналог Edgecore). На центральном свиче в логе видим сообщения:

Sep 18 08:06:45 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/1, changed state to DOWN

Sep 18 08:06:45 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/2, changed state to DOWN

Sep 18 08:06:45 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/3, changed state to DOWN

Sep 18 08:06:45 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/9, changed state to DOWN

Sep 18 08:06:45 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/13, changed state to UP

Sep 18 08:06:45 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/15, changed state to UP

Sep 18 08:06:45 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/16, changed state to UP

Sep 18 08:06:45 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/18, changed state to DOWN

Sep 18 08:06:45 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/19, changed state to DOWN

Sep 18 08:06:46 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/21, changed state to UP

Sep 18 08:06:46 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/22, changed state to UP

Sep 18 08:06:46 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/23, changed state to UP

Sep 18 08:06:46 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/16, changed state to DOWN

Sep 18 08:06:46 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/17, changed state to UP

Sep 18 08:06:46 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/20, changed state to UP

Sep 18 08:06:46 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/21, changed state to UP

Sep 18 08:06:46 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/22, changed state to UP

Sep 18 08:06:46 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/26, changed state to UP

Sep 18 08:06:47 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/28, changed state to UP

Sep 18 08:06:47 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/30, changed state to UP

Sep 18 08:06:47 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/31, changed state to UP

Sep 18 08:06:47 172.17.0.111 %Sep 18 07:03:22 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/32, changed state to UP

Sep 18 08:06:47 172.17.0.111 %Sep 18 07:03:23 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/1, changed state to UP

Sep 18 08:06:47 172.17.0.111 %Sep 18 07:03:23 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/2, changed state to UP

Sep 18 08:06:47 172.17.0.111 %Sep 18 07:03:23 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/3, changed state to UP

Sep 18 08:06:47 172.17.0.111 %Sep 18 07:03:23 2011 MODULE_PORT[tphyDaemon]:%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/9, changed state to UP

 

 

В чем может быть проблема? Как ее выявить?

Posted

В приведенном логе, пропадают линки. А вы смотрели логи самих коммутаторов? Уверены что они именно перезагружались?

Posted (edited)

В приведенном логе, пропадают линки. А вы смотрели логи самих коммутаторов? Уверены что они именно перезагружались?

 

Да проверяем все свитчи, на них, UP TIME одинаковый,к примеру, 0 дней 0 часов 20 минут

 

sh ver показывает

Last reboot is warm reset.

Uptime is 0 weeks, 0 days, 0 hours, 52 minutes

 

в логе свитча

 

69 Jan 01 03:00:43 2006 <critical> DEFAULT[zIMI]:System warm restart...

 

68 Jan 01 00:00:00 2006 <critical> DEFAULT[app_root]:switch is booting, software version:S6224-S2_6.1.94.82...

Edited by resident_k
Posted

Edgecore =)... по snmp что-то получаете с них? была ситуация когда при попытке получить с L3 Edgecore конфиг (8/24-SFP портов , модель не помню), они ребутались.

Posted

Edgecore =)... по snmp что-то получаете с них? была ситуация когда при попытке получить с L3 Edgecore конфиг (8/24-SFP портов , модель не помню), они ребутались.

 

Cacti опрашивает все свитчи по СНМП, однако, проблемы с этим не было, началось с неделю назад. Сегодня уже отключали управляющий VLAN совсем (в нем идет все управление и СНМП в т.ч.) - не помогло.

Подозрение уже что некий "хитрый" броадкаст пакет перегружает свитчи. У нас все свитчи доступа FoxGate , они и перегружаются. Другие свитчи - Dlink 3100-24TG и Nexthop на 48SFP - работают без проблем.

Posted

Миррорить магистральный порт проблемного (а может даже наоборот) свитча на отдельную машину и смотреть что прошло по сети в момент ребута, сложно что-либо еще придумать.

Posted
S6224-S2_6.1.94.82
Ммм, перешить на поновее не пробовали? Публично вывалили новую прошивку. Да и депса стоит подолбать, авось чего выгорит. Касательно вашего вопроса: а не мог кто-то по snmp перегружать свитчи? Надеюсь хотя бы список доверенных хостов и комьюнити для snmp заданы.
Posted
S6224-S2_6.1.94.82
Ммм, перешить на поновее не пробовали? Публично вывалили новую прошивку. Да и депса стоит подолбать, авось чего выгорит. Касательно вашего вопроса: а не мог кто-то по snmp перегружать свитчи? Надеюсь хотя бы список доверенных хостов и комьюнити для snmp заданы.

 

Комьюнити задано, доверенный хост - соновной сервак, все заведено в один ВЛАН для управления свитчами. ВЛАН этот уже отключали, но не помогло. Прошивку завтра попробуем обновить и ДЕПС напрячь.

Posted

Мультикаст от пользователей попробуйте запретить хоть на коренном свитче временно.

 

Мы с линксисом долго решала проблему с софтом, какой-то мультикаст пакетик вешал сразу все свитчи с бщим пользовательским вланом.

Но перед рестартом они в сислог успевали об этом написать.

Posted
все заведено в один ВЛАН для управления свитчами. ВЛАН этот уже отключали, но не помогло.
Возможно таки причина перезагрузки не в явной команде по snmp или telnet, но часом этот vlan не маршрутизируется с пользовательскими?

Да, если желаете, покажите свой конфиг, у меня как-то именно такого глюка не замечалось за фоксами.

Posted (edited)

Да, если желаете, покажите свой конфиг, у меня как-то именно такого глюка не замечалось за фоксами.

 

У нас тоже за два года работы с ними не замечалось ...

 

конфиг

\\---------------

service password-encryption

hostname Microsoft-2-115

sysLocation

sysContact

password 7 f8111023f837f5fd8f02aac6ea8ffa14

enable password level 15 7 f8111023f837f5fd8f02aac6ea8ffa14

username admin privilege 15 password 7 f8111023f837f5fd8f02aac6ea8ffa14

authentication securityip 172.17.0.1

clock timezone Kiev add 3 0

ip http server

snmp-server enable

snmp-server securityip 172.17.0.1

snmp-server community rw XXXXXXX

snmp-server community ro XXXXXXXX

snmp-server enable traps

no rmon enable

service dhcp

ip dhcp snooping enable

ip dhcp snooping binding enable

ip dhcp snooping binding arp

ip dhcp snooping information enable

vlan 1

vlan 300

name users

vlan 303

name admin

vlan 400

name IPTV

multicast-vlan

multicast-vlan association 300

firewall enable

access-list 6000 deny ip any-source 239.192.0.192 0.0.0.63

access-list 6000 permit ip any-source 239.192.0.1 0.0.0.127

access-list 6000 permit ip any-source 239.192.0.128 0.0.0.63

access-list 6000 deny ip any-source any-destination

access-list 6011 permit ip any-source 239.192.0.1 0.0.0.255

access-list 6011 deny ip any-source any-destination

access-list 1 deny host-source 10.100.1.1

access-list 1 deny host-source 10.100.2.1

access-list 1 deny host-source 10.100.2.2

access-list 1 deny host-source 10.100.2.3

access-list 1 deny host-source 10.100.2.4

access-list 1 deny host-source 10.100.2.5

access-list 1 deny host-source 10.100.2.6

access-list 1 deny host-source 10.100.2.7

access-list 1 deny host-source 10.100.2.8

access-list 1 deny host-source 10.100.2.9

access-list 1 deny host-source 10.100.2.10

access-list 1 deny host-source 10.100.2.11

!

multicast destination-control

!

Interface Ethernet0/0/1

ip multicast destination-control access-group 6000

switchport access vlan 300

ip access-group 1 in

ip dhcp snooping action blackhole recovery 60

!

Interface Ethernet0/0/2

ip multicast destination-control access-group 6000

switchport access vlan 300

ip access-group 1 in

ip dhcp snooping action blackhole recovery 60

!

Interface Ethernet0/0/3

ip multicast destination-control access-group 6000

switchport access vlan 300

ip access-group 1 in

ip dhcp snooping action blackhole recovery 60

!

Interface Ethernet0/0/4

ip multicast destination-control access-group 6000

switchport access vlan 300

ip access-group 1 in

ip dhcp snooping action blackhole recovery 60

!

!

Interface Ethernet0/0/25

ip multicast destination-control access-group 6000

switchport access vlan 300

ip access-group 1 in

ip dhcp snooping action blackhole recovery 60

!

Interface Ethernet0/0/26

switchport mode trunk

switchport trunk allowed vlan 300;303;400

ip dhcp snooping trust

!

interface Vlan303

ip address 172.17.2.115 255.255.0.0

!

ip igmp snooping

ip igmp snooping vlan 400

ip igmp snooping vlan 400 immediately-leave

!

sntp polltime 3600

sntp server 172.17.0.1

!

no login

!

!

end

 

 

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

Edited by resident_k
Posted

А консольный порт есть у свитчей? При 5-6 раз на дню я бы и консольку помониторил в первую очередь....

 

Дык, оно если бы регулярно было, а то день работает нормально, потом начинает "колбасить".

По поводу того как мониторить консоль не совсем понял ...

 

Заметил еще, что перегружаются, все свитчи доступа FoxGate - больше сотни шт., перегружаются не одновременно, а друг за другом, как цепная реакция, в течении 2-3 мин, порядок (какой свитч идет за каким) не четкий, но более-менее выдерживается.

Отключили на некоторых свитчах СНМП, посмотрим даст ли результат ...

Posted (edited)

Отключили на некоторых свитчах СНМП, посмотрим даст ли результат ...

Я бы на Вашем месте с перепугу уже 10 раз бы зазеркалил трафик и проверил связность менеджмент-сети с остальной сетью.

Edited by GFORGX
Posted

Отключили на некоторых свитчах СНМП, посмотрим даст ли результат ...

 

только что глюкнуло, результат неоднозначный - из 3 свитчей, на которых отключили СНМП, 2 перегрузились один нет.

 

Да еще - в сети работает мультикаст (IPTV), работает уже около полугода, проблем не было, попробуем его отключить еще ...

Posted

На свичах Ruby есть опция, пинговать определенный хост с определенной периодичностью, если он не доступен в этот период - свич ребутится. (например 5 циклов посылки ICMP в течение 5 минут)

Как то тоже было что разом начали перегружаться штук 40 рубиков. Но сразу поняли в чем дело, стал недоступен хост, который они пинговали (прикрыли файером не вспомнив о его задаче отвечать на такие alive пинги).

 

Здесь не может быть такой фичи ?

Posted

А консольный порт есть у свитчей? При 5-6 раз на дню я бы и консольку помониторил в первую очередь....

 

Дык, оно если бы регулярно было, а то день работает нормально, потом начинает "колбасить".

По поводу того как мониторить консоль не совсем понял ...

Консоль это последовательный порт на свитче, который можно соединить с COM-портом в компе и терминальной программой управлять консолью свитча. Как правило в консоль сыпется весь дебаг процесса (пере)загрузки/работы и можно попытаться поймать причину.

Posted
Можно попросить ваш конфиг для фоксгейтов в личку, посмотрим, может что-то для себя найдем полезное.
Завтрабуду на работе - выложу.
Posted (edited)

На свичах Ruby есть опция, пинговать определенный хост с определенной периодичностью, если он не доступен в этот период - свич ребутится.

Здесь не может быть такой фичи ?

 

Такого не настраивали

 

Как правило в консоль сыпется весь дебаг процесса (пере)загрузки/работы и можно попытаться поймать причину.

 

Попробуем и такой вариант, хотя это и не так просто - свичи на чердаках и в подъездах стоят

 

Еще одну закономерность заметили - перегружаются все свитчи, которые прописаны в ЛанБиллинге, те свитчи, которые в Ланбиллинге не прописаны - не перегружаются (к примеру наш офисный FoxGate). Прописали его в биллинг, посмотрим будет ли дергаться.

Edited by resident_k
Posted

А как LanBilling работает с коммутаторами? snmp/telnet?

 

Lanbilling по snmp порты опрашивает и блокирует, но отключение snmp не помогло

 

Я так погляжу, у Вас вэбморда включена - используется?

 

нет

Posted

1. Т.е. счетчики, состояние порта и только? Или что-то еще?

 

 

2. Я предпочитаю выключать все лишнее, но лезть с советами не буду. Лучше завтра свой конфиг покажу и, ежели пожелаете, обсудим. Единственное, что у меня пока мультикаста нет, чтобы в полный рост проверить вашу проблему. Несколько свитчей не пытались перешить?

 

 

Posted

1. Т.е. счетчики, состояние порта и только? Или что-то еще?

 

Блокирует порт, клиентам с отрицательнім балансом

 

2. Я предпочитаю выключать все лишнее, но лезть с советами не буду. Лучше завтра свой конфиг покажу и, ежели пожелаете, обсудим. Единственное, что у меня пока мультикаста нет, чтобы в полный рост проверить вашу проблему. Несколько свитчей не пытались перешить?

 

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

Posted

IMHO надо смотреть на более банальные вещи.

Электроснабжение.

Совсен напряжение могло не пропадать, А вот "проседать" или "прыгать" - у нас например регулярно. И тоже десятками перегружались

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.