Балансировка нагрузки на каналы в 21 веке

[sol]

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

 

 

Есть точка А и точка Б. Между ними есть прямой канал А-Б пропускной способностью 500 попугаев.

Есть точка В, имеющая каналы к точкам А и Б. Канал B-А в 300 попугаев и канал B-Б в 200 попугаев.

 

Что появилось новенького чтобы между точками А и Б получить не 500 попугаев, а 700? Характер трафика - IP, "интернет"?

 

Все точки находятся под одним административным контролем.

На момент фантазирования можем воображать любое железо.

 

[zavndw]

А второй канал? балансировка требует больше чем 1 канал

[sol]

1 минуту назад, zavndw сказал:

А второй канал?

Поверьте, он есть.

[zavndw]

С таким результатом, трафик между А и Б надо гнать вкруг через B

A <500> Б
B <unlim> А
B <unlim> Б

С <300> А
С <200> Б

 

Конечно боль может составить если это 1 какой то L2 канал и тогда кроме бодинга сильно вариантов можно и не быть

[sol]

Прошу пардону, заигрался в буквы.

Конечно же точек всего три.

А <500> Б

А <300> В

Б <200> В

[AN111]

1. неравновесная балансировка
 - EIGRP
 - BGP c link bandwith

2. ECMP для любого протокола: нарезать каналы на 5*100 + 2*100

Все это будет относительно равномерно раскладываться только для множество пар src_dst IP.

[sol]

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

 - EIGRP

Не понимаю чем это поможет. Да, EIGRP умеет учитывать, хоть и криво, загруженность линка. Но всё равно, два канала одновременно работать не будут. Протокол вычислит лучший маршрут и будет работать менее загруженный.

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

BGP c link bandwith

Аналогично предыдущему. После всех вычислений протокол вычислит ОДИН наилучший маршрут, который и попадёт в FIB.

 

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

ECMP для любого протокола: нарезать каналы на 5*100 + 2*100

Н.я.п. первая буква Е в слове ECMP означает equal. А у меня маршруты ни разу не equal. Они вери дифферент.

Я верно понимаю, что вы предлагаете нарезать через транспорт 7 "труб" "по сто" хоть MPLS, хоть  VLAN + полисер, сделав таким образом каналы equal?

Интересное предложение, но в этом случае один отдельный поток будет ограничен пропускной способностью в 100 попугаев. Даже если каналы свободны, один отдельный юзер не разгонится быстрее 100 попугаев.

 

[Умник]

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

отдельный поток будет ограничен пропускной способностью в 100 попугаев

Если сделать просто 7 (5+2) VLAN, без полисера (зачем он?), чтобы было 7 nexthops, то отдельный поток будет ограничен скоростью от 200 до 500 Мбит. Как повезет.

[Умник]

Да, ведь ECMP может быть per-packet. Если reordering не пугает, то почему бы и нет?

[sol]

1 час назад, Умник сказал:

Если сделать просто 7 (5+2) VLAN, без полисера (зачем он?), чтобы было 7 nexthops, то отдельный поток будет ограничен скоростью от 200 до 500 Мбит. Как повезет.

Вообще, логично.

1 час назад, Умник сказал:

Да, ведь ECMP может быть per-packet. Если reordering не пугает, то почему бы и нет?

А вот этого не хотелось бы. Хотелось бы per-flow.

[jffulcrum]

Не совсем по теме, но в нашей маленькой секте свидетелей св.Микротика варианты для разноскоростных каналов  есть: https://help.mikrotik.com/docs/display/ROS/Bonding . 

[fractal]

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

Вообще, логично.

А вот этого не хотелось бы. Хотелось бы per-flow.

Ну тут в помощь sdwan, тот же касперский 

 

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

Вообще, логично.

А вот этого не хотелось бы. Хотелось бы per-flow.

либо искать железо которое умеет per flow

[Saab95]

Создать на 500 канале 5 вланов, на 300 канале 3 влана и на 200 канале 2 влана. Повесить на каждый свою уникальную подсеть и включить OSPF.

 

Трафик сам отбалансируется, если клиенты будут иметь разные IP адреса и делать запросы на разные адреса интернета.

[DeLL]

Вот это бред :D

[MrNv]

22 часа назад, sol сказал:

Не понимаю чем это поможет. Да, EIGRP умеет учитывать, хоть и криво, загруженность линка. Но всё равно, два канала одновременно работать не будут. Протокол вычислит лучший маршрут и будет работать менее загруженный.

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

так же через offset-list можно очень тонко поправить метрику у нужного префикса, т.е. грубо говоря весь ваш трафик будет идти через линк А-Б а отельный префикс 10.1.1.0/30 будет через А-В-Б

#sh ip ro 10.2.0.253
Routing entry for 10.2.0.253/32
  Known via "eigrp 4", distance 170, metric 6144, precedence routine (0), type external
  Redistributing via eigrp 4
  Last update from 10.2.2.121 on HundredGigE1/0/49, 15:29:57 ago
  Routing Descriptor Blocks:
  * 10.2.2.121, from 10.2.2.121, 15:29:57 ago, via HundredGigE1/0/49
      Route metric is 6144, traffic share count is 1
      Total delay is 230 microseconds, minimum bandwidth is 10000000 Kbit
      Reliability 50/255, minimum MTU 1500 bytes
      Loading 77/255, Hops 3
    10.2.1.185, from 10.2.1.185, 15:29:57 ago, via HundredGigE1/0/50
      Route metric is 6144, traffic share count is 1
      Total delay is 230 microseconds, minimum bandwidth is 10000000 Kbit
      Reliability 50/255, minimum MTU 1500 bytes
      Loading 77/255, Hops 3

 

или вот не равномерная балансировка

#sh ip ro 10.1.1.14
Routing entry for 10.1.1.14/32
  Known via "eigrp 4", distance 170, metric 154112, precedence routine (0), type external
  Redistributing via eigrp 4
  Last update from 10.2.2.198 on Port-channel3, 19:28:53 ago
  Routing Descriptor Blocks:
  * 10.2.2.198, from 10.2.2.198, 19:28:53 ago, via Port-channel3
      Route metric is 162304, traffic share count is 114
      Total delay is 6330 microseconds, minimum bandwidth is 8000000 Kbit
      Reliability 255/255, minimum MTU 1514 bytes
      Loading 7/255, Hops 2
    10.2.2.122, from 10.2.2.122, 19:28:53 ago, via HundredGigE1/0/49
      Route metric is 154112, traffic share count is 120
      Total delay is 6010 microseconds, minimum bandwidth is 8000000 Kbit
      Reliability 255/255, minimum MTU 1514 bytes
      Loading 44/255, Hops 2
    10.2.2.17, from 10.2.2.17, 19:28:53 ago, via TwentyFiveGigE1/0/21
      Route metric is 179456, traffic share count is 103
      Total delay is 7000 microseconds, minimum bandwidth is 8000000 Kbit
      Reliability 255/255, minimum MTU 1514 bytes
      Loading 70/255, Hops 2
    10.2.1.186, from 10.2.1.186, 19:28:53 ago, via HundredGigE1/0/50
      Route metric is 154112, traffic share count is 120
      Total delay is 6010 microseconds, minimum bandwidth is 8000000 Kbit
      Reliability 255/255, minimum MTU 1514 bytes
      Loading 44/255, Hops 2

 

Edited October 10, 2023 by MrNv

[AN111]

Еще раз для sol:
1. неравновесная балансировка
 - EIGRP (поддерживается с рождения протокола)
 - BGP c link bandwith

Здесь - именно неравновесная балансировка.

 В примере выше от MrNv для EIGRP коэффициенты балансировки видны через  traffic share count
Есть ньюансы - надо подгонять EIGRP AD/FD/bandwith/delay, чтобы попасть в нужные коэффициенты, но это решаемо

Для BGP c link bandwith - примерно так же, только нет возни с коэффициентами
 На старых коробках может не поддерживаться

2. ECMP для любого протокола: нарезать каналы на 5*100 + 2*100
нарезать ваши суммарные 700Mbit двумя путями на 7 каналов по 100Mbit и хоть забалансируйтесь равномерно.



Все это будет относительно равномерно раскладываться только для множество пар src_dst IP.

[Saab95]

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

Все это будет относительно равномерно раскладываться только для множество пар src_dst IP.

Если разбивать per packet, тогда можно и с одного IP получить полную скорость канала. Но если какие-то каналы будут проседать по скорости или терять данные, такой способ приведет к потерям.