Comments 11
К нам приезжали представители Juniper и рекомендовали вовсе не кольцо, а Spine-and-Leaf архитектуру.
Не требуются линки внутри каждого слоя, т.к. сеть строится таким образом, что трафик ходит только снизу-вверх или сверху-вниз.
Не требуются линки внутри каждого слоя, т.к. сеть строится таким образом, что трафик ходит только снизу-вверх или сверху-вниз.
Чтобы свести к минимуму прерывания трафика во время сценария отказоустойчивости RE, нужно включить graceful Routing Engine switchover.
Так же для этого стоит включить
protocols layer2-control nonstop-bridging
routing-options nonstop-routing
Чтобы свести к минимуму прерывание коммутации и маршрутизации.
При включении этих опций backup-re синхронизирует протоколы stp и разные протоколы динамической маршрутизации, что позволяет ему работать в горячем резерве. Если их не включить, то backup-re с нуля запустит эти протоколы при падении master-re и можем получить прерывание трафика (перезапуск ospf, bgp, etc со всеми вытекающими)
Ещё стоит упомянуть, что line-card при потере связи с master-re все порты переводит в shutdown, чтобы предотвратить образование колец, т.к. все протоколы выполняются только на master-re.
Забыл упомянуть, что так же по рекомендации представителей Juniper всех членов фабрики советуют разделить в группы для NSSU:
Чтобы можно было обновить сначала чётных членов (2,4,6,...), затем нечётных (3,5,7,...) и только потом master (0) и backup (1)
chassis {
nssu {
upgrade-group group1 {
fpcs [ 2 4 6 8 10 ];
}
upgrade-group group2 {
fpcs [ 3 5 7 9 11 ];
}
upgrade-group group3 {
fpcs 1;
}
upgrade-group group4 {
fpcs 0;
}
}
}
Чтобы можно было обновить сначала чётных членов (2,4,6,...), затем нечётных (3,5,7,...) и только потом master (0) и backup (1)
На вашем рисунке показана технология Virtual Chassis Fabric, тут действительно Spine and leaf, про нее мы тоже напишем. Но Virtual Chassis Fabric поддерживают далеко не все коммутаторы Juniper и она требует лицензий. Самой просто технологией стекирования является Virtual Chassis.
В статье писалось про nonstop-bridging и nonstop-routing, это упоминалось в аббревиатурах NSR, GRES, NSB вполне очевидные вещи для устройств с резервирование RE. Относительно групп это тоже рекомендация для Virtual Chassis Fabric так как там количество коммутаторов гораздо больше чем в Virtual Chassis.
Но в остальном все супер, спасибо интерестный комментарий, про технологию Virtual Chassis Fabric мы тоже напишем.
В статье писалось про nonstop-bridging и nonstop-routing, это упоминалось в аббревиатурах NSR, GRES, NSB вполне очевидные вещи для устройств с резервирование RE. Относительно групп это тоже рекомендация для Virtual Chassis Fabric так как там количество коммутаторов гораздо больше чем в Virtual Chassis.
Но в остальном все супер, спасибо интерестный комментарий, про технологию Virtual Chassis Fabric мы тоже напишем.
Поясните, чем обусловлено рекомендованное расположение коммутаторов Master и Backup, когда они вместе размещены. Может быть есть ссылка на доку вендора, где это объясняется.
Поддерживается ли MC-LAG для Virtual Chassis?
Вопрос: а как рапределяется трафик между портами виртуального шасси, он работает в режиме active-active? Или в режиме active-backup?
Active-active. Там у них какой-то свой протокол со своей арифметикой распределения, как в LAG протоколах.
Тут active-backup только в плане Control Plane, на Data plane все порты активны и внутри VC работает алгоритм SPF т.е. трафик идет по кратчайшему пути внутри VC. Если вы имели ввиду каким обралом работают VCP когда мы соединяем двойным кольцом, то тут active-active. Хороший пример тут: http://www.juniper.net/techpubs/en_US/junos14.1/topics/example/virtual-chassis-ex4200-link-aggregation-over-extended-vcps.html
Sign up to leave a comment.
Преимущества стекирования Juniper