A continuación se mostrarán el funcionamiento de uRPF (RFC 3704), el cual Cisco describe en
Understanding Unicast Reverse Path Forwarding y su configuración es detallada en Configuring Unicast Reverse Path Forwarding.

Este mecanismo corresponde a una sencilla herramienta de seguridad que chequea el origen de los paquetes IP, permitiendo descartarlos si por ejemplo el origen no es visible a nivel de la tabla de ruteo por la interface por donde se recibió el paquete, protegiendo la red de ataques que son fácilmente generables como describe Jeremy Stretch en Using uRPF at the access layer to deter DDoS attacks. Otra buena lectura es el RFC 2827; Defeating Denial of Service Attacks which employ IP Source Address Spoofing.

Se utilizará la maqueta de la figura considerando que en primera instancia el link entre R4-R5 estará configurado con la subnet 10.0.0.8/30 para luego pasar a 172.16.0.8/30. Se utilizará EIGRP como protocolo de ruteo.

A continuación se configurará una topología Hub and Spoke sobre Frame-Relay. Sólo se configurará lo estrictamente necesario, para más detalles referirse a: Frame Relay Configuration Task List.


Como protocolo de ruteo se utilizará EIGRP.

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.

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.

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.