Jump to content
Калькуляторы

Разрывы PPPoE сессий по причине Lost-Carrier, из-за чего может быть?

Добрый день.

 

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

 

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

 

Спасибо.

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

ter mon

debug ppp exception

 

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

ppp keepalive check-interval seconds 10

Share this post


Link to post
Share on other sites

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

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


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

Share this post


Link to post
Share on other sites
Первым делом начали проверять флудящий трафик - 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 by spruce

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Вобщем у меня на R2 (см. картинку) проиходит смена топологии STP.

  Number of topology changes 1564 last change occurred 00:04:47 ago
         from TenGigabitEthernet5/2

stp_problem.jpg

 

Блокируется влан на всех портах, кроме Te5/2 на R2.

на Te5/2 включен spanning-tree portfast

 

Напомню, периодичность смены достаточно расплывчатая - может через 10 минут поменяться, может часов через 6-7...

 

Стал сливать RSPAN`ом все что происходит в проблемном влане, но никакого криминала не нашел...потом также начал сливать native vlan (vlan1) - но там у меня ничего вобще не ходит, кроме пакетов stp через каждые 2 секунды. В момент смены топологии ничего не меняется, все STP пакеты одинаковые как под копирку...

 

Подскажите, какие пакеты надо отлавливать? Очень уж непонятно стало...

Edited by spruce

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

 

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

Edited by spruce

Share this post


Link to post
Share on other sites

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

 

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

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

#sh errdisable recovery | i bpduguard

Share this post


Link to post
Share on other sites

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

 

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

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

#sh errdisable recovery | i bpduguard

 

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

 

C6500#sh errdisable recovery | i bpduguard
bpduguard            Enabled

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this