spruce Опубликовано 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, может что-то проясниться... Подскажите, как еще можно отследить, почему возникают такого рода разрывы? Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 26 июля, 2011 · Жалоба Он установлен в одной стойке с Cisco C6500 и включен в него же. плата в которую включен? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
macharius Опубликовано 26 июля, 2011 · Жалоба 1. какой софт у вас стоит на se100? 2. сколько абонентов сейчас на коробке? попробуйте дать в контексте где абоненты подключены: ter mon debug ppp exception И еще включите keepalive на ppp, например так ppp keepalive check-interval seconds 10 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 26 июля, 2011 · Жалоба Брас, помимо аккаунтинга ещё о чём-либо сообщает? Может в логи срёт чем-нибудь? Нагрузка пиковая или в пределах нормы? Внимательно читайте то, что пишут вам свичи агрегации и доступа. Кстати, доступ к вас как настроен? (максимально подробно) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 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 - собирается Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 26 июля, 2011 · Жалоба Брас, помимо аккаунтинга ещё о чём-либо сообщает? Может в логи срёт чем-нибудь? Нагрузка пиковая или в пределах нормы? Внимательно читайте то, что пишут вам свичи агрегации и доступа. Кстати, доступ к вас как настроен? (максимально подробно) Сейчас логи собираю, посмотрю что вывалит в момент разрыва. Разрывы происходят в разное время суток, и в пиковые моменты (когда трафик на всех интерфейсах по ~700-800Mbps и unicast ~100kpps), и в ночные часы, когда трафик мимнимален... цпу - 2%. Свитчи агрегации и доступа на эту тему ничего не пишут, на доступе включен только лупдетект, на агрегации вобще ничего не включено, только прогоняются вланы от каталиста до свитчей доступа.. Проблема наблюдается на любых ос, *nix, windows без разницы... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XeonVs Опубликовано 26 июля, 2011 · Жалоба Такая ерунда бывает, если абонент словил вирусню которая повреждает IP-стек и pppoe-клиент банально не отправляет PADT при разрыве сессии. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 26 июля, 2011 · Жалоба Такая ерунда бывает, если абонент словил вирусню которая повреждает IP-стек и pppoe-клиент банально не отправляет PADT при разрыве сессии. Была такая мысль, что это вирусняк, но разрыв у разных сессий в одно время. А также, как уже писал, сам сейчас подключен на машине с линуксом... Вчера весь день был подключен по PPPoE в другом влане, разрывов не было. Сейчас подключен в влане с разрывами, и разрывы есть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 26 июля, 2011 · Жалоба Такая ерунда бывает, если абонент словил вирусню которая повреждает IP-стек и pppoe-клиент банально не отправляет PADT при разрыве сессии. Была такая мысль, что это вирусняк, но разрыв у разных сессий в одно время. А также, как уже писал, сам сейчас подключен на машине с линуксом... Вчера весь день был подключен по PPPoE в другом влане, разрывов не было. Сейчас подключен в влане с разрывами, и разрывы есть. ;))) У Вас петля в VLAN появляется просто. Уменьшите время перепосыла контрольных пакетов на свитчах доступа скажем до 3 секунд и время блокировки по петле до макс. и смотрите, кто уйдет в LBD. Сделайте тоже самое на транзитных портах, жалко потерять пару свитчей, но петли ловить надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 26 июля, 2011 · Жалоба Наврал, пинг до локального шлюза тоже пропадает, наверно и правда петля где-то закралась... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 26 июля, 2011 · Жалоба Получается интересная ситуация, на циске spanning-tree блочит часть вланов с pppoe на всех портах за исключением одного, потом сразу же их поднимает. За время BLK-FWD сессия и рвется... Почему происходит эта блокировка на всех портах кроме одного, и почему сразу на пачке вланах, которые идут вообще в разные стороны на циске? PS: какие то странные интервалы срабатывания - то 10 минут, то несколько часов без проблем... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 27 июля, 2011 (изменено) · Жалоба Первым делом начали проверять флудящий трафик - 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) .... Изменено 27 июля, 2011 пользователем spruce Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
John_obn Опубликовано 27 июля, 2011 · Жалоба Также на 65-м можете сделать mac-add notification mac-move , увидите в логах мак флаппинг между какими то портами, также поможет определить где петля. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 27 июля, 2011 (изменено) · Жалоба Также на 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) ... Гугл на эту тему ничего дельного не дает.... :-( Изменено 27 июля, 2011 пользователем spruce Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 27 июля, 2011 (изменено) · Жалоба Вобщем у меня на 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 пакеты одинаковые как под копирку... Подскажите, какие пакеты надо отлавливать? Очень уж непонятно стало... Изменено 27 июля, 2011 пользователем spruce Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 27 июля, 2011 · Жалоба У вас в сторону кастомеров похоже stp работает. Никаких portfast и прочей ерунды, на абонентских портах он должен быть жёстко выключен. Похоже, что у кого-то из абонентов L2-устройство с STP, которое перестраивает топологию Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 27 июля, 2011 (изменено) · Жалоба У вас в сторону кастомеров похоже stp работает. Никаких portfast и прочей ерунды, на абонентских портах он должен быть жёстко выключен. Похоже, что у кого-то из абонентов L2-устройство с STP, которое перестраивает топологию Нет, в сторону кастомеров portfast выключен, специально щас проверил. Portfast включен только на порт браса и на 10 гиговый порт. На другой стороне 10-гигового линка только еще один брас подключен и больше ничего... Может ли это из-за portfast`ов быть в этом случае? Кстати на порт кастомеров я включил spanning-tree bpduguard enable Изменено 27 июля, 2011 пользователем spruce Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mr.anatoly Опубликовано 28 июля, 2011 · Жалоба Кстати на порт кастомеров я включил spanning-tree bpduguard enable осмелюсь поинтересоваться, с какой целью это включено? покажите вывод команды #sh errdisable recovery | i bpduguard Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 28 июля, 2011 · Жалоба Кстати на порт кастомеров я включил spanning-tree bpduguard enable осмелюсь поинтересоваться, с какой целью это включено? покажите вывод команды #sh errdisable recovery | i bpduguard Была попытка отловить чужие bdpu C6500#sh errdisable recovery | i bpduguard bpduguard Enabled Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mr.anatoly Опубликовано 29 июля, 2011 · Жалоба оно вам надо? при включенном bpduguard порт укладывается в err-disable, при входящем bpdu-helo bpduguard лучше отключите, а bpdufilter включите Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 29 июля, 2011 · Жалоба оно вам надо? при включенном bpduguard порт укладывается в err-disable, при входящем bpdu-helo bpduguard лучше отключите, а bpdufilter включите На укладывание порт в даун и был расчет...это все временно было, уже отключено. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 30 июля, 2011 · Жалоба Вобщем и правда всему виной был spanning-tree portfast на Te5/2... хотя на этом линке он висел с самого начала, и никаких проблем небыло, а тут на тебе, такая замарочка... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...