[spruce]

Добрый день.

 

Наблюдаем разрывы 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, может что-то проясниться...

 

Подскажите, как еще можно отследить, почему возникают такого рода разрывы?

 

Спасибо.

[ingress]

Он установлен в одной стойке с Cisco C6500 и включен в него же.

 

плата в которую включен?

[macharius]

1. какой софт у вас стоит на se100?

2. сколько абонентов сейчас на коробке? попробуйте дать в контексте где абоненты подключены:

ter mon

debug ppp exception

 

И еще включите keepalive на ppp, например так

ppp keepalive check-interval seconds 10

[terrible]

Брас, помимо аккаунтинга ещё о чём-либо сообщает? Может в логи срёт чем-нибудь? Нагрузка пиковая или в пределах нормы?

 

Внимательно читайте то, что пишут вам свичи агрегации и доступа.

Кстати, доступ к вас как настроен? (максимально подробно)

[spruce]

Он установлен в одной стойке с 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 - собирается

[spruce]

Брас, помимо аккаунтинга ещё о чём-либо сообщает? Может в логи срёт чем-нибудь? Нагрузка пиковая или в пределах нормы?

 

Внимательно читайте то, что пишут вам свичи агрегации и доступа.

Кстати, доступ к вас как настроен? (максимально подробно)

 

Сейчас логи собираю, посмотрю что вывалит в момент разрыва.

Разрывы происходят в разное время суток, и в пиковые моменты (когда трафик на всех интерфейсах по ~700-800Mbps и unicast ~100kpps), и в ночные часы, когда трафик мимнимален... цпу - 2%.

 

Свитчи агрегации и доступа на эту тему ничего не пишут, на доступе включен только лупдетект, на агрегации вобще ничего не включено, только прогоняются вланы от каталиста до свитчей доступа..

 

Проблема наблюдается на любых ос, *nix, windows без разницы...

[XeonVs]

Такая ерунда бывает, если абонент словил вирусню которая повреждает IP-стек и pppoe-клиент банально не отправляет PADT при разрыве сессии.

[spruce]

Такая ерунда бывает, если абонент словил вирусню которая повреждает IP-стек и pppoe-клиент банально не отправляет PADT при разрыве сессии.

Была такая мысль, что это вирусняк, но разрыв у разных сессий в одно время. А также, как уже писал, сам сейчас подключен на машине с линуксом...

Вчера весь день был подключен по PPPoE в другом влане, разрывов не было. Сейчас подключен в влане с разрывами, и разрывы есть.

[tartila]

Такая ерунда бывает, если абонент словил вирусню которая повреждает IP-стек и pppoe-клиент банально не отправляет PADT при разрыве сессии.

Была такая мысль, что это вирусняк, но разрыв у разных сессий в одно время. А также, как уже писал, сам сейчас подключен на машине с линуксом...

Вчера весь день был подключен по PPPoE в другом влане, разрывов не было. Сейчас подключен в влане с разрывами, и разрывы есть.

 

;))) У Вас петля в VLAN появляется просто. Уменьшите время перепосыла контрольных пакетов на свитчах доступа скажем до 3 секунд и время блокировки по петле до макс. и смотрите, кто уйдет в LBD. Сделайте тоже самое на транзитных портах, жалко потерять пару свитчей, но петли ловить надо.

[spruce]

Наврал, пинг до локального шлюза тоже пропадает, наверно и правда петля где-то закралась...

[spruce]

Получается интересная ситуация, на циске spanning-tree блочит часть вланов с pppoe на всех портах за исключением одного, потом сразу же их поднимает. За время BLK-FWD сессия и рвется...

Почему происходит эта блокировка на всех портах кроме одного, и почему сразу на пачке вланах, которые идут вообще в разные стороны на циске?

 

PS: какие то странные интервалы срабатывания - то 10 минут, то несколько часов без проблем...

[Negator]

Первым делом начали проверять флудящий трафик - 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

[spruce]

Первым делом начали проверять флудящий трафик - 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

[John_obn]

Также на 65-м можете сделать mac-add notification mac-move , увидите в логах мак флаппинг между какими то портами, также поможет определить где петля.

[spruce]

Также на 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

[spruce]

Вобщем у меня на 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

[s.lobanov]

У вас в сторону кастомеров похоже stp работает. Никаких portfast и прочей ерунды, на абонентских портах он должен быть жёстко выключен. Похоже, что у кого-то из абонентов L2-устройство с STP, которое перестраивает топологию

[spruce]

У вас в сторону кастомеров похоже stp работает. Никаких portfast и прочей ерунды, на абонентских портах он должен быть жёстко выключен. Похоже, что у кого-то из абонентов L2-устройство с STP, которое перестраивает топологию

 

Нет, в сторону кастомеров portfast выключен, специально щас проверил.

Portfast включен только на порт браса и на 10 гиговый порт. На другой стороне 10-гигового линка только еще один брас подключен и больше ничего...

 

Может ли это из-за portfast`ов быть в этом случае?

 

Кстати на порт кастомеров я включил spanning-tree bpduguard enable

Изменено 27 июля, 2011 пользователем spruce

[mr.anatoly]

Кстати на порт кастомеров я включил spanning-tree bpduguard enable

 

осмелюсь поинтересоваться, с какой целью это включено?

покажите вывод команды

#sh errdisable recovery | i bpduguard

[spruce]

Кстати на порт кастомеров я включил spanning-tree bpduguard enable

 

осмелюсь поинтересоваться, с какой целью это включено?

покажите вывод команды

#sh errdisable recovery | i bpduguard

 

Была попытка отловить чужие bdpu

 

C6500#sh errdisable recovery | i bpduguard
bpduguard            Enabled

[mr.anatoly]

оно вам надо? при включенном bpduguard порт укладывается в err-disable, при входящем bpdu-helo

bpduguard лучше отключите, а bpdufilter включите

[spruce]

оно вам надо? при включенном bpduguard порт укладывается в err-disable, при входящем bpdu-helo

bpduguard лучше отключите, а bpdufilter включите

На укладывание порт в даун и был расчет...это все временно было, уже отключено.

[spruce]

Вобщем и правда всему виной был spanning-tree portfast на Te5/2... хотя на этом линке он висел с самого начала, и никаких проблем небыло, а тут на тебе, такая замарочка...