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

loopdetect принцип

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

loopdetect настроен

Interval         : 3 sec
 Recover Time     : 180 sec

сама сеть построена des 3200-26 дом----DGS-3420-26SC районный узел-----DGS-3120-24SC агрегация

вопрос как правильнее настроить loopdetect и если можно сам принцип, в интернетах читал ... не уловил суть

Share this post


Link to post
Share on other sites

http://dlink.ru/ru/faq/62/242.html

 

Цитата

Петля на порту обнаруживается путём отсылки коммутатором пакета с адресом назначения  CF-00-00-00-00-00 (9000 Ethernet Configuration Test protocol (Loopback)).

 

Share this post


Link to post
Share on other sites

это я читал....

Через указанное кол-во секунд (т.е. каждые 3 секунды) в сеть отправляется определенный пакет.

Если он возвращается - значит зафиксирована петля, и порт отключается на определенное время.

Если интервал отправки пакета большой - все это время в сети будет флуд.

т.е. выходит что на домовых надо ставить 3 секунды и уменьшать это время по мере приближения к агрегации так?

Share this post


Link to post
Share on other sites

Реально принято ставить 10 сек. Чаще смысла нет - слишком много срабатываний в духе "воткнул - осознал - сразу вынул"

Share this post


Link to post
Share on other sites

выходит на домовом на абонентских портах 10 на 240 к примеру, на узлах 6 на 180 на агрегации 3 на 120 так я понимаю?

Share this post


Link to post
Share on other sites

У нас включен per-vlan loopdetect на районных узлах, per-port на доступе. Порты на доступе выключаются навсегда (recover=0) + трап в мониторинг.

И то что у вас 3 секунды будет флуд - не смертельно, когда скорость порта где петля ниже, чем скорость аплинка.

Share this post


Link to post
Share on other sites
3 часа назад, Butch3r сказал:

Порты на доступе выключаются навсегда (recover=0) + трап в мониторинг

это по моему лишнее, лишний звонок от абонента в ТП, достаточно заблокировать порт минут на 5 я думаю

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

Share this post


Link to post
Share on other sites
4 минуты назад, Adim сказал:

это по моему лишнее, лишний звонок от абонента в ТП, достаточно заблокировать порт минут на 5 я думаю

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

как показывает практика абонентских колец очень мало. Как правило это сгоревший порт.

У нас стандартное значение - каждые 10 секунд.

Share this post


Link to post
Share on other sites

сгоревший порт это если он медный
у нас много абонентов подключенных оптикой т.е. sfp- абонентский медюк и иногда он имеет свойство петлю слать в сеть (или медюк или абонентский роутер) 

Share this post


Link to post
Share on other sites
8 часов назад, jffulcrum сказал:

Реально принято ставить 10 сек. Чаще смысла нет - слишком много срабатываний в духе "воткнул - осознал - сразу вынул"

1 секунда, рекавери 10 минут, будет время подумать чтобы не втыкать больше.

Share this post


Link to post
Share on other sites

 Лупбек на клиентских, выше на агрегации длинки например воспринимают это как левые bpdu, там и блочить все bpdu от клиентских маршрутизаторов.

Share this post


Link to post
Share on other sites
1 час назад, FIGO сказал:

1 секунда, рекавери 10 минут, будет время подумать чтобы не втыкать больше.

Ох уж этот максимализм... Мало того, что у свитча проц не бесконечный реагировать, так еще и трапы на мониторинг падают, а там БД тоже не бесконечная. 

Share this post


Link to post
Share on other sites

выходит на домовом на абонентских портах 10 на 240 к примеру, на узлах 6 на 180 на агрегации 3 на 120 так я понимаю?

верно или не так я понял?

т.е. чем ниже от агрегации тем больше время интервала так?

Share this post


Link to post
Share on other sites

LBD работает на уровне порта и ловит петли на себе же. Петлю МЕЖДУ портами он отловить ан масс неспособен (мы, как понимаю, про провайдинг говорим, с ынтырпрайсом возможен вариант per-vlan). Соответственно, его предел - доступ. На более высоких уровнях надо делать STP, и LBD там может только повредить.

Share this post


Link to post
Share on other sites

Мда...

ТС, Вы пожинаете плоды проблемы, которую сами себе создали. Правило очень простое:

1. на ВСЕХ абонентских портах должен быть включен LBD;

2. на ВСЕХ магистральных портах (как на свичах доступа, так и на свичах агрегации, и уж тем более в ядре) LBD должен отсутствовать.

Как поступать - дело Ваше. Но любое отклонение от указанного правила приводит к геморрою, который Вы и огребли.

Share this post


Link to post
Share on other sites
8 минут назад, nemo_lynx сказал:

Правило очень простое:

Я бы добавил ещё третье - зафильтровать на агрегации BPDU. По идее их не должно быть, но если по какой-то причине попадут, то будут локализованы сегментом сети.

Share this post


Link to post
Share on other sites
14 минут назад, alibek сказал:

Я бы добавил ещё третье - зафильтровать на агрегации BPDU. По идее их не должно быть, но если по какой-то причине попадут, то будут локализованы сегментом сети.

Я бы на уровне доступа в out в сторону агрегации вообще весь мульт со стороны абонентов-домоюзеров зафильтровал наглухо. На доступе от абонентов igmp перехватывается в MRV, dhcp перехватывается релеем. Так что в агрегацию кроме L3 + arp не должно лезть больше никакого L2.

Да и для юриков фильтрация не помешает, по крайней мере до тех пор, пока клиент не затребует странного.

Edited by nemo_lynx

Share this post


Link to post
Share on other sites
2 часа назад, alibek сказал:

Я бы добавил ещё третье - зафильтровать на агрегации BPDU.

Я бы добавил четвертое - нечего делать L2 трафику в центре - пакуйте его на промежуточных узлах в L3 и не забивайте голову всякими устаревшими технологиями.

Share this post


Link to post
Share on other sites
7 часов назад, jffulcrum сказал:

LBD работает на уровне порта и ловит петли на себе же. Петлю МЕЖДУ портами он отловить ан масс неспособен (мы, как понимаю, про провайдинг говорим, с ынтырпрайсом возможен вариант per-vlan). Соответственно, его предел - доступ. На более высоких уровнях надо делать STP, и LBD там может только повредить.

современные длинки ловят как раз между портами

Share this post


Link to post
Share on other sites
4 часа назад, Butch3r сказал:

современные длинки ловят как раз между портами

Это конфигурится
 

Цитата

 

DES-3200-26:5#config loopdetect mode
Command: config loopdetect mode

Next possible completions:
port-based          vlan-based

DES-3200-26:5#

 

 

Share this post


Link to post
Share on other sites
2 часа назад, pppoetest сказал:

Это конфигурится
 

 

вот так:

 

enable loopdetect
config loopdetect log state enable
config loopdetect ports 1-24 state enable
config loopdetect trap both
config loopdetect mode port-based
config loopdetect recover_timer 0

 

Share this post


Link to post
Share on other sites
11 часов назад, Saab95 сказал:

Я бы добавил четвертое - нечего делать L2 трафику в центре - пакуйте его на промежуточных узлах в L3 и не забивайте голову всякими устаревшими технологиями.

Если использовать нормальное оборудование (то есть не микротики), то посторонний L2-трафик в ядре и не появится.

Share this post


Link to post
Share on other sites

Я тоже за LBD только на доступе, рекавери - часы, либо навсегда, желателен трап.

У меня нет трапов по этому событию, но есть грозовой скрипт, которым можно после молний пробежаться

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

 

Share this post


Link to post
Share on other sites
37 минут назад, disappointed сказал:

Я тоже за LBD только на доступе, рекавери - часы, либо навсегда, желателен трап.

У меня нет трапов по этому событию, но есть грозовой скрипт, которым можно после молний пробежаться

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

 

 

А по каким критериям вы определяете, что порт битый?

Share this post


Link to post
Share on other sites
5 часов назад, alibek сказал:

Если использовать нормальное оборудование (то есть не микротики), то посторонний L2-трафик в ядре и не появится.

Тут недавно у одного крупного провайдера был перерыв сервиса, связанный с закольцовкой на магистральной сети. Интересно как такое могло произойти? Оборудование там же не дешевое используется =)

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