Балансировка нагрузки между разнотипными каналами связи используя протокол EIGRP на маршрутизаторах CISCO

Телефонные номера доступа sip операторов VitebskPets - инфопомощь животным в Витебске Телефонные коды городов и стран мира.

Рейтинг статьи: 2.583/5 (12 голосов).

Сбалансировав нагрузку между Serial и Tunnel задумаллся, а в какой пропорции необходимо разделять траффик между каналами с одинаковой пропускной способностью. Выяснилось, что тунель накладывает дополнительные накладные расходы, а Телеком на VPN режет трафик с помощью police (то есть удаляем все лишнее не глядя).

Спонсор этой страницы:

Описание схемы

Имеем 2 канала связи по 512 кбит/c. Один через Serial, Второй через VPN и GRE тунелирование.

interface serial0
  bandwidth 512
  ip address 192.168.10.1 255.255.255.252
  ip mtu 1476
  ip load-sharing per-packet

interface tunnel0
  bandwidth 512
  ip address 192.168.10.5 255.255.255.252
  ip mtu 1476
  delay 2000
  ip load-sharing per-packet

router eigrp 100
  network 192.168.10.0
  network 10.0.0.0
  no auto-summary
  variance 2

В данном варианте каналы связи Serial и Tunnel сбалансированны равнозначно 1:1
Но правильно ли это?

Теоретические размышления

При инкапсуляции пакета в GRE тунель происходит увеличение пакета на 24 байта.
Соответственно, при идеальных условиях (все пакеты максимальной длинны) прирост составит 1500/1476 (или 1,6%)
А если мы используем VoIP с размером пакета в зависимости от кодека 60-200 байт, то прирост в 24 байта может дать прирост до 40% в объеме трафика.

Соостветственно необходимо вычислить (взять интуитивно или еще каким образом) процент прироста.

После теоретических выкладок было решено взять цифры из практики.
Банальная команда clear counter и через несколько часов sh int | i packets output

6046254 packets output, 1382510683 bytes, 0 underruns

1382510683/6046254 Разделив количество байт на количество пакетов, получаем среднюю длинну пакета в 230 байт
Соответственно, (230+24)/230 получаем 11%.
Что собственно и показало расхождение в тунеле и на физическом интерфейсе.
Так что теория совпала с практикой.

Пути решения

Необходимо на тунельном интерфейсе уменьшить bandwich на 11%
512/1,11 = 461

interface tunnel0
  bandwidth 461
  delay 2220

Router#sh ip route 10.1.1.1
Routing entry for 10.0.0.0/8
  Known via "eigrp 100", distance 90, metric 5514496, type internal
  Redistributing via eigrp 100
  Last update from 192.168.10.6 on Tunnel0, 00:00:07 ago
  Routing Descriptor Blocks:
  * 192.168.10.2, from 192.168.10.2, 00:00:07 ago, via Serial0
        Route metric is 5514496, traffic share count is 10
      Total delay is 20100 microseconds, minimum bandwidth is 512 Kbit
      Reliability 255/255, minimum MTU 1472 bytes
      Loading 1/255, Hops 1
    192.168.10.6, from 192.168.10.6, 00:00:07 ago, via Tunnel0
      Route metric is 6123776, traffic share count is 9
      Total delay is 22300 microseconds, minimum bandwidth is 461 Kbit
      Reliability 255/255, minimum MTU 1472 bytes
      Loading 49/255, Hops 1

Router#sh int | i 5 minute output
  5 minute output rate 91000 bits/sec, 54 packets/sec
  5 minute output rate 91000 bits/sec, 50 packets/sec

В общем после очередного clear counter и часа ожидания достигнуто равновесие в великой силе.

Причины, по которым происходят тормоза при максимальных нагрузках, описанные в статье по Балансировке нагрузки между каналми связи используя протокол EIGRP стали более понятны.

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

p.s. Ну и неплохо зашейпить трафик на тунельном интерфейсе, пока его не срезал телеком.

policy-map out_512_tunnel
  class class-default
    shape average 461000
interface tunnel0
  service-policy output out_512_tunnel

Думаю, что по балансировке еще не все.
Буду исследовать дальше.
Удачной работы с минимальными потерями.

Cisco Systems маршрутизатор

Комментариев нет. Станьте первым!