2008-10-28

маленькое издевательство с eigrp

у eigrp есть такая фича - goodbye пакет. он позволяет роутеру штатно завершащему работу протокола предупредить соседей о своем уходе.
как он работает? очень просто - в хелло пакете устанавливаются все К-коефициенты в 255.

теперь вопрос, что будет если на живом роутере их всех установить в 255? :)

эксперимент:
два соседних роутера, R0 (10.255.1.0/31), R1 (20.255.1.1/31)

1) только на одном из соседей

R1(config)# router eigrp 1
R1(config-router)# metric weights 0 255 255 255 255 255

результат:

R0#
*Mar 1 00:07:51.207: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.1 (Serial0/0) is down: Interface Goodbye received
*Mar 1 00:07:55.515: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.1 (Serial0/0) is down: Interface Goodbye received
*Mar 1 00:08:00.107: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.1 (Serial0/0) is down: Interface Goodbye received
*Mar 1 00:08:00.163: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.1 (Serial0/0) is down: Interface Goodbye received

"пока, пока, пока..." :)
прям-таки goodbye protocol :)

R1(config-router)#
*Mar 1 00:08:04.179: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.0 (Serial0/0) is down: K-value mismatch
*Mar 1 00:08:08.699: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.0 (Serial0/0) is down: K-value mismatch
*Mar 1 00:08:13.083: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.0 (Serial0/0) is down: K-value mismatch
*Mar 1 00:08:17.639: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.0 (Serial0/0) is down: K-value mismatch

ну а тут все ок - коефициенты-то реально не совпадают.

2) на обоих :)


R0(config)#router eigrp 1
R0(config-router)#metric weights 0 255 255 255 255 255
R0(config-router)#^Z
R0#
*Mar 1 00:09:03.291: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 00:09:05.679: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.1 (Serial0/0) is up: new adjacency


R1#
*Mar 1 00:09:02.247: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.0 (Serial0/0) is up: new adjacency

все ок. в чем же тогда подвох?

3) проверим как работает goodbye в случаях 0 и 2

R1(config)#no router eigrp


R0#
*Mar 1 00:13:14.439: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.1 (Serial0/0) is down: holding time expired

вернем К-коефициенты обратно

R1(config)#router eigrp 1
R1(config-router)#network 0.0.0.0
R1(config-router)#defaule metric weights


R0(config)#router eigrp 1
R0(config-router)#network 0.0.0.0
R0(config-router)#defaule metric weights
*Mar 1 00:13:44.767: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.1 (Serial0/0) is up: new adjacency
R0(config-router)#no router eigrp 1


R1#
*Mar 1 00:15:54.079: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.255.1.0 (Serial0/0) is down: Interface Goodbye received


мило не правда ли? :)

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...