martes, 19 de mayo de 2009
Continuando con la senda del valor de MTU, un protocolo que nos indica este valor en un camino es EIGRP (protocolo propietario de Cisco, por ende no existe RFC asociado).
Seteamos eigrp en el AS 1 (Sistema autónnomo 1) compuesto por P1R1, P1R2 Y P1R4. Si sólo se modifica la MTU para los paquetes IP en la interface FastEthernet0/0 de P1R2 a 1498 bytes, en P1R1 la loopback del P1R4 se verá como sigue.
P1R1#sh ip rou 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "eigrp 1", distance 90, metric 158720, type internal
Redistributing via eigrp 1
Last update from 10.1.0.2 on FastEthernet0/1, 00:00:48 ago
Routing Descriptor Blocks:
* 10.1.0.2, from 10.1.0.2, 00:00:48 ago, via FastEthernet0/1
Route metric is 158720, traffic share count is 1
Total delay is 5200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1498 bytes
Loading 1/255, Hops 2
P1R2#sh run int f0/0
Building configuration...
Current configuration : 105 bytes
!
interface FastEthernet0/0
ip address 10.1.2.2 255.255.255.0
ip mtu 1498
speed 100
full-duplex
end
Es importante destacar que no se obtiene el mismo resultado si se modifica sólo la FastEthernet0/1 de P1R2.
P1R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
P1R2(config)#interface FastEthernet0/0
P1R2(config-if)#no ip mtu 1498
P1R2(config-if)#interface FastEthernet0/1
P1R2(config-if)#ip mtu 1498
P1R2(config-if)#end
P1R1#sh ip rou 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "eigrp 1", distance 90, metric 158720, type internal
Redistributing via eigrp 1
Last update from 10.1.0.2 on FastEthernet0/1, 00:00:00 ago
Routing Descriptor Blocks:
* 10.1.0.2, from 10.1.0.2, 00:00:00 ago, via FastEthernet0/1
Route metric is 158720, traffic share count is 1
Total delay is 5200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
¿Pero esto modifica la métrica de la ruta?; NO. Es sólo un valor informativo, veamos cómo se calcula la métrica entonces. Básicamente se sigue la siguiente fórmula:
EIGRP Metric = 256*((K1*Bw)+(K2*Bw)/(256-Load)+(K3*Delay)*(K5/(Reliability + K4)))
Si K5 es 0, entonces (K5/(Reliability + K4)) se define igual a 1.
K1, .., K5 son valores arbitrarios que se pueden definir con el comando metric weights tos k1 k2 k3 k4 k5, siendo tos siempre 0 (el default es metric weights 0 1 0 1 0 0, o sea k1=k3=1, k2=k4=k5=0). El resto de los valores se obtienen del output de show ip route tomando en consideración que:
BW = 10^7/(minimum bandwidth)
Delay = delay/10 [suma de todos los delay del camino]
Load = Primer valor de Loading
Reliability = Primer valor de Reliability
Por lo general no es conveniente modificar los valores default de K1, .., K5. De esta forma además la fórmula se simplifica a:
EIGRP Metric = 256*(K1*Bw + K3*Delay)
A continuación se verá qué sucede al modificar los valores de K1, .., K5 y ejemplos de cálculo de métrica. Si se toma la configuración de la figura al comienzo del post, P1R2 tiene vecindad eigrp con P1R1 y P1R4.
P1R2#sh ip eigrp nei
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq Type
(sec) (ms) Cnt Num
1 10.1.2.4 Fa0/0 14 00:21:05 4 200 0 25
0 10.1.0.1 Fa0/1 14 00:53:15 1 200 0 18
Al modificar el valor de los factores de la fórmula en P1R4, desde P1R2 se pierde la vecindad contra ese equipo.
P1R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
P1R4(config)#router eigrp 1
P1R4(config-router)#metric weights 0 2 0 1 0 0
P1R2#sh ip eigrp nei
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq Type
(sec) (ms) Cnt Num
0 10.1.0.1 Fa0/1 14 00:53:43 1 200 0 19
Luego se modifican los valores en P1R2 y vemos que se recupera la vecindad con P1R4, pero se ha perdido contra P1R1.
P1R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
P1R2(config)#router eigrp 1
P1R2(config-router)#metric weights 0 2 0 1 0 0
P1R2(config-router)#end
P1R2#
5d01h: %SYS-5-CONFIG_I: Configured from console by vty0 (172.31.1.3)
P1R2#sh ip eigrp nei
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq Type
(sec) (ms) Cnt Num
1 10.1.2.4 Fa0/0 13 00:00:02 594 3564 0 28
P1R2#
La moraleja es no utilizar este comando a no ser que se distribuya a todos los equipos del sistema autónomo y teniendo en cuenta realmente lo que implica. Ahora se dejarán los valores a su nivel por default y se verán ejemplos de cálculo de métrica.
Desde P1R2 se analiza la ruta a la red conectada a la F0/0 de P1R1
P1R2#sh ip rou 10.1.1.0
Routing entry for 10.1.1.0/24
Known via "eigrp 1", distance 90, metric 30720, type internal
Redistributing via eigrp 1
Last update from 10.1.0.1 on FastEthernet0/1, 00:00:04 ago
Routing Descriptor Blocks:
* 10.1.0.1, from 10.1.0.1, 00:00:04 ago, via FastEthernet0/1
Route metric is 30720, traffic share count is 1
Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
La fórmula dice entonces
EIGRP Metric = 256*(K1*Bw + K3*Delay)
= 256*(K1*10^7/(minimum bandwidth) + K3*delay/10)
= 256*(1*10^7/(minimum bandwidth) + 1*delay/10)
= 256*(10^7/100000 + 200/10)
= 256*(100 + 20)
= 30720
Algunos valores default de BW y delay asociados a distintos tipos de interfaces se encuentra en la siguiente tabla
Media.........Bandwidth..Delay
FastEthernet...100000K...100µS
Ethernet........10000K...1000µS
T1..............1544K....20000µS
DS0..............64K....20000µS
56K..............56K....20000µS
Por último veamos otro ejemplo.
P1R2#sh ip rou 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "eigrp 1", distance 90, metric 156160, type internal
Redistributing via eigrp 1
Last update from 10.1.0.1 on FastEthernet0/1, 00:00:02 ago
Routing Descriptor Blocks:
* 10.1.0.1, from 10.1.0.1, 00:00:02 ago, via FastEthernet0/1
Route metric is 156160, traffic share count is 1
Total delay is 5100 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
La lógica indica que al ser una red conectada directamente a P1R1 (tal como la anterior) debiera entonces tener la misma métrica. Pues bien, la diferencia radica en el tipo de interface a que están conectada, una a una FastEthernet y otra a una Loopback. Qué BW/delay le asocia entonces? no encontré referencia alguna en Google, pero es sencillo notar que le asocia un delay de 5000 mircoseconds y un BW igual o mayor a 100000 Kbps (entonces no relevante para el cálculo). El resultado de la fórmula entonces es:
= 256*(10^7/100000 + (5000+100)/10) [delay 5000 de la Loopback + 100 de la FastEthernet0/1 de P1R2]
= 256*(100 + 510)
= 156160
Veamos qué pasa si la loopback 0 de P1R1 "se convierte" en una FastEthernet.
P1R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
P1R1(config)#int loop0
P1R1(config-if)#delay 10
P1R1(config-if)#delay ?
<1-16777215> Throughput delay (tens of microseconds)
P1R1(config-if)#end
P1R2#sh ip rou 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "eigrp 1", distance 90, metric 30720, type internal
Redistributing via eigrp 1
Last update from 10.1.0.1 on FastEthernet0/1, 00:00:34 ago
Routing Descriptor Blocks:
* 10.1.0.1, from 10.1.0.1, 00:00:34 ago, via FastEthernet0/1
Route metric is 30720, traffic share count is 1
Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Misma métrica que el primer ejemplo ;)
Hay que tener precaución con las unidades del delay. Para configurar las interfaces se usa la misma unidad que en el cálculo de la métrica (tens of microseconds), que no es la misma que se ve en el show ip route (microseconds).
Suscribirse a:
Enviar comentarios (Atom)
Muy informativo, gracias.