Рейтинг статьи: 2.692/5 
(39 голосов).
Спонсор этой страницы:
Схема сети и настройка двух маршрутизаторов
Настройка локальных адресов и поднятие протокола HSRP
Конфигурация маршрутизатора 1
interface g0/0.1
encapsulation dot1Q 1
ip address 10.0.0.101 255.255.255.0
standby 1 ip 10.0.0.1
standby 1 priority 110
standby 1 preempt
Конфигурация маршрутизатора 2
interface g0/0.1
encapsulation dot1Q 1
ip address 10.0.0.102 255.255.255.0
standby 1 ip 10.0.0.1
standby 1 priority 90
standby 1 preempt
Настройка адресов сети провайдера
Конфигурация маршрутизатора 1
interface g0/0.100
encapsulation dot1Q 100
ip address 10.100.0.1 255.255.255.248
ip route 10.100.0.0 255.255.0.0 10.100.0.6
Конфигурация маршрутизатора 2
interface G0/0.100
encapsulation dot1Q 100
ip address 10.100.0.2 255.255.255.248
ip route 10.100.0.0 255.255.0.0 10.100.0.6
Настройка Сериального интерфейса
interface Serial0/0/0
description Office 2
ip address 10.200.0.1 255.255.255.252
Поднятие протокола EIGRP
Конфигурация маршрутизаторов 1 и 2
router eigrp 100
network 10.0.0.0
no auto-summary
passive-interface Gi0/0.100
При аналогичной настройке маршрутизаторов офиса 2 все начинает работать.
Проверяем маршруты и метрики в таблице маршрутизации
с2821_1#sh ip eigrp top 10.1.1.0/24
IP-EIGRP (AS 100): Topology entry for 10.1.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 933632
Routing Descriptor Blocks:
10.200.0.2 (Serial0/0/0), from 10.200.0.2, Send flag is 0x0
Composite metric is (1764352/28160), Route is Internal
Vector metric:
Minimum bandwidth is 2048 Kbit
Total delay is 20100 microseconds
Reliability is 0/255
Load is 42/255
Minimum MTU is 1500
Hop count is 1
с2821_1#sh ip route 10.1.1.0
Routing entry for 10.1.1.0/24
Known via "eigrp 100", distance 90, metric 1764352, type internal
Redistributing via eigrp 100
Last update from 10.200.0.2 on Serial0/0/0, 05:13:54 ago
Routing Descriptor Blocks:
* 10.1.1.0, from 10.200.0.54, 05:13:54 ago, via Serial0/0/0
Route metric is 1764352, traffic share count is 1
Total delay is 20100 microseconds, minimum bandwidth is 2048 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 42/255, Hops 1
Хотя матрика состоит из суммы метрик разных сегментов, мы можем приблизительно расчитать метрики по формуле:
metric=(10 000 000/bandwidth+delay/10)*256
Данная формула работает, когда все коэффициенты в протоколе EIGRP настроены по умолчанию, что означает, что в расчете метрики используется только ширина канала и задержка
(10000000/2048+20100/10)*256=1764560
Настройка тунелей
После некоторых проб и ошибок было построено до второго офиса 2 тунеля
c2821_1 - c2821_4
c2821_2 - c2821_3
Конфигурация маршрутизатора 1
interface Tunnel24
description Office2_router4
bandwidth 2048
ip address 10.200.2.1 255.255.255.252
delay 2000
keepalive 10 3
tunnel source 10.100.0.1
tunnel destination 10.100.2.4
Конфигурация маршрутизатора 2
interface Tunnel23
description Office2_router3
bandwidth 2048
ip address 10.200.2.5 255.255.255.252
delay 2000
keepalive 10 3
tunnel source 10.100.0.2
tunnel destination 10.100.2.3
При аналогичной настройке маршрутизаторов офиса 2 поднимается маршрутизация на тунелях.
Мало вероятно, что одновременно выйдут из строя маршрутизаторы 1 3, но для подстраховки можно поднять тунель между 2 и 4.
Данная схема реализует балансировку трафика per-destination и только, если метрики одинаковые. При этом общая пропускная способность будет суммой двух каналов, но пропускная способность единичного компьютера не привысит пропускную способность одного канала.
Балансировка per-packet
Для включения балансировки по пакетам добавляем на всех интерфейсах
ip load-sharing per-packet
При этом на интерфейсы Serial0/0/0 и Tunnel24 будут циклически посылаться группы пакетов и пропускная способность отдельзых соединений достигнет суммы пропускной способности двух каналов.
Далее была обнаружена такая проблема:
В связи с тем, что провайдер режет трафик на уровне физического интерфейса, а на данном интерфейсе есть трафик от других подразделений (офисы 2,3,4), то при максимальных нагрузках наблюдаются глюки в виде пропадания пакетов и резкого падения скорости.
(Спасибо механизму TCP windows)
После замеров объемов входящего трафика в офисе 2, было решено разделить трафик между Serial0/0/0 и Tunnel24 в пропорции 4 к 3.
Балансировка с разными метриками
router eigrp 100
variance 2
traffic-share balanced
maximum-paths 2
variance N указывает во сколька раз метрика одного канала может превышать метрику другого, участвуя в передаче трафика
Что бы увеличить метрику на интерфейсе можно или уменьшить bandwidth или увеличить delay
оптимальнее bandwidth не трогать, и после небольших расчетов увеличил delay
interface Tunnel24
delay 4300
Чтобы трафик шел только через один тунел, увеличиваем Delay и втором паршрутизаторе на величину большую, чем на рабочем тунеле.
interface Tunnel23
delay 6000
Получаем неравномерную балансировку/
с2821_1#sh ip route 10.1.1.1
Routing entry for 10.1.1.0/24
Known via "eigrp 100", distance 90, metric 1764352, type internal
Redistributing via eigrp 100
Last update from 10.200.0.2 on Serial0/0/0, 00:13:54 ago
Routing Descriptor Blocks:
* 10.200.0.2, from 10.200.0.2, 00:00:13 ago, via Serial0/0/0
Route metric is 1764352, traffic share count is 4
Total delay is 20100 microseconds, minimum bandwidth is 2048 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 42/255, Hops 1
10.200.2.2, from 10.200.2.2, 00:00:13 ago, via Tunnel24
Route metric is 2353152, traffic share count is 3
Total delay is 43100 microseconds, minimum bandwidth is 2048 Kbit
Reliability 255/255, minimum MTU 1476 bytes
Loading 85/255, Hops 1
Согласно traffic share count is на каждые 4 пакета, направляемые в Serial0/0/0 в Tunnel24 будут напрвлены 3 пакета
В случае каналов разной пропускной способности, метрика пересчитается исходя из bandwidth и, соотвественно, пересчитает и соостношение количества передаваемых пакетов
Тормоза отдельных компьютеров
После построения схемы были замечены непонятные тормоза при незагруженных каналах.
Было выдвинуто предположение, что глюки возникази из за того, на разных интерфейсах были разные MTU.
Сесия начиналась через Serial и продолжаласт через Tunnel.
Для проверки версии на некоторых компьютерах на сетевых интерфейсах был уменьшен MTU до l300.
Тормоза на данных компьютерах исчезли.
Пока часть компьютеров и измененным MTU работало искал решение для остальных, так как офисов много, и на всех компах менять MTU тяжело
Для проверки была использована команда ping.
Проверяем серийный интерфейс
ping 10.200.0.2 -l 1449 -f
Ответ от 10.200.0.2: число байт=1449 время=51мс TTL=254
Ответ от 10.200.0.2: число байт=1449 время=51мс TTL=254
Ответ от 10.200.0.2: число байт=1449 время=51мс TTL=254
Ответ от 10.200.0.2: число байт=1449 время=51мс TTL=254
Проверяем тунельный интерфейс
ping 10.200.2.2 -l 1449 -f
Превышен интервал ожидания для запроса.
Ответ от 10.0.0.101: Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Пингуем компьютер в сети Офиса
ping 10.1.1.25 -l 1449 -f
Ответ от 10.1.1.25: число байт=1449 время=61мс TTL=252
Ответ от 10.0.0.101: Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
После копания интернета и документации добавили на всех сериальных и тунельных интерфейсах:
interface xxx
ip mtu 1476
ping 10.1.1.25 -l 1449 -f
Ответ от 10.0.0.101: Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
В общем по балансировке все.
Если возникнут проблемы, буду искать решение, после чего опубликую.
Удачной работы с минимальными потерями.
Комментариев нет. Станьте первым!