spruce Posted July 26, 2011 Posted July 26, 2011 Добрый день. Наблюдаем разрывы PPPoE сессий в части вланов без определенной периодичности (от 10 минут и до нескольких часов) по непонятным причинам. В качестве BRAS используется Ericsson SE100(+ 2 платы по 2 гига). Он установлен в одной стойке с Cisco C6500 и включен в него же. С циски идет на агрегацию DGS-3627G (используется только как L2) и дальше на доступ из управляемых L2 свитчей D-Link DES-30xx, DES-32xx, DES-35xx к абонентам. Первым делом начали проверять флудящий трафик - non-unicast не превышает 100pps, пинг до локального шлюза (который висит на C6500) без потерь и не превышает 1ms - следовательно это не флуд... В момент обрыва сессии пинг до локального шлюза продолжает идти без изменений - сбоит и не физика... Может это брас? Начали проверять интерфейсы на нем, но на один интерфейс приходят и вланы в которых все работает отлично, а также те вланы, в которых наблюдаем разрывы...В аккаунтинге брас пишет - разрыв сессии по причине Lost-Carrier... В данный момент собираю tcpdump, может что-то проясниться... Подскажите, как еще можно отследить, почему возникают такого рода разрывы? Спасибо. Вставить ник Quote
ingress Posted July 26, 2011 Posted July 26, 2011 Он установлен в одной стойке с Cisco C6500 и включен в него же. плата в которую включен? Вставить ник Quote
macharius Posted July 26, 2011 Posted July 26, 2011 1. какой софт у вас стоит на se100? 2. сколько абонентов сейчас на коробке? попробуйте дать в контексте где абоненты подключены: ter mon debug ppp exception И еще включите keepalive на ppp, например так ppp keepalive check-interval seconds 10 Вставить ник Quote
terrible Posted July 26, 2011 Posted July 26, 2011 Брас, помимо аккаунтинга ещё о чём-либо сообщает? Может в логи срёт чем-нибудь? Нагрузка пиковая или в пределах нормы? Внимательно читайте то, что пишут вам свичи агрегации и доступа. Кстати, доступ к вас как настроен? (максимально подробно) Вставить ник Quote
spruce Posted July 26, 2011 Author Posted July 26, 2011 Он установлен в одной стойке с Cisco C6500 и включен в него же. плата в которую включен? плата - 16 port GE RJ45 WS-X6316-GE-TX 1. какой софт у вас стоит на se100? 2. сколько абонентов сейчас на коробке? попробуйте дать в контексте где абоненты подключены: ter mon debug ppp exception И еще включите keepalive на ppp, например так ppp keepalive check-interval seconds 10 Софт: Redback Networks SmartEdge OS Version SEOS-6.2.1.6-Release Built by sysbuild@SWB-node04 Fri Dec 17 09:18:59 PST 2010 Copyright © 1998-2010, Redback Networks Inc. All rights reserved. System Bootstrap version is PowerPC,rev2.0.1.4 Installed minikernel version is 2.7 Router Up Time - 125 days, 21 hours 44 minutes 8 secs ppp keepalive check-interval seconds 10 - уже включено debug ppp exception - собирается Вставить ник Quote
spruce Posted July 26, 2011 Author Posted July 26, 2011 Брас, помимо аккаунтинга ещё о чём-либо сообщает? Может в логи срёт чем-нибудь? Нагрузка пиковая или в пределах нормы? Внимательно читайте то, что пишут вам свичи агрегации и доступа. Кстати, доступ к вас как настроен? (максимально подробно) Сейчас логи собираю, посмотрю что вывалит в момент разрыва. Разрывы происходят в разное время суток, и в пиковые моменты (когда трафик на всех интерфейсах по ~700-800Mbps и unicast ~100kpps), и в ночные часы, когда трафик мимнимален... цпу - 2%. Свитчи агрегации и доступа на эту тему ничего не пишут, на доступе включен только лупдетект, на агрегации вобще ничего не включено, только прогоняются вланы от каталиста до свитчей доступа.. Проблема наблюдается на любых ос, *nix, windows без разницы... Вставить ник Quote
XeonVs Posted July 26, 2011 Posted July 26, 2011 Такая ерунда бывает, если абонент словил вирусню которая повреждает IP-стек и pppoe-клиент банально не отправляет PADT при разрыве сессии. Вставить ник Quote
spruce Posted July 26, 2011 Author Posted July 26, 2011 Такая ерунда бывает, если абонент словил вирусню которая повреждает IP-стек и pppoe-клиент банально не отправляет PADT при разрыве сессии. Была такая мысль, что это вирусняк, но разрыв у разных сессий в одно время. А также, как уже писал, сам сейчас подключен на машине с линуксом... Вчера весь день был подключен по PPPoE в другом влане, разрывов не было. Сейчас подключен в влане с разрывами, и разрывы есть. Вставить ник Quote
tartila Posted July 26, 2011 Posted July 26, 2011 Такая ерунда бывает, если абонент словил вирусню которая повреждает IP-стек и pppoe-клиент банально не отправляет PADT при разрыве сессии. Была такая мысль, что это вирусняк, но разрыв у разных сессий в одно время. А также, как уже писал, сам сейчас подключен на машине с линуксом... Вчера весь день был подключен по PPPoE в другом влане, разрывов не было. Сейчас подключен в влане с разрывами, и разрывы есть. ;))) У Вас петля в VLAN появляется просто. Уменьшите время перепосыла контрольных пакетов на свитчах доступа скажем до 3 секунд и время блокировки по петле до макс. и смотрите, кто уйдет в LBD. Сделайте тоже самое на транзитных портах, жалко потерять пару свитчей, но петли ловить надо. Вставить ник Quote
spruce Posted July 26, 2011 Author Posted July 26, 2011 Наврал, пинг до локального шлюза тоже пропадает, наверно и правда петля где-то закралась... Вставить ник Quote
spruce Posted July 26, 2011 Author Posted July 26, 2011 Получается интересная ситуация, на циске spanning-tree блочит часть вланов с pppoe на всех портах за исключением одного, потом сразу же их поднимает. За время BLK-FWD сессия и рвется... Почему происходит эта блокировка на всех портах кроме одного, и почему сразу на пачке вланах, которые идут вообще в разные стороны на циске? PS: какие то странные интервалы срабатывания - то 10 минут, то несколько часов без проблем... Вставить ник Quote
Negator Posted July 26, 2011 Posted July 26, 2011 Первым делом начали проверять флудящий трафик - non-unicast не превышает 100pps, пинг до локального шлюза (который висит на C6500) без потерь и не превышает 1ms - следовательно это не флуд... маловато для детекта флуд или нет :) Попробуйте дамп поснимать. Вероятно где то петля, флудящий свич или ложный PPPOE сервер. Сразу заблокируйте с помощью ACL на длинках весь ненужный броадкаст и фильтруйте PPPOE ответы сервера с абонентских портов -длинки это умеют вот навскидку для 3526: Блокируем ответы PPPOE сервера (PAD0)со всех портов кроме аплинка(25 порт). Если в сети используется PPPOE то этот профиль позволяет избавиться от левых PPPOE серверов. сreate access_profile packet_content_mask offset_16-31 0xFFFF00FF 0×0 0×0 0×0 profile_id 13 config access_profile profile_id 13 add access_id 1 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 1 deny config access_profile profile_id 13 add access_id 2 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 2 deny config access_profile profile_id 13 add access_id 3 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 3 deny config access_profile profile_id 13 add access_id 4 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 4 deny config access_profile profile_id 13 add access_id 5 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 5 deny config access_profile profile_id 13 add access_id 6 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 6 deny config access_profile profile_id 13 add access_id 7 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 7 deny config access_profile profile_id 13 add access_id 8 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 8 deny config access_profile profile_id 13 add access_id 9 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 9 deny config access_profile profile_id 13 add access_id 10 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 10 deny config access_profile profile_id 13 add access_id 11 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 11 deny config access_profile profile_id 13 add access_id 12 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 12 deny config access_profile profile_id 13 add access_id 13 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 13 deny config access_profile profile_id 13 add access_id 14 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 14 deny config access_profile profile_id 13 add access_id 15 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 15 deny config access_profile profile_id 13 add access_id 16 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 16 deny config access_profile profile_id 13 add access_id 17 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 17 deny config access_profile profile_id 13 add access_id 18 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 18 deny config access_profile profile_id 13 add access_id 19 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 19 deny config access_profile profile_id 13 add access_id 20 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 20 deny config access_profile profile_id 13 add access_id 21 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 21 deny config access_profile profile_id 13 add access_id 22 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 22 deny config access_profile profile_id 13 add access_id 23 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 23 deny config access_profile profile_id 13 add access_id 24 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 24 deny config access_profile profile_id 13 add access_id 26 packet_content_mask offset_16-31 0×88630007 0×0 0×0 0×0 port 26 deny Вставить ник Quote
spruce Posted July 27, 2011 Author Posted July 27, 2011 (edited) Первым делом начали проверять флудящий трафик - non-unicast не превышает 100pps, пинг до локального шлюза (который висит на C6500) без потерь и не превышает 1ms - следовательно это не флуд... маловато для детекта флуд или нет :) Вобще флуд достаточно хорошо мониторится в системах типа cacti, по скачку non-unicast на графике сразу все видно (даже если на эти интерфейсы ходит мультикаст)...вобщем мы этим пользуемся и это помогает в таким моменты. Но щас совсем другой момент. Циска на корневой агрегации вырубает вланы по pvst.. включил debug: c6500#sh debugging Spanning Tree: Spanning Tree general debugging is on Spanning Tree Exceptions debugging is on Spanning Tree BPDU Transmitted debugging is on Spanning Tree BPDU Received debugging is on Spanning Tree event dump debugging is on Spanning Tree snapshot debugging is on Spanning Tree event debugging is on Spanning Tree root changes debugging is on Spanning Tree configuration debugging is on Spanning Tree etherchannel support debugging is on Spanning Tree PVST+ debugging is on Spanning Tree uplinkfast debugging is on Spanning Tree Distributed Uplinkfast debugging is on Spanning Tree uplinkfast exceptions debugging is on Spanning Tree backbonefast general debugging is on Spanning Tree backbonefast detail debugging is on Spanning Tree backbonefast exceptions debugging is on Spanning Tree optimized bpdu handling debugging is on Spanning Tree optimized bpdu handling detail debugging is on Spanning Tree optimized bpdu handling packet level debugging is on Spanning Tree SNMP support debugging is on Port Manager: Virtual port events debugging is on в syslog сыпет только нечто такое, причем достаточно много.. вот маленький кусочек: .... 8707: 8w1d: STP CFG: get port param unknown 0 GigabitEthernet4/16 7=3 rc=1 8708: 8w1d: STP CFG: found port cfg GigabitEthernet4/16 (45A52A48) 8709: 8w1d: STP CFG: found port cfg GigabitEthernet4/16 (45A52A48) 8710: 8w1d: STP CFG: get port param unknown 0 GigabitEthernet4/16 4=3 rc=1 8711: 8w1d: STP CFG: found port cfg GigabitEthernet4/16 (45A52A48) 8712: 8w1d: STP CFG: get port param unknown 0 GigabitEthernet4/16 3=3 rc=1 8713: 8w1d: STP CFG: found port cfg TenGigabitEthernet5/1 (462DEA20) 8714: 8w1d: STP CFG: get port param unknown 0 TenGigabitEthernet5/1 1=1 rc=0 8715: 8w1d: STP CFG: found port cfg TenGigabitEthernet5/1 (462DEA20) 8716: 8w1d: STP CFG: get port param unknown 0 TenGigabitEthernet5/1 1=1 rc=0 8717: 8w1d: STP CFG: found port cfg TenGigabitEthernet5/1 (462DEA20) 8718: 8w1d: STP CFG: get port param unknown 0 TenGigabitEthernet5/1 1=1 rc=0 8719: 8w1d: STP CFG: found port cfg TenGigabitEthernet5/1 (462DEA20) .... Edited July 27, 2011 by spruce Вставить ник Quote
John_obn Posted July 27, 2011 Posted July 27, 2011 Также на 65-м можете сделать mac-add notification mac-move , увидите в логах мак флаппинг между какими то портами, также поможет определить где петля. Вставить ник Quote
spruce Posted July 27, 2011 Author Posted July 27, 2011 (edited) Также на 65-м можете сделать mac-add notification mac-move , увидите в логах мак флаппинг между какими то портами, также поможет определить где петля. Сделал это, мак-флапп ничего не вываливает дельного, одна строчка только пробежала за все время, и то на тех портах, на которые проблемные вланы даже не идут... время разрыва и этой строчки мак-флаппа сильно различаются... Через некоторое время после разрыва в логи опять вывалилась куча подобного содержания: ... 9331: 8w1d: STP CFG: found port cfg GigabitEthernet4/4 (462D20D8) 9332: 8w1d: STP CFG: get port param unknown 0 GigabitEthernet4/4 9=1 rc=1 9333: 8w1d: STP CFG: found port cfg GigabitEthernet4/4 (462D20D8) 9334: 8w1d: STP CFG: get port param mst 0 GigabitEthernet4/4 10=1 rc=1 9335: 8w1d: STP CFG: found port cfg GigabitEthernet4/4 (462D20D8) ... Гугл на эту тему ничего дельного не дает.... :-( Edited July 27, 2011 by spruce Вставить ник Quote
spruce Posted July 27, 2011 Author Posted July 27, 2011 (edited) Вобщем у меня на R2 (см. картинку) проиходит смена топологии STP. Number of topology changes 1564 last change occurred 00:04:47 ago from TenGigabitEthernet5/2 Блокируется влан на всех портах, кроме Te5/2 на R2. на Te5/2 включен spanning-tree portfast Напомню, периодичность смены достаточно расплывчатая - может через 10 минут поменяться, может часов через 6-7... Стал сливать RSPAN`ом все что происходит в проблемном влане, но никакого криминала не нашел...потом также начал сливать native vlan (vlan1) - но там у меня ничего вобще не ходит, кроме пакетов stp через каждые 2 секунды. В момент смены топологии ничего не меняется, все STP пакеты одинаковые как под копирку... Подскажите, какие пакеты надо отлавливать? Очень уж непонятно стало... Edited July 27, 2011 by spruce Вставить ник Quote
s.lobanov Posted July 27, 2011 Posted July 27, 2011 У вас в сторону кастомеров похоже stp работает. Никаких portfast и прочей ерунды, на абонентских портах он должен быть жёстко выключен. Похоже, что у кого-то из абонентов L2-устройство с STP, которое перестраивает топологию Вставить ник Quote
spruce Posted July 27, 2011 Author Posted July 27, 2011 (edited) У вас в сторону кастомеров похоже stp работает. Никаких portfast и прочей ерунды, на абонентских портах он должен быть жёстко выключен. Похоже, что у кого-то из абонентов L2-устройство с STP, которое перестраивает топологию Нет, в сторону кастомеров portfast выключен, специально щас проверил. Portfast включен только на порт браса и на 10 гиговый порт. На другой стороне 10-гигового линка только еще один брас подключен и больше ничего... Может ли это из-за portfast`ов быть в этом случае? Кстати на порт кастомеров я включил spanning-tree bpduguard enable Edited July 27, 2011 by spruce Вставить ник Quote
mr.anatoly Posted July 28, 2011 Posted July 28, 2011 Кстати на порт кастомеров я включил spanning-tree bpduguard enable осмелюсь поинтересоваться, с какой целью это включено? покажите вывод команды #sh errdisable recovery | i bpduguard Вставить ник Quote
spruce Posted July 28, 2011 Author Posted July 28, 2011 Кстати на порт кастомеров я включил spanning-tree bpduguard enable осмелюсь поинтересоваться, с какой целью это включено? покажите вывод команды #sh errdisable recovery | i bpduguard Была попытка отловить чужие bdpu C6500#sh errdisable recovery | i bpduguard bpduguard Enabled Вставить ник Quote
mr.anatoly Posted July 29, 2011 Posted July 29, 2011 оно вам надо? при включенном bpduguard порт укладывается в err-disable, при входящем bpdu-helo bpduguard лучше отключите, а bpdufilter включите Вставить ник Quote
spruce Posted July 29, 2011 Author Posted July 29, 2011 оно вам надо? при включенном bpduguard порт укладывается в err-disable, при входящем bpdu-helo bpduguard лучше отключите, а bpdufilter включите На укладывание порт в даун и был расчет...это все временно было, уже отключено. Вставить ник Quote
spruce Posted July 30, 2011 Author Posted July 30, 2011 Вобщем и правда всему виной был spanning-tree portfast на Te5/2... хотя на этом линке он висел с самого начала, и никаких проблем небыло, а тут на тебе, такая замарочка... Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.