Рад приветствовать всех хабражителей.
В соответствии с новыми требованиями, на работе стали создаваться резервированные каналы связи, при первичной настройке которых, балансировка траффика в EIGRP не заработала, пришлось разбираться с этим интересным вопросом.
Схема сети
Дано:
У нас есть сеть 172.18.230.224/27, назовем её «нашей сетью», из нее передаются очень важные данные в две других сети ID и IE соответственно. Передача должна осуществляться по резервированным каналам связи, то есть у нас есть основной и резервный каналы. Два интересных нюанса:
1) В сеть ID настроена статическая маршрутизация и, sla-monitors и ip load-sharing per-packet, балансировка работает исправно;
2) В сети IE работает протокол динамической маршрутизации EIGRP и при первичной настройке балансировка не заработала, а почему, разберемся далее.
Итак, посмотрим в чем дело по шагам:
1) Посмотрим на топологию EIGRP со второго в маршрутизатора в сеть IE командой: sh ip eigrp topology 192.168.10.0
2) Посмотрим на топологию EIGRP с первого в маршрутизатора в сеть IE командой: sh ip eigrp topology 192.168.10.0
Здесь мы видим bandwith (пропускная способность) и delay (задержка) для локального интерфейса S0/0/0:1 и интерфейса Fa0/1, через который анонсируется второй маршрут до сети IE. Метрика рассчитывается на основании вышеупомянутых коэффициентов K1-K5, а также bandwith (пропускная способность) и delay (задержка). Видим, что у первого прямого маршрута метрика 40514560, у второго через внутренний интерфейс и второй маршрутизатор метрика 40517120, следовательно можно предположить, почему не работает балансировка: первым маршрутизатором используется только первый маршрут, так как у него наилучшая метрика, а второй маршрут является резервным, и он заработает только в случае, если основной канал «упадет».
Проверим нашу догадку
Мы были правы: в таблице маршрутизации у первого маршрутизатора только один маршрут через основной канал.
Решение:
Конечно вариантов решения данной проблемы может быть несколько, но я уже намекнул что метрика рассчитывается на основе таких параметров как коэффициенты K1-K5, пропускной способности и задержки. Может быть, наше решение не будет самым элегантным, но мы постараемся подобрать такую задержку на интерфейсе S0/0/0:1 второго маршрутизатора, чтобы метрики двух маршрутов первого маршрутизатора совпадали.
Краткая теоретическая справка:
Общая метрика вычисляется с помощью значений bandwidth (пропускной способности) и delay (задержки). Bandwidth вычисляется по формуле:
bandwidth = (10000000/bandwidth(m)) * 256
где bandwidth(m) – это минимальная пропускная способность канала на всем пути следования к сети назначения.
Delay:
delay = delay(s) * 256 (в десятках микросекунд)
где delay(s) – это суммарная задержка на всех маршрутизаторах по пути следования к сети назначения.
Эти значения использует протокол EIGRP для подсчета метрики:
Metric=[K1*bandwidth+(K2* bandwidth)/(256-load)+K3*delay]*[K5/(reliability+K4)]
Если коэффициенты не менялись, то формула получает вид:
Metric=K1*bandwidth+ K3*delay
Количество переходов в протоколе EIGRP равно 224, чего более чем достаточно для современных сетей.
Расчет:
Для определения значений коэффициентов, используемых для расчета метрики в EIGRP воспользуемся командой: sh ip protocols
Видим, что вЕса коэффициентов K1=1, K2=0, K3=1, K4=0, K5=0
Так как K2=K4=K5=0 => Metric=K1*bandwidth+ K3*delay, где Bandwidth = 10 ^ 7 / Slowest(B) (in Kbps), Slowest(B) — наименьшая пропускная способность на пути маршрута; Delay = Summa(D) / 10, Summa(D) — сумма всех задержек на пути.
(10^7/64 + 20100 / 10)*256 = (10^7 / 64 + (200+D2)/10)*256
(поделим обе части на 256 и взаимно уничтожим 10^7/64)
20100 = 200 + D2
D2=19900 данное число необходимо поделить на 10, чтобы получить необходимую задержку для S0/0/0:1
D2=1990
Примечание: D = D1 + D2, где D1 сумма задержек на двух интерфейсах Fa0/1, которые соединяют между собой маршрутизаторы и D1=100+100=200. Задержку на интерфейсе посмотрели командой show int fa0/1
Осталось совсем немного. Заходим на второй маршрутизатор в режиме глобальной конфигурации набираем команды:
int S0/0/0:1
delay 1990
Результат:
На 2811-1 появился новый маршрут через интерфейс FastEthernet0/1 и метрики у двух маршрутов совпадают -----> балансировка работает:
Нагрузка основного канала:
Нагрузка резервного канала:
Послесловие:
данное решение может показаться не совсем логичным и изрядно усложняющим дальнейший траблшуттинг, я с этим тезисом полностью соглашусь. Для людей которые не имеют большого опыта работы с CISCO, я думаю, моя статья окажется полезной. Буду рад комментариям и предложениям.
В соответствии с новыми требованиями, на работе стали создаваться резервированные каналы связи, при первичной настройке которых, балансировка траффика в EIGRP не заработала, пришлось разбираться с этим интересным вопросом.
Схема сети
Дано:
У нас есть сеть 172.18.230.224/27, назовем её «нашей сетью», из нее передаются очень важные данные в две других сети ID и IE соответственно. Передача должна осуществляться по резервированным каналам связи, то есть у нас есть основной и резервный каналы. Два интересных нюанса:
1) В сеть ID настроена статическая маршрутизация и, sla-monitors и ip load-sharing per-packet, балансировка работает исправно;
2) В сети IE работает протокол динамической маршрутизации EIGRP и при первичной настройке балансировка не заработала, а почему, разберемся далее.
Итак, посмотрим в чем дело по шагам:
1) Посмотрим на топологию EIGRP со второго в маршрутизатора в сеть IE командой: sh ip eigrp topology 192.168.10.0
2811-2#sh ip eigrp topology 192.168.10.0
IP-EIGRP (AS 1): Topology entry for 192.168.10.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 40512000
Routing Descriptor Blocks:
192.168.199.205 (Serial0/0/0:1), from 192.168.199.205, Send flag is 0x0
Composite metric is (40514560/28160), Route is External
Minimum bandwidth is 64 Kbit
Total delay is 20100 microseconds
{вывод пропущен}
192.168.198.98 (FastEthernet0/1), from 192.168.198.98, Send flag is 0x0
Composite metric is (40517120/40514560), Route is External
Minimum bandwidth is 64 Kbit
Total delay is 20200 microseconds
{вывод пропущен}
2) Посмотрим на топологию EIGRP с первого в маршрутизатора в сеть IE командой: sh ip eigrp topology 192.168.10.0
2811-1#sh ip eigrp topology 192.168.10.0/24
IP-EIGRP (AS 1): Topology entry for 192.168.10.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 40514560
Routing Descriptor Blocks:
192.168.199.201 (Serial0/0/0:1), from 192.168.199.201, Send flag is 0x0
Composite metric is (40514560/28160), Route is External
Vector metric:
Minimum bandwidth is 64 Kbit
Total delay is 20100 microseconds
{вывод пропущен}
192.168.198.99 (FastEthernet0/1), from 192.168.198.99, Send flag is 0x0
Composite metric is (40517120/40514560), Route is External
Vector metric:
Minimum bandwidth is 64 Kbit
Total delay is 20200 microseconds
{вывод пропущен}
Здесь мы видим bandwith (пропускная способность) и delay (задержка) для локального интерфейса S0/0/0:1 и интерфейса Fa0/1, через который анонсируется второй маршрут до сети IE. Метрика рассчитывается на основании вышеупомянутых коэффициентов K1-K5, а также bandwith (пропускная способность) и delay (задержка). Видим, что у первого прямого маршрута метрика 40514560, у второго через внутренний интерфейс и второй маршрутизатор метрика 40517120, следовательно можно предположить, почему не работает балансировка: первым маршрутизатором используется только первый маршрут, так как у него наилучшая метрика, а второй маршрут является резервным, и он заработает только в случае, если основной канал «упадет».
Проверим нашу догадку
2811-1#sh ip route 192.168.10.0
Routing entry for 192.168.10.0/24
Known via "eigrp 1", distance 170, metric 40514560, type external
Redistributing via eigrp 1
Last update from 192.168.199.209 on Serial0/0/0:1, 3d06h ago
Routing Descriptor Blocks:
* 192.168.199.209, from 192.168.199.209, 3d06h ago, via Serial0/0/0:1
Route metric is 40514560, traffic share count is 1
Total delay is 20100 microseconds, minimum bandwidth is 64 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 7/255, Hops 1
Мы были правы: в таблице маршрутизации у первого маршрутизатора только один маршрут через основной канал.
Решение:
Конечно вариантов решения данной проблемы может быть несколько, но я уже намекнул что метрика рассчитывается на основе таких параметров как коэффициенты K1-K5, пропускной способности и задержки. Может быть, наше решение не будет самым элегантным, но мы постараемся подобрать такую задержку на интерфейсе S0/0/0:1 второго маршрутизатора, чтобы метрики двух маршрутов первого маршрутизатора совпадали.
Краткая теоретическая справка:
Общая метрика вычисляется с помощью значений bandwidth (пропускной способности) и delay (задержки). Bandwidth вычисляется по формуле:
bandwidth = (10000000/bandwidth(m)) * 256
где bandwidth(m) – это минимальная пропускная способность канала на всем пути следования к сети назначения.
Delay:
delay = delay(s) * 256 (в десятках микросекунд)
где delay(s) – это суммарная задержка на всех маршрутизаторах по пути следования к сети назначения.
Эти значения использует протокол EIGRP для подсчета метрики:
Metric=[K1*bandwidth+(K2* bandwidth)/(256-load)+K3*delay]*[K5/(reliability+K4)]
Если коэффициенты не менялись, то формула получает вид:
Metric=K1*bandwidth+ K3*delay
Количество переходов в протоколе EIGRP равно 224, чего более чем достаточно для современных сетей.
Расчет:
Для определения значений коэффициентов, используемых для расчета метрики в EIGRP воспользуемся командой: sh ip protocols
2811-1#sh ip protocols
{вывод пропущен}
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
{вывод пропущен}Видим, что вЕса коэффициентов K1=1, K2=0, K3=1, K4=0, K5=0
Так как K2=K4=K5=0 => Metric=K1*bandwidth+ K3*delay, где Bandwidth = 10 ^ 7 / Slowest(B) (in Kbps), Slowest(B) — наименьшая пропускная способность на пути маршрута; Delay = Summa(D) / 10, Summa(D) — сумма всех задержек на пути.
(10^7/64 + 20100 / 10)*256 = (10^7 / 64 + (200+D2)/10)*256
(поделим обе части на 256 и взаимно уничтожим 10^7/64)
20100 = 200 + D2
D2=19900 данное число необходимо поделить на 10, чтобы получить необходимую задержку для S0/0/0:1
D2=1990
Примечание: D = D1 + D2, где D1 сумма задержек на двух интерфейсах Fa0/1, которые соединяют между собой маршрутизаторы и D1=100+100=200. Задержку на интерфейсе посмотрели командой show int fa0/1
Осталось совсем немного. Заходим на второй маршрутизатор в режиме глобальной конфигурации набираем команды:
int S0/0/0:1
delay 1990
Результат:
На 2811-1 появился новый маршрут через интерфейс FastEthernet0/1 и метрики у двух маршрутов совпадают -----> балансировка работает:
2811-1#sh ip route 192.168.10.0
{вывод пропущен}
Routing Descriptor Blocks:
* 192.168.199.201, from 192.168.199.201, 00:14:09 ago, via Serial0/0/0:1
Route metric is 40514560, traffic share count is 1
Total delay is 20100 microseconds, minimum bandwidth is 64 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 39/255, Hops 1
192.168.198.99, from 192.168.198.99, 00:14:09 ago, via FastEthernet0/1
Route metric is 40514560, traffic share count is 1
Total delay is 20100 microseconds, minimum bandwidth is 64 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 35/255, Hops 2
Нагрузка основного канала:
Нагрузка резервного канала:
Послесловие:
данное решение может показаться не совсем логичным и изрядно усложняющим дальнейший траблшуттинг, я с этим тезисом полностью соглашусь. Для людей которые не имеют большого опыта работы с CISCO, я думаю, моя статья окажется полезной. Буду рад комментариям и предложениям.
