miércoles, 20 de mayo de 2009

BGP: Balanceo de carga I

Posted by Nicolas | miércoles, 20 de mayo de 2009 | Category: , , |

Se examinarán dos formas para balancear tráfico usando BGP (colección de RFC de este protocolo), teniendo en consideración que que el balanceo está constituido por dos entes totalmente independientes: tráfico de entrada y salida. En este post se verá una (multipath) y en el siguiente la otra.

Cisco describe cómo funciona el balanceo de carga en el documento; How Does Load Balancing Work?. En esta ocasión sólo se verá balanceo para caminos con igual costo. Para el detalle de cómo se puede hacer lo mismo para caminos con distinto costo (en EIGRP y BGP), referirse al excelente artículo; Understanding Unequal-Cost Load-Balancing.

En primera instancia se trabajará sobre la red de la figura.


Primero que nada se debe asegurar perfecta simetría en el ruteo (se utilizará EIGRP para la conectividad), lo cual no es cierto debido al enlace Ethernet entre P1R3 y P1R4. Para eso veamos desde P1R4 cómo se la Loopback de P1R1.

P1R4#sh ip eigrp 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 (412160/156160), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 6100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
P1R4#

Para igualar en métrica, basta modificar los parámetros bandwidth y delay en la interface FastEthernet0/1 de P1R4. Ojo que estos parámetros son meramente informativos, ya que la interface seguirá operando a 10 Mbps (eso se modifica con speed para interfaces LAN). Por consistencia se hará lo propio del lado de P1R3.

P1R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
P1R4(config)#interface FastEthernet0/1
P1R4(config-if)#band 100000
P1R4(config-if)#delay 10
P1R4(config-if)#end
P1R4#
*Apr 13 02:24:28.675: %SYS-5-CONFIG_I: Configured from console by vty0 (10.1.2.2)
P1R4#clear ip eigrp nei
P1R4#sh ip eigrp 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, 2 Successor(s), FD is 158720
Routing Descriptor Blocks:
10.1.3.3 (FastEthernet0/1), from 10.1.3.3, 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.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
P1R4#

Una vez asegurada la simetría de la red necesaria para nuestros propósitos, se procede a configurar las sesiones BGP.

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 2.2.2.2 remote-as 64512
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 64512
neighbor 3.3.3.3 ebgp-multihop 2
neighbor 3.3.3.3 update-source Loopback0
no auto-summary
!

P1R3#sh run | b router bgp
router bgp 64512
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 64512
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 remote-as 65534
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
!

P1R2#sh run | b router bgp
router bgp 64512
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 64512
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 remote-as 65534
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
no auto-summary
!

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 2.2.2.2 remote-as 64512
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 64512
neighbor 3.3.3.3 update-source Loopback0
no auto-summary
!

En particular se han creado sesiones iBGP y eBGP como detalla la figura, desabilitando la sincronización con IGP (no synchronization) y la sumarización automática (no auto-summary). En cada router se han agregado un par de redes para anunciar (network) y se han utilizado las direcciónes de loopback para formar las vecindades (por defecto se ocupa la dirección de la interface de salida, por ende se debe especificar lo anterior con update-source, de otra forma los paquetes no podrán ser interpretados correctamente en cada lado de la vecindad). Además se ha aumentado el número de saltos permitidos para las sesiones eBGP (ebgp-multihop), dado que por default sólo permite un salto de distancia, i.e. TTL seteado a 1.

P1R4#sh ip bgp nei 3.3.3.3 | i hops
External BGP neighbor may be up to 2 hops away.
P1R4#

Veamos cómo BGP sabe de la red 10.1.5.0/24 directamente conectada a P1R1.

P1R4#sh ip bgp 10.1.5.0
BGP routing table entry for 10.1.5.0/24, version 14
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
3.3.3.3
64512
3.3.3.3 (metric 156160) from 3.3.3.3 (3.3.3.3)
Origin IGP, localpref 100, valid, external
64512
2.2.2.2 (metric 156160) from 2.2.2.2 (2.2.2.2)
Origin IGP, localpref 100, valid, external, best
P1R4#

P1R4 actualmente selecciona el anuncio (promesa de ruteo) que nos hace P1R2. ¿Por qué?; Bien, si revisamos los atributos de ambos anuncios de acuerdo a BGP Best Path Selection Algorithm (o mejor aún, la imagen que creó Richard Bannister en BGP Path Selection), nos daremos cuenta que lo que rompe el empate en este caso es la antiguedad del anuncio (se comprueba reseteando la sesión contra P1R2, notando que el anuncio que queda como Best corresponde al de P1R3).

P1R4#
*Apr 13 03:29:14.827: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Down User reset
P1R4#sh ip bgp 10.1.5.0
BGP routing table entry for 10.1.5.0/24, version 17
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
2.2.2.2
64512
2.2.2.2 (metric 156160) from 2.2.2.2 (2.2.2.2)
Origin IGP, localpref 100, valid, external
64512
3.3.3.3 (metric 156160) from 3.3.3.3 (3.3.3.3)
Origin IGP, localpref 100, valid, external, best
P1R4#

Por default BGP sólo permite pasar 1 anuncio a la tabla de ruteo, cosa que puede ser modificada con el comando maximum-paths.

P1R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
P1R4(config)#router bgp 65534
P1R4(config-router)#maximum-paths 2
P1R4(config-router)#^Z
P1R4#
*Apr 13 03:47:57.351: %SYS-5-CONFIG_I: Configured from console by vty0 (10.1.2.2)
P1R4#sh ip bgp 10.1.5.0
BGP routing table entry for 10.1.5.0/24, version 22
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Multipath: eBGP
Flag: 0x800
Advertised to non peer-group peers:
3.3.3.3
64512
2.2.2.2 (metric 156160) from 2.2.2.2 (2.2.2.2)
Origin IGP, localpref 100, valid, external, multipath, best
64512
3.3.3.3 (metric 156160) from 3.3.3.3 (3.3.3.3)
Origin IGP, localpref 100, valid, external, multipath

Pues bien, ahora aparece la palabra multipath, lo que es un buen indicio, de hecho si se ve la tabla de ruteo.

P1R4#sh ip rou 10.1.5.0
Routing entry for 10.1.5.0/24
Known via "bgp 65534", distance 20, metric 0
Tag 64512, type external
Last update from 3.3.3.3 00:01:55 ago
Routing Descriptor Blocks:
* 2.2.2.2, from 2.2.2.2, 00:01:55 ago
Route metric is 0, traffic share count is 1
AS Hops 1
3.3.3.3, from 3.3.3.3, 00:01:55 ago
Route metric is 0, traffic share count is 1
AS Hops 1

Efectivamete se balanceará el tráfico. ¿Cómo?; Per-destination o Per-packet, dependiendo del método de switcheo de paquetes. Por defecto en la mayoría de los routers Cisco está habilitado fast switching. Por su parte process switching equivale a deshabilitar lo anterior realizando el balanceo por cada paquete, lo que implica que cada uno de éstos debe ser procesado por la CPU. Fast switching permite que la CPU sólo procese el primer paquete para cada destino. Ojo que esto es válido para los paquetes que ingresen por una interface configurada para estos efectos.

Los distintos modos de switcheo de paquetes se describe en: How to Choose the Best Router Switching Path for Your Network.

Pese a que no es requisito, se recomienta configurar CEF (por defecto en la mayoría de los routers Cisco) para un balanceo más eficiente como describe Ivan Pepelnjak en EBGP multipath load sharing and CEF. Por otro lado se pueden obtener interesantes outputs con el detalle de cómo se hara el forward de los paquetes ;)

P1R4#sh ip cef 10.1.5.0 internal
10.1.5.0/24, version 49, epoch 0, per-destination sharing
0 packets, 0 bytes
via 2.2.2.2, 0 dependencies, recursive
traffic share 1
next hop 10.1.2.2, FastEthernet0/0 via 2.2.2.2/32
valid adjacency
via 3.3.3.3, 0 dependencies, recursive
traffic share 1
next hop 10.1.3.3, FastEthernet0/1 via 3.3.3.3/32
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 0 1 0 1 0 1 (refcount 1)

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

En total 1 comentarios:

  1. Muy bueno el docu.

    Gracias


Leave a Reply