loopdetect принцип

[Adim]

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

loopdetect настроен

Interval         : 3 sec
 Recover Time     : 180 sec

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

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

[jffulcrum]

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

 

Цитата

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

 

[Adim]

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

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

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

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

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

[jffulcrum]

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

[Adim]

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

[Butch3r]

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

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

[Adim]

3 часа назад, Butch3r сказал:

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

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

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

[Butch3r]

4 минуты назад, Adim сказал:

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

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

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

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

[Adim]

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

[FIGO]

8 часов назад, jffulcrum сказал:

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

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

[YuryD]

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

[jffulcrum]

1 час назад, FIGO сказал:

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

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

[Adim]

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

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

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

[jffulcrum]

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

[nemo_lynx]

Мда...

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

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

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

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

[alibek]

8 минут назад, nemo_lynx сказал:

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

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

[nemo_lynx]

14 минут назад, alibek сказал:

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

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

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

Edited June 19, 2019 by nemo_lynx

[Saab95]

2 часа назад, alibek сказал:

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

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

[Butch3r]

7 часов назад, jffulcrum сказал:

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

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

[pppoetest]

4 часа назад, Butch3r сказал:

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

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

Цитата

 

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

Next possible completions:
port-based          vlan-based

DES-3200-26:5#

 

 

[Butch3r]

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

 

[alibek]

11 часов назад, Saab95 сказал:

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

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

[disappointed]

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

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

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

 

[StSphinx]

37 минут назад, disappointed сказал:

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

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

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

 

 

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

[Saab95]

5 часов назад, alibek сказал:

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

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