http://nettips.ru

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

На главную Cisco Systems VoIP маршрутизатор Беларусь Asterisk коммутатор Nateks Alcatel MTS Gigaset Velcom ZTE Grandstream Android Huawei админы шутят о сайте Zelax Allied Telesis D-Link Arduino Штрихкоды HP
Телефонные номера доступа sip операторов Телефонные коды городов и стран мира.

Рейтинг статьи: 2.636/5 Рейтинг 2.64 из 5Рейтинг 2.64 из 5Рейтинг 2.64 из 5Рейтинг 2.64 из 5Рейтинг 2.64 из 5 (11 голосов).

Сбалансировав нагрузку между 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 маршрутизатор

Пожалуйста, оцените и ВЫ эту статью:

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


Ваши отзывы и предложения по работе сайта направляйте на форму обратной связи.

Яндекс.Метрика