Continuando el post anterior, se procederá a balancear carga a través de BGP sin utilizar multipath. Básicamente se tendrá sólo una ruta por BGP al destino, pero dos caminos para el next hop (recursive lookup). En esta ocasión se configurará una única sesión eBGP entre P1R1 y P1R4 como se muestra en la figura. Cabe recordar que, tal como el resto de los ejemplos de este blog, la red en cuestión no corresponde a un diseño adecuado, su propósito es méramente académido.

P1R1#sh run | b router bgp
router bgp 64512
no synchronization
network 10.1.0.0 mask 255.255.255.0
network 10.1.1.0 mask 255.255.255.0
network 10.1.5.0 mask 255.255.255.0
 neighbor 4.4.4.4 remote-as 65534
 neighbor 4.4.4.4 ebgp-multihop 3
neighbor 4.4.4.4 update-source Loopback0
no auto-summary
!

P1R4#sh run | b router bgp
router bgp 65534
no synchronization
bgp log-neighbor-changes
network 10.1.2.0 mask 255.255.255.0
network 10.1.3.0 mask 255.255.255.0
neighbor 1.1.1.1 remote-as 64512
neighbor 1.1.1.1 ebgp-multihop 3
neighbor 1.1.1.1 update-source Loopback0
no auto-summary
!

Si observamos la red conectada a P1R1 desde P1R4.

P1R4#sh ip bgp 10.1.5.0
BGP routing table entry for 10.1.5.0/24, version 31
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Multipath: eBGP
Not advertised to any peer
64512
1.1.1.1 (metric 158720) from 1.1.1.1 (10.11.11.11)
Origin IGP, metric 0, localpref 100, valid, external, best

No es directo que esté balanceando. Ésto se revelará al observar el next-hop.

P1R4#sh ip rou 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "eigrp 1", distance 90, metric 158720, type internal
Redistributing via eigrp 1
Last update from 10.1.3.3 on FastEthernet0/1, 03:00:14 ago
Routing Descriptor Blocks:
* 10.1.2.2, from 10.1.2.2, 03:00:14 ago, via FastEthernet0/0
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
10.1.3.3, from 10.1.3.3, 03:00:14 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

Más claro aún con CEF.

P1R4#sh ip cef 1.1.1.1 int
1.1.1.1/32, version 40, epoch 0, per-destination sharing
0 packets, 0 bytes
via 10.1.2.2, FastEthernet0/0, 1 dependency
traffic share 1
next hop 10.1.2.2, FastEthernet0/0
valid adjacency
via 10.1.3.3, FastEthernet0/1, 2 dependencies
traffic share 1
next hop 10.1.3.3, FastEthernet0/1
valid adjacency
!resto del output omitido

¿Qué pasaría si las rutas al next hop no tuvieran el mismo costo?. Con la configuración actual simplemente se tendría un único camino y no se balancearía carga como se ve al modificar un parámetro del cálculo de métrica (delay) en EIGRP de 100 a 1000 microseconds en la interface FastEthernet0/1 de P1R4 (atención con las unidades como se describió en EIGRP, MTU y métrica).

P1R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
P1R4(config)#int f0/1             
P1R4(config-if)#no delay 10
P1R4(config-if)#end
P1R4#
*Apr 13 05:27:01.470: %SYS-5-CONFIG_I: Configured from console by vty0 (10.1.2.2)
P1R4#sh ip rou 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "eigrp 1", distance 90, metric 158720, type internal
Redistributing via eigrp 1
Last update from 10.1.2.2 on FastEthernet0/0, 00:00:00 ago
Routing Descriptor Blocks:
* 10.1.2.2, from 10.1.2.2, 00:00:00 ago, via FastEthernet0/0
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

P1R4#sh ip cef 1.1.1.1 int
1.1.1.1/32, version 59, epoch 0, cached adjacency 10.1.2.2
0 packets, 0 bytes
via 10.1.2.2, FastEthernet0/0, 3 dependencies
next hop 10.1.2.2, FastEthernet0/0
valid cached adjacency
P1R4#

P1R4#sh ip eig topo 1.1.1.1/32
IP-EIGRP (AS 1): Topology entry for 1.1.1.1/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 158720
Routing Descriptor Blocks:
10.1.2.2 (FastEthernet0/0), from 10.1.2.2, Send flag is 0x0
Composite metric is (158720/156160), Route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 5200 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
10.1.3.3 (FastEthernet0/1), from 10.1.3.3, Send flag is 0x0
Composite metric is (181760/156160), Route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 6100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2

Para hacer provecho de todas las herramientas que nos brinda EIGRP, se utilizará el comando variance para balancear proporcional a cada interface según su métrica.

P1R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
P1R4(config)#router eigrp 1
P1R4(config-router)#variance 2
P1R4(config-router)#^Z
P1R4#

¿Qué significa esto?. Básicamente variance por defecto es igual a 1, lo que implica balanceo exclusivo para rutas de igual costo. Modificar su valor a 2 nos permite incluir en el balanceo, proporcional, a rutas con métrica de hasta 2 veces el valor de la métrica de la mejor ruta, eso siempre cumplan la feasibility condition (FC).

Repasemos algunos conceptos. Feasible distance (FD) es la menor métrica al destino (mejor ruta). Una ruta cumple con feasibility condition (FC) si su advertised distance (AD) es menor a FD, o sea si el router que anuncia la ruta está efectivamente más cerca del destino que el router al cual se le anuncia la ruta, convirtiéndose entonces en un feasible successor. Lo anterior asegura un ruteo excento de loops como se demuestra en el paper original de DUAL, algoritmo base de EIGRP.

Para hacerlo más claro, en nuestro ejemplo FD es 158720. Cada feasible successor (o sea que aparecen en el show ip eigrp topology) muestra un par de valores entre paréntesis, los que representan; (métrica calculada localmente/AD). El setar variance a 2 permite tener en la tabla de ruteo, además de la mejor ruta a 1.1.1.1/32, otras cuya métrica sea de hasta 158720*2 = 317440, siempre y cuando su AD sea menor a 158720. Actualmente se tiene un feasible successor que cumple esto; métrica 181760. Lo haremos un poco más elocuente cambiando el parámetro bandwidth en la interface FastEthernet0/1 de P1R4 a 25Mbps, con esto la métrica pasará a 256*(400+610)=258560.

P1R4#conf t    
Enter configuration commands, one per line.  End with CNTL/Z.
P1R4(config)#int f0/1
P1R4(config-if)#bandwidth 25000

P1R4#sh ip rou 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "eigrp 1", distance 90, metric 158720, type internal
Redistributing via eigrp 1
Last update from 10.1.2.2 on FastEthernet0/0, 00:00:02 ago
Routing Descriptor Blocks:
* 10.1.3.3, from 10.1.3.3, 00:00:02 ago, via FastEthernet0/1
Route metric is 258560, traffic share count is 1
Total delay is 6100 microseconds, minimum bandwidth is 25000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
10.1.2.2, from 10.1.2.2, 00:00:02 ago, via FastEthernet0/0
Route metric is 158720, traffic share count is 2
Total delay is 5200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2

Es decir por cada tres paquetes, dos se deberían enviar por FastEthernet0/0 y uno por FastEthernet0/1. show ip cef internal nos revela el detalle de esto para nuestra ruta aprendida por BGP cuyo next hop es aprendido por EIGRP.

P1R4#sh ip cef 10.1.5.0 int
10.1.5.0/24, version 103, epoch 0, per-destination sharing
0 packets, 0 bytes
via 10.1.3.3, FastEthernet0/1, 0 dependencies
traffic share 1
next hop 10.1.3.3, FastEthernet0/1
valid adjacency
via 10.1.2.2, FastEthernet0/0, 0 dependencies
traffic share 2
next hop 10.1.2.2, FastEthernet0/0
valid adjacency

0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
     internal 0 packets, 0 bytes
Load distribution: 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 (refcount 1)

Hash  OK  Interface                 Address         Packets
1     Y   FastEthernet0/1           10.1.3.3              0
2     Y   FastEthernet0/0           10.1.2.2              0
3     Y   FastEthernet0/1           10.1.3.3              0
4     Y   FastEthernet0/0           10.1.2.2              0
5     Y   FastEthernet0/1           10.1.3.3              0
6     Y   FastEthernet0/0           10.1.2.2              0
7     Y   FastEthernet0/1           10.1.3.3              0
8     Y   FastEthernet0/0           10.1.2.2              0
9     Y   FastEthernet0/1           10.1.3.3              0
 10    Y   FastEthernet0/0           10.1.2.2              0
 11    Y   FastEthernet0/0           10.1.2.2              0
 12    Y   FastEthernet0/0           10.1.2.2              0
 13    Y   FastEthernet0/0           10.1.2.2              0
 14    Y   FastEthernet0/0           10.1.2.2              0
 15    Y   FastEthernet0/0           10.1.2.2              0
 16    Y   FastEthernet0/0           10.1.2.2              0

Se ve que que cada 16 paquetes, sólo 5 se enviarán por FastEthernet0/1.

Por último, un truco para balancear carga proporcional al ancho de banda de las interfaces, por ejemplo, utilizando sólo rutas estáticas es explicado por Ivan Pepelnjak en Unequal load split with static routes.