juniper EX loopguard/loopdetect/Loopback Detection

[ollsanek]

Приветствую!

На коммутаторах многих вендоров есть опция loopdetect или как-то так называющаяся. Смысл - определять петли там где xSTP включить не получится. (свич ставит свой MAC как DA во фреймы с ethertype 0х9000 и шлёт их на порт, если потом как-то получает, то есть петля).

 

есть ли что-то подобное на коммутаторах Juniper EX (EX2200, EX3200, EX4200) и как включить?

Спасибо.

Edited August 15, 2012 by ollsanek

[msdt]

Вроде бы нет: петли обнаруживаются только при включенном STP. Еще есть storm control - http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/rate-limiting-storm-control-configuring.html

[ollsanek]

Вроде бы нет: петли обнаруживаются только при включенном STP. Еще есть storm control - http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/rate-limiting-storm-control-configuring.html

не, STP не подходит, т.к. BPDU дальше первого свича не пройдёт, и петли могут быть в неконтроллируемом сегменте.

storm control тоже не подходит, т.к. есть мультикаст, и штормит как раз им.

 

я тоже не нашёл такой фичи, но как-то странно, думаю что должна быть, ибо на Zyxel/d-link/extreme есть, да и EX2200 позиционируется как access ...

[msdt]

Мультикаст-шторм, судя по описаниям, должен отлавливаться. http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/configuration-statement/no-multicast-edit-ethernet-switching-options.html

[Andrey Shepelev]

насколько я понимаю джунипер зовет это bpdu-block-on-edge

 

[edit]
protocols {
( mstp | rstp | vstp ) { 
bpdu-block-on-edge; 
interface interface-name; 
}
}

[nnm]

насколько я понимаю джунипер зовет это bpdu-block-on-edge

 

По моему это блокировка edge-портов, на которых внезапно приехал BPDU.

[fomka31ru]

может так

[triam]

Это вы не туда смотрите. Нужно не блокировать BPDU, а слать специальный BPDU и ждать его возвращения. Если вернулся, то это кольцо, если нет - всё нормуль.

Такой фишки у J - Нет, насколько я знаю.

[Denis Samsonov]

Это вы не туда смотрите. Нужно не блокировать BPDU, а слать специальный BPDU и ждать его возвращения. Если вернулся, то это кольцо, если нет - всё нормуль.

Такой фишки у J - Нет, насколько я знаю.

есть Storm-control

 

port-error-disable {

disable-timeout 600;

}

storm-control {

action-shutdown;

interface xe-0/0/23.0 {

bandwidth 50000;

no-unknown-unicast;

}

interface xe-0/0/24.0 {

bandwidth 500000;

}

[Andrey Shepelev]

сам джунипер говорит:

 

•	We do not have a command similar to loopback detection in Juniper Switch.
•	We can do loop protection by using below commands in Cisco and Juniper 
o	Juniper calls this 'bpdu-block-on-edge'
o	Cisco calls this 'bdpuguard'

 

так что нету

[ollsanek]

Это вы не туда смотрите. Нужно не блокировать BPDU, а слать специальный BPDU и ждать его возвращения. Если вернулся, то это кольцо, если нет - всё нормуль.

Такой фишки у J - Нет, насколько я знаю.

да именно это я имел в виду.

 

сам джунипер говорит:

•       We do not have a command similar to loopback detection in Juniper Switch.

...

так что нету

Спасибо за помощь, хотя сам ответ опечалил... Тему можно считать исчерпаной.

[Tima]

насколько я понимаю джунипер зовет это bpdu-block-on-edge

 

По моему это блокировка edge-портов, на которых внезапно приехал BPDU.

 

 

А это не то, что нужно достичь?

[ollsanek]

По моему это блокировка edge-портов, на которых внезапно приехал BPDU.

 

А это не то, что нужно достичь?

 

совсем-совсем нет.

самый простой вариант - есть сеть "А" и сеть "Б", есть линк между ними. Я администратор сети "А", если в сети "Б" случиться петля то в мою сеть "А" начинает наливаться совершенно ненужный трафик. bpdu-block-on-edge тут не поможет.

(сети - в смысле административно независимые L2 бродкаст домены ethernet)

(и да это самый простой вариант)

 

 

Кстати, из чистого любопытства, а у циски такое есть?

[nnm]

Кстати, из чистого любопытства, а у циски такое есть?

 

Коммутаторы Cisco посылают вот такое:

Ethernet II, Src: 00:0e:84:10:d2:8b (00:0e:84:10:d2:8b), Dst: 00:0e:84:10:d2:8b (00:0e:84:10:d2:8b)
   Destination: 00:0e:84:10:d2:8b (00:0e:84:10:d2:8b)
       Address: 00:0e:84:10:d2:8b (00:0e:84:10:d2:8b)
       .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
       .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
   Source: 00:0e:84:10:d2:8b (00:0e:84:10:d2:8b)
       Address: 00:0e:84:10:d2:8b (00:0e:84:10:d2:8b)
       .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
       .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
   Type: Loopback (0x9000)
Configuration Test Protocol (loopback)
   skipCount: 0
   Relevant function:
   Function: Reply (1)
   Receipt number: 0
Data (40 bytes)

 

Это поведение по умолчанию, кажется его можно выключить.

 

самый простой вариант - есть сеть "А" и сеть "Б", есть линк между ними. Я администратор сети "А", если в сети "Б" случиться петля то в мою сеть "А" начинает наливаться совершенно ненужный трафик. bpdu-block-on-edge тут не поможет.

(сети - в смысле административно независимые L2 бродкаст домены ethernet)

 

Я сомневаюсь этот механизм может спасти в описанном Вами случае. Представьте, что коммутатор сети 'А' шлет LOOP Reply в сеть 'Б'. Коммутатор сети 'Б' эти фреймы просто дропает (DMAC==SMAC и DMAC выучен на порту по которому принят фрейм). И сеть 'А' никогда не узнает, что в 'Б' наступила петля.

Не знаю, как это сделано у других вендоров, но думаю, что также.

Edited August 20, 2012 by nnm