[baf]

Есть задача:

Через два L2 канала от двух разных провайдеров

организовать один канал с резервированием для передачи видеопотока multicast.

 

Примерно такой вариант

 

Имеем 2шт WS-C3750E-24TD-S в стеке в датацентре г.Москва.

И Cisco 4948-10GE в Нижнем Новгороде.

Есть оборудование Mikrotik на обоих концах если это поможет)

 

У провайдеров порты с обоих концов канала в access, думаю можно попросить настроить по другому.

 

Подскажите пожалуйста как организовать канал на подобие EtherChannel?

Можно ли использовать STP?

Или может есть другие варианты резервирования?

 

Заранее благодарю за любые предложения!

[NiTr0]

Через два L2 канала от двух разных провайдеров

организовать один канал с резервированием для передачи видеопотока multicast.

Подскажите пожалуйста как организовать канал на подобие EtherChannel?

балансировка для мультикаста по каналам разной длины с разным пингом - плохая идея ИМХО...

 

Можно ли использовать STP?

если аплинк не режет - ИМХО вполне ок.

 

Есть оборудование Mikrotik на обоих концах если это поможет)

микротик с мультикастом несовместимы.

[Butch3r]

STP это нифига не эзерченел, тут работает либо А, либо Б.

[zhenya`]

Pim обычная маршрутизация

[s.lobanov]

STP это нифига не эзерченел, тут работает либо А, либо Б.

 

Ну вообще-то в "эзерченеле" (будем считать что тут все на ты с cisco и понимают что речь идет про LAG) есть режим active-standby, есть всякие M+N (M активных, N стендбайных). На cisco M+N конфигурится так - загонятете M портов в port-channel и в настройках Po задаете max-links

[s.lobanov]

Через два L2 канала от двух разных провайдеров

организовать один канал с резервированием для передачи видеопотока multicast.

Подскажите пожалуйста как организовать канал на подобие EtherChannel?

балансировка для мультикаста по каналам разной длины с разным пингом - плохая идея ИМХО...

 

Наркоман чтоле? Щас все современные L2/L3 свитчи балансируют по L2/L3-хедеру, что по умнее по L4. Т.е. собрав port-channel на каналах с разными пингами по ним можно смело балансировать мультикаст трафик (да и практически любой другой), потому что один flow (одна мультикаст группа) всегда будет уходить строго по одному каналу.

 

Можно ли использовать STP?

если аплинк не режет - ИМХО вполне ок.

Не, ну точно наркоман. Делать опаснейшую схему с stp через арендованные L2 - видимо нравится адреналин и жить в непрерывном устранении аварий. Вот начнет один провайдер в день X дропать ваши BPDU-шки и всё, припыли.

 

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

 

Выше предложили правильные варианты:

1. PIM

2. LAG. Он работает и без BPDU-шек, но это плохо ибо не будет контроля того, что канал работает и будет лишь link-state на границах. За то с использованием LACP если вдруг один оператор их подропает, то у вас трафик не будет ходить через этого канал и всё уйдет на второй порт, а не случится петля как с STP

[baf]

Вах! Спасибо!!!

 

Получается, что PIM самый кошерный вариант?

Нашел вот такое решение:

Using MBGP and MSDP

Можно ли обойтись одним свичем на входе с 2мя IP вместо R2 и R3?

И будет ли эта схема работать на свичах 3 уровня WS-C3750?

Изменено 16 января, 2017 пользователем baf

[zhenya`]

можно и без мсдп и без бгп. тупо дотягиваете оспф или чо там у вас в качестве игп. прописываете рп и включаете на интерфейсах ip pim sparse-mode.

ну еще включаете multicast routing)

[h1vs2]

Как уже ответили, PIM - лучший из вариантов.

 

Как вариант, если нужно л2 - можно сделать LAG(даже без lacp) + micro bfd, если железо умеет.

[basterik]

Был опыт аналогичной ситуации Москва-точка удаленная ~600км, вообщем обычный port-channel работает на ура.

Для быстрой реакции добавили LACP с укороченными таймерами, но это не у всех есть.

Изменено 16 января, 2017 пользователем basterik

[h1vs2]

Был опыт аналогичной ситуации Москва-точка удаленная ~600км, вообщем обычный port-channel работает на ура.

 

C microbfd будет еще и fail detection.

[baf]

Спасибо! заработало)

Вот что получилось может пригодится кому...

PIM резервирование через 2х провайдеров

 

Примерная схема (рисовать лень)

Картинка от сюда

 

Интерфейс источника 10.52.4.2

Интерфейс получателя 10.77.4.3

 

Свич на стороне источника

ip routing
ip multicast-routing distributed
!
interface GigabitEthernet2/0/1
no switchport
ip address 10.77.3.2 255.255.255.0
ip pim sparse-dense-mode
ip ospf cost 1
ip ospf dead-interval 10
!
interface GigabitEthernet2/0/2
no switchport
ip address 10.77.5.2 255.255.255.0
ip pim sparse-dense-mode
ip ospf cost 10
ip ospf dead-interval 10
!
interface GigabitEthernet2/0/5
no switchport
ip address 10.52.4.2 255.255.255.0
ip pim sparse-dense-mode
!
router ospf 1
router-id 52.52.52.52
network 10.52.4.0 0.0.0.255 area 77
network 10.77.3.0 0.0.0.255 area 77
network 10.77.5.0 0.0.0.255 area 77
!
ip pim rp-address 10.52.4.10 IPTV override
!
ip access-list standard IPTV
permit 239.0.0.0 0.255.255.255

 

Свич в датацентре куда нужно передать сигнал

 

ip routing
ip multicast-routing distributed
!
interface GigabitEthernet1/0/1
no switchport
ip address 10.77.3.3 255.255.255.0
ip pim sparse-dense-mode
ip ospf cost 1
ip ospf dead-interval 10
!
interface GigabitEthernet1/0/2
no switchport
ip address 10.77.5.3 255.255.255.0
ip pim sparse-dense-mode
ip ospf cost 10
ip ospf dead-interval 10
!
interface GigabitEthernet1/0/5
no switchport
ip address 10.77.4.3 255.255.255.0
ip pim sparse-dense-mode
!
router ospf 1
router-id 77.77.77.77
network 10.77.3.0 0.0.0.255 area 77
network 10.77.4.0 0.0.0.255 area 77
network 10.77.5.0 0.0.0.255 area 77
!
ip pim rp-address 10.52.4.10 IPTV override
!
ip access-list standard IPTV
permit 239.0.0.0 0.255.255.255

Изменено 18 января, 2017 пользователем baf

[zhenya`]

ip pim sparse-dense-mode -> ip pim sparse-mode

[NiTr0]

Щас все современные L2/L3 свитчи балансируют по L2/L3-хедеру, что по умнее по L4.

балансируют по destination. и потому мультикаст те же длинки не балансируют вообще, тупо валится в мастер порт.

 

Делать опаснейшую схему с stp через арендованные L2 - видимо нравится адреналин и жить в непрерывном устранении аварий. Вот начнет один провайдер в день X дропать ваши BPDU-шки и всё, припыли.

traffic segmentation...

 

Выше предложили правильные варианты:

1. PIM

ну если оборудование л3 - то почему бы и нет.

 

За то с использованием LACP если вдруг один оператор их подропает, то у вас трафик не будет ходить через этого канал и всё уйдет на второй порт, а не случится петля как с STP

от реализации зависит... у меня к примеру при попытке увязать длинк 3120 с LACP с длинком 3200 на котором оказался настроен статик LAG (давно, и оно работало с длинком 3100 нормально) случилось колечко...

[Butch3r]

Да у меня что-то вообще ниразу не получилось собрать LACP через промежуточные свичи, LACP просто не собирался. Но может я что-то не так делал...

[zhenya`]

Там специальные команды должны быть на тему l2 protocol tunnel

 

http://packetlife.net/blog/2008/jul/02/layer-two-protocol-tunneling/

[baf]

ip pim sparse-dense-mode -> ip pim sparse-mode

 

Спасибо! почитал ip pim sparse-mode правильнее в данном случае)

[s.lobanov]

хорошо, что уберегли ТС-а от всяких пионернет-стайл решений в виде stp!

[baf]

Обнаружил интересную особенность OSPF при работе в стеке

 

В данной конфигурации нужно убрать

ip ospf dead-interval 10

с интерфейсов

иначе каждые 10 сек свичи начинают искать путь заново

в цикле трафик идет то по одному каналу то по другому

а если разорвать одну из цепочек (обрыв провайдера)

то происходит просто потеря пакетов примерно каждые 10 сек

[v_r]

ip multicast multipath на свитче-приемнике не включали? На 4948 должен поддерживаться, позволит разбалансировать мультикаст по двум каналам.

ip ospf dead-interval 10

Dead interval по умолчанию настроен как 4x hello interval чтобы соседство не разваливалось при потере 2 hello пакетов.

Какой у вас был OSPF hello interval на интерфейсах при dead-interval 10?

[Saab95]

Есть оборудование Mikrotik на обоих концах если это поможет)

микротик с мультикастом несовместимы.

 

Как раз совместим - туннель EoIP между IP роутеров, которые подключены к двум каналам, по каналам 2 сетки /30 с OSPF, поверх них уже и будет передаваться мультикаст. Схема вполне рабочая и часто применяемая. При этом можно даже настроить удвоение пропускной способности, отправляя пакеты вразнобой по каналам.

[zhenya`]

Дада. Вразнобой положительно скажется на мультике, спасибо поржал

[myth]

удвоение пропускной способности, отправляя пакеты вразнобой по каналам.

ржу))

[pppoetest]

Щас все современные L2/L3 свитчи балансируют по L2/L3-хедеру, что по умнее по L4.

балансируют по destination. и потому мультикаст те же длинки не балансируют вообще, тупо валится в мастер порт.

Не согласен, длинк 3620 нормально разливает мультикаст на все порты в lacp

[baf]

ip multicast multipath на свитче-приемнике не включали?

нет не пробовал, на приемнике свичи С3750E

 

Какой у вас был OSPF hello interval на интерфейсах при dead-interval 10?

Был по умолчанию (то есть не задан в конфигурации)