[Wildy75]

Добрый день.

 

Гуру сетестроения, обращаюсь к вам! Подскажите, какие возможны подводные камни, если реализовать схему с LACP поверх двух волокон, если длина линков существенно различается (скажем, 20 и 80 км)?

Насколько я понимаю, если разные потоки не чувствительны к RTT настолько, то ничего нехорошего случиться не должно?

 

Я хочу сделать CWDM кольцо, а руководство так делать не хочет, хотят зачем-то резервироваться по L2 и ставить посередине активку, хотя ИМХО чем проще (и независимее от другого оборудования) - тем надежнее.

[Butch3r]

Всё будет ОК. Не те расстояния

[orlik]

ничего принципиально страшного не случится даже если будет 20 и 1000 км , балансировать будет по потокам , и все будет нормально

[Diamont]

У нас именно так работает LACP. Правда, расстояния от 2 до 10 км.

Edited November 24, 2014 by Diamont

[Wildy75]

Получается там 0.27 мс, если считать 80 км. В общем конечно, повлиять не должно никак. :)

[taf_321]

LACP пофиг на задержки. Он работает по другим принципам. Как выше писали, можно зацепить двумя линками в 2 и 1000 км, и все будет рабоатать нормально.

[pfexec]

LACP пофиг на задержки.

на задержки не пофиг транзитному трафику. если балансинг пер пакет, то может быть реордеринг на разных линках. благо в современном мире все свитчи и маршрутизаторы это делают пер флоу. :)

[orlik]

LACP пофиг на задержки.

на задержки не пофиг транзитному трафику. если балансинг пер пакет, то может быть реордеринг на разных линках. благо в современном мире все свитчи и маршрутизаторы это делают пер флоу. :)

Сейчас гораздо сложнее найти оборудование которое будет уметь пер пакет :)

[Stak]

LACP пофиг на задержки.

на задержки не пофиг транзитному трафику. если балансинг пер пакет, то может быть реордеринг на разных линках. благо в современном мире все свитчи и маршрутизаторы это делают пер флоу. :)

за балансинг пер-пакет надо бить по рукам лопатой :) Но вы таки удивитесь, но прецеденты были. С Мегафоном, с некоторых регионах.

[EDA_SPB]

А что не так с пер-пакет если нужно в один логический 2 физических линка объединить? Помню, очень давно так делали включения с Ростелекомом, собирая несколько е1. Проблем не помню, с балансировкой нет вопросов вообще.

Edited December 4, 2014 by EDA_SPB

[taf_321]

А что не так с пер-пакет если нужно в один логический 2 физических линка объединить? Помню, очень давно так делали включения с Ростелекомом, собирая несколько е1. Проблем не помню, с балансировкой нет вопросов вообще.

 

Сам тоже собирал несколько E1 в один логический интерфейс и тоже делалась per-packet. Но таки с каких это пор Ethernet стал синхронным соединением?

[EDA_SPB]

Сам тоже собирал несколько E1 в один логический интерфейс и тоже делалась per-packet. Но таки с каких это пор Ethernet стал синхронным соединением?

 

Намек понятен. Вопрос у меня не праздный, сейчас вот надо четыре гига принять от аплинка, десяток нет.

Я хотел пер-пакет замутить, не знал что есть нюансы (физически линки идентичные, лямбды в dwdm).

Могут быть проблемы?

[taf_321]

Лучше-таки делать per-flow. при per-packet на несинхронных каналах можно легко поймать переупорядовачивание пакетов в рамках одного соединения. Как следствие - заикания и артефакты в VoIP и UDP-видеопотоках, и всем знакомое замирание скачивания роликов с видеохостингов, и вообще при скачивании и серфигне будут вылазить затыки на ровном месте.

[White_Alex]

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

балансироваться на L3 по BGP в таком случае вполне вариант, мы с ТТК так жили долго достаточно, проблем не возникало, нагрузку оно хорошо распределяет. ну и кроме того, делать стык lacp с чужой сетью страшновато, не?

[sio]

... делать стык lacp с чужой сетью страшновато, не?

Делать агрегированный стык без lacp страшно, ибо легко получается 50% loss при одностороннем линке.