2008-10-18

метрики eigrp

метрики eigrp - тема очень интересного разговора :)
ведь именно они - одно из "сильных" преимуществ данного протокола.

пройдемся по типовым заблуждениям :)
для примера будем рассматривать все применительно к следующей топологии:

между R0 и R1 два линка - езернет и последовательный.

1) мту используеться в качестве компонента метрики

бытует заблуждение что метрик 5:
* минимальная пропускная
* суммарная задержка
* загруженность
* надежность
* мту
и что каждой метрике соответствует K-коефициент
естественно что ЭТО НЕ ТАК :)
формула расчета метрики следующая:

Metric = 256*([K1*Bw + K2*Bw/(256-Load) + K3*Delay]*[K5/(Reliability + K4)])

ну и кто здесь увидел мту? :)
и кто сказал что К5 связан с мту? :)

2) еигрп не использует хопкаунт

естественно, хопкаунт не используется для _численного_ влияния на метрику. но он используеться для ограничения диаметра домена еигрп. кроме того, испытания показали, что если все к-коефициенты обнулить, еигрп эффективно превращаеться в рипв2 :) и использует только хопкаунт для сравнения маршрутов и предотвращения лупов :)
хопкаут передаеться и храниться для каждого маршрута:
осед анонсирует маршрут на свой лупбек 10.2.1.0/24.

R1#sh ip eigrp to 10.2.1.0/24
IP-EIGRP (AS 1): Topology entry for 10.2.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
Routing Descriptor Blocks:
10.255.12.2 (Serial0/1), from 10.255.12.2, Send flag is 0x0
Composite metric is (2297856/128256), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 25000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1


3) еигрп динамически определяет задержки

кое-где в материалах по еигрп пишеться что для измерения метрики еигрп использует следующее число


R1#sh ip ei ne
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.255.12.2 Se0/1 14 00:43:38 291 1746 0 4
0 10.255.1.0 Se0/0 11 01:05:01 96 576 0 30


но это легко опровергнуть. у R1 есть сосед 10.255.12.2. сосед анонсирует маршрут на свой лупбек 10.2.1.0/24.

R1#sh ip eigrp to 10.2.1.0/24
IP-EIGRP (AS 1): Topology entry for 10.2.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
Routing Descriptor Blocks:
10.255.12.2 (Serial0/1), from 10.255.12.2, Send flag is 0x0
Composite metric is (2297856/128256), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 25000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1

srtt=291мс
суммарный делей=25мс
неправда ли странно? :)

зато оно сходиться с следующими расчетами:
1) 10.255.12.2 анонсирует маршрут лупбека.

R2#sh int lo1 | in address|DLY
Internet address is 10.2.1.1/24
MTU 1514 bytes, BW 8000000 Kbit, DLY 5000 usec,

5000нс - стартовый делей
R1 прибавляет делей линка между ними:

R1#sh int s0/1 | in address|DLY
Internet address is 10.255.12.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

20000нс - добавленный делей.
сумма - 25мс

возникает вопрос: от чего зависит и как измеряется параметр DLY?
ответ: он зависит только от типа интерфейса, а именно:
serial - DLY=20000
fastethernet - DLY=100
loopback - DLY=5000

4) еигрп может эффективно использовать загруженность линка для балансировки загрузки

во первых надо убедиться что еигрп реально динамически определяет загруженность, а не пользуется шаблонными значенияими:
пустим тестовый поток траффики между маршрутизаторами:
R0# ttcp receive
R2# ttcp transmit 10.0.1.1
теперь проверим на транзитном R1 результаты:

R1#sh int s0/0 | in load
reliability 255/255, txload 51/255, rxload 4/255
R1#sh int s0/1 | in load
reliability 255/255, txload 4/255, rxload 51/255

сам маршрутизатор потоки трафика "видит". а еигрп:

R1#sh ip ei to 10.0.1.0/24
IP-EIGRP (AS 1): Topology entry for 10.0.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 896000
Routing Descriptor Blocks:
10.255.1.0 (Serial0/0), from 10.255.1.0, Send flag is 0x0
Composite metric is (2297856/128256), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 25000 microseconds
Reliability is 255/255
Load is 56/255
Minimum MTU is 1500
Hop count is 1
R1#sh ip ei to 10.2.1.0/24
IP-EIGRP (AS 1): Topology entry for 10.2.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
Routing Descriptor Blocks:
10.255.12.2 (Serial0/1), from 10.255.12.2, Send flag is 0x0
Composite metric is (2297856/128256), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 25000 microseconds
Reliability is 255/255
Load is 5/255
Minimum MTU is 1500
Hop count is 1

как мы видим, нагрузка учитывается, но только txload. в принципе неплохо :)
теперь усложняем задачу :)
активируем между R0 и R1 резервный линк :)
причем, для чистоты эксперимента, делаем на обоих одинаковую пропускную (скажем по 1.5М) и задержку (ведь вы помните, для фаста она будет 0.1мс, а для последовательного 20мс :))

R0(config)#int fa1/0
R0(config-if)#band 1500
R0(config-if)#delay 10
R1(config)#int fa1/0
R1(config-if)#bandwidth 1500
R1(config-if)#delay 10

теперь, установим К-коефициент загруженности:

router eigrp 1
metric weights 0 1 1 1 0 0

и, смертельный номер, отключаем балансировку нагрузки:

router eigrp 1
maximum-paths 1

зачем все эти ухищрения? очень просто. в реальной сети приблизительно равные маршруты которые будут successor в зависимости от уровня загрузки найти не трудно, а подобрать в лабораторной топологии оптимальные значения мне лень :)
таким образом я упрощаю себе задачу для того что б рассмотреть концепцию использования загруженности

далее, проверим таблицу маршрутов на R1:

R1#sh ip ro 10.0.1.0
Routing entry for 10.0.1.0/24
Known via "eigrp 1", distance 90, metric 1713188, type internal
Redistributing via eigrp 1
Last update from 10.255.0.0 on FastEthernet1/0, 00:00:25 ago
Routing Descriptor Blocks:
* 10.255.0.0, from 10.255.0.0, 00:00:25 ago, via FastEthernet1/0
Route metric is 1713188, traffic share count is 1
Total delay is 15000 microseconds, minimum bandwidth is 1500 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
R1#sh ip eigrp to 10.0.1.0/24
IP-EIGRP (AS 1): Topology entry for 10.0.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1713188
Routing Descriptor Blocks:
10.255.0.0 (FastEthernet1/0), from 10.255.0.0, Send flag is 0x0
Composite metric is (1713188/257), Route is Internal
Vector metric:
Minimum bandwidth is 1500 Kbit
Total delay is 15000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
10.255.1.0 (Serial0/0), from 10.255.1.0, Send flag is 0x0
Composite metric is (1713188/257), Route is Internal
Vector metric:
Minimum bandwidth is 1500 Kbit
Total delay is 15000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1

т.е. в таблице топологии есть 2 записи, и одна запись установлена в таблицу маршрутов?
тут возникает вопрос: которая из записей установлена? и как она была выбрана из 2х идентичных маршрутов?
сразу отвечу: была выбрана по _минимальному_ айпи некстхопа :)

теперь пускаем тест:

R0# ttcp receive
R1# debug ip eigtp
R2# ttcp transmit 10.0.1.1

что забавного можно пронаблюдать?
смотрите сами:

R1#sh int fa1/0 | in txload
reliability 255/255, txload 60/255, rxload 1/255
R1#sh ip ei to 10.0.1.0/24
IP-EIGRP (AS 1): Topology entry for 10.0.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2097188
Routing Descriptor Blocks:
10.255.0.0 (FastEthernet1/0), from 10.255.0.0, Send flag is 0x0
Composite metric is (2097188/128257), Route is Internal
Vector metric:
Minimum bandwidth is 1500 Kbit
Total delay is 15000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
10.255.1.0 (Serial0/0), from 10.255.1.0, Send flag is 0x0
Composite metric is (2097188/128257), Route is Internal
Vector metric:
Minimum bandwidth is 1500 Kbit
Total delay is 15000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1

не смотря на рост txload метрика маршрута не меняеться... странно, не правда ли? :)
связанно это с механизмом обработки маршрутов в еигрп, а именно с событийным механизмом обработки маршрутов: нет события - нет пересчета.
давайте проверим:

R1(config)# int fa1/0
R1(config-if)# band 1501
...
R1#sh ip ei to 10.0.1.0/24
IP-EIGRP (AS 1): Topology entry for 10.0.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2096160
Routing Descriptor Blocks:
10.255.0.0 (FastEthernet1/0), from 10.255.0.0, Send flag is 0x0
Composite metric is (2096160/128257), Route is Internal
Vector metric:
Minimum bandwidth is 1501 Kbit
Total delay is 15000 microseconds
Reliability is 255/255
Load is 82/255
Minimum MTU is 1500
Hop count is 1
10.255.1.0 (Serial0/0), from 10.255.1.0, Send flag is 0x0
Composite metric is (2097188/128257), Route is Internal
Vector metric:
Minimum bandwidth is 1500 Kbit
Total delay is 15000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1

как мы видим, мгновенно поднялся лод :)
вот и проблема - лод учитывается метрикой еигрп не сразу, а при изменении топологии либо таймере (на глазок - 10 минут).



п.с. полезные ссылки:
http://www.rhyshaden.com/eigrp.htm


to be continued...

Немає коментарів: