Mike on the Wire

Hace unos días me encontré con la necesidad de balancear el tráfico de salida de un Sistema Autónomo. Este AS hacía peering con otro mediante 2 enlaces, uno de mayor capacidad que el otro.

Con esta casuística, se planteaba un problema ya que no se puede hacer un balanceo “puro y duro” (multipath) ya que en caso de que hubiese una tasa de tráfico importante, perfectamente podría ocurrir que el enlace menor se saturase, mientras el enlace con mayor caudal seguiría “tranquilo”. Si esto ocurriese, parte del tráfico tendría problemas de saturación y so no es muy recomendable…

La única solución (elegante) es hacer un balanceo de carga proporcional al ancho de banda de los enlaces hacia nuestro Upstream Provider.

Para ver un ejemplo práctico, utilizaremos la siguiente topología:

• Tenemos 2 AS – 65534 y 65535, ambos de rango privado
• Nuestro AS y el que nosotros controlaremos será el 65534
• El objetivo es balancear el tráfico que pase por AS2R1 originado por PC2 hacia el AS 65535, entre los 2 enlaces que tienen AS2R2 y AS2R3 de una manera proporcional a su ancho de banda
• Dentro de cada sistema autónomo correrá iBGP y PC1 y PC2 accederán tendrán como GW por defecto AS1R6 y AS2R1 respectivamente
• Teniendo en cuenta que solamente tenemos capacidad administrativa del AS 65534, solamente se mostrarán las configuraciones de este AS

Y ahora…

¿Cómo le indicamos a AS2R1 que tiene que usar 2 caminos distintos para llegar a las rutas de AS 65535 pero teniendo en cuenta (y actuando en consecuencia) de que son enlaces con distintos ancho de banda ?

La solución nos la da una Extended Community de BGP llamada “Link Bandwidth” o “BGP DMZlink”. Esta es una “community no-transitiva” fuera de nuestro AS, luego se quedará dentro de nuestro AS, entre nuestros vecinos iBGP, que es lo que nos interesa.

¿ Pero como anunciamos ese valor a AS2R1 ? A continuación se muestra la configuración de la parte BGP de AS2R2 y AS2R3.

AS2R2:
router bgp 65534
no synchronization
bgp log-neighbor-changes
bgp dmzlink-bw
network 10.200.2.0 mask 255.255.255.252
network 172.24.0.0 mask 255.255.255.252
neighbor 10.200.2.1 remote-as 65534
neighbor 10.200.2.1 description AS2R1
neighbor 10.200.2.1 next-hop-self
neighbor 10.200.2.1 send-community both
neighbor 172.24.0.1 remote-as 65535
neighbor 172.24.0.1 description AS1R4
neighbor 172.24.0.1 dmzlink-bw
no auto-summary

interface Serial1/0
bandwidth 25000
ip address 172.24.0.2 255.255.255.252
serial restart-delay 0
no cdp enable
end

—————————————

AS2R3:
router bgp 65534
no synchronization
bgp log-neighbor-changes
bgp dmzlink-bw
network 10.200.2.4 mask 255.255.255.252
network 172.24.0.4 mask 255.255.255.252
neighbor 10.200.2.5 remote-as 65534
neighbor 10.200.2.5 description AS2R1
neighbor 10.200.2.5 next-hop-self
neighbor 10.200.2.5 send-community both
neighbor 172.24.0.5 remote-as 65535
neighbor 172.24.0.5 description AS1R5
neighbor 172.24.0.5 dmzlink-bw
no auto-summary

interface FastEthernet0/0
bandwidth 100000
ip address 172.24.0.6 255.255.255.252
duplex auto
speed auto
no cdp enable
end

—————————————

• bgp dmzlink-bw: Habilitamos la feature BGP DMZLink
• neighbor x.y.z.w send-community both: mandamos las communities standar y extended al vecino (solamente con las extended valdría)
• neighbor x.y.z.w dmzlink-bw: Se propagará el valor de DMZ Link Bandwitdth, calculado a partir del ancho de banda configurado en la interfaz que se use para llegar al neighbor x.y.z.w
• Configuramos el bandwidth adecuado en las interfaces que nos dan salida de nuestro AS. Serial 1/0 en el caso de AS2R2 y Fa 0/0 en el caso de AS2R3

Ya solo quedaría configurar el router interno AS2R1.

AS2R1:
router bgp 65534
no synchronization
bgp log-neighbor-changes
bgp dmzlink-bw
network 10.200.2.0 mask 255.255.255.252
network 10.200.2.4 mask 255.255.255.252
network 192.168.2.0
neighbor 10.200.2.2 remote-as 65534
neighbor 10.200.2.2 description AS2R2
neighbor 10.200.2.6 remote-as 65534
neighbor 10.200.2.6 description AS2R3
maximum-paths ibgp 2
no auto-summary

• bgp dmzlink-bw: Habilitamos BGP DMZlink para “hacer caso” a las extended communities anunciadas por AS2R2 y AS2R3
• maximum-paths ibgp 2: Habilitamos el multipathing para que se metan 2 gateways como máximo para un mismo destino (1 por efecto)

Verificación

Analizamos la tabla de enrutamiento y CEF de AS2R1 con respecto a la red 192.168.1.0/24 que es una red del AS 65535.

AS2R1#sh ip route 192.168.1.0
Routing entry for 192.168.1.0/24
Known via "bgp 65534", distance 200, metric 0
Tag 65535, type internal
Last update from 10.200.2.6 00:36:01 ago
Routing Descriptor Blocks:
10.200.2.6, from 10.200.2.6, 00:36:01 ago
Route metric is 0, traffic share count is 4
AS Hops 1
Route tag 65535
* 10.200.2.2, from 10.200.2.2, 00:36:01 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65535

—————————————

AS2R1#sh ip cef 192.168.1.0
192.168.1.0/24, version 52, epoch 0, per-destination sharing
0 packets, 0 bytes
via 10.200.2.6, 0 dependencies, recursive
traffic share 4
next hop 10.200.2.6, FastEthernet1/0 via 10.200.2.6/32
valid adjacency
via 10.200.2.2, 0 dependencies, recursive
traffic share 1
next hop 10.200.2.2, FastEthernet0/0 via 10.200.2.2/32
valid adjacency
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes

—————————————

Tal y como podemos observar, tanto en la tabla de enrutamiento como en la tabla CEF, existe un “traffic share” de 1-4. Esto quiere decir que de 5 paquetes (depende el algoritmo de load balancing aplicado), 4 irán por un sitio y el quinto por otro y volver a empezar, 4-1 4-1… Si os fijais, el ancho de banda configurado en la interfaz Serial 1/0 es 4 veces menor que la de la Fa 0/0. Hace justo lo que se queríamos, un balance de carga proporcional al ancho de banda!

Veamos que cuenta la database de BGP sobre la red 192.168.1.0

AS2R1#sh ip bgp 192.168.1.0
BGP routing table entry for 192.168.1.0/24, version 42
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Multipath: iBGP
Not advertised to any peer
65535
10.200.2.2 from 10.200.2.2 (172.24.0.2)
Origin IGP, metric 0, localpref 100, valid, internal, multipath, best
DMZ-Link Bw 3125 kbytes
65535
10.200.2.6 from 10.200.2.6 (172.24.0.6)
Origin IGP, metric 0, localpref 100, valid, internal, multipath
DMZ-Link Bw 12500 kbytes

Podemos ver que tenemos el valor “DMZ-Link Bw” especificado en Kbytes, es el valor que hayamos puesto con el comando “bandwidth” dividido entre 8.

• 100000 kbit / 8 = 12500 Kbytes
• 25000 kbit / 8 = 3125 Kbytes

Y finalmente la prueba mágica, ping desde PC2 a PC1 con un “record route” para ver el camino del paquete ICMP.

PC2#ping
Protocol [ip]:
Target IP address: 192.168.1.100
Repeat count [5]: 10
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]: 5
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 192.168.1.100, timeout is 2 seconds:
Packet has IP options: Total option bytes= 23, padded length=24
Record route: <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)

Reply to request 0 (40 ms). Received packet has options
Total option bytes= 24, padded length=24
Record route:
(192.168.2.100)
(10.200.2.1)        *1
(172.24.0.6)
(10.200.1.6)
(192.168.1.1)
<*>
End of list

Success rate is 100 percent (10/10), round-trip min/avg/max = 8/26/56 ms


Como podemos ver en el output del comando, el primer paquete va a través del router 10.200.2.1 (irá por la Serial) y los siguientes 4 por 10.200.2.5 (Fa 0/0) y vuelta a empezar. It works!

Happy BGP-ing!!