Routing and other considerations 1.

Objetivo: Desarrollar un escenario donde se produzca el error de OSPF %OSPF-4-FLOOD_WAR y confirmar la causa que lo genera.

Escenario propuesto:

El escenario cumple con las siguientes condiciones:

– Inicialmente el existía el enlace entre R2 y R3 mediante la subnet 10.0.0.4/30. El router R3 tiene configuradas dos interfaces loopbacks con las ip 10.0.0.1 y 10.0.0.2.
– Se decidió montar un nuevo enlace con el router R1 y por equivocación se brindo la subnet 10.0.0.0/30 al proveedor de servicios. En R2 se utilizó la ip 10.0.0.1 y en R1 la ip 10.0.0.1, ambas ya existentes en el router R3 cómo las direcciones IP de las loopback.
– Vecindad OSPF en todos los routers dentro de la misma area.

Configuración:

R2
!
interface FastEthernet1/0
ip address 10.0.0.1 255.255.255.252
!
interface FastEthernet1/1
ip address 10.0.0.5 255.255.255.252
!
router ospf 1
router-id 1.1.1.1
network 10.0.0.0 0.255.255.255 area 0
!

R1
!
interface FastEthernet1/0
ip address 10.0.0.2 255.255.255.252
!
interface FastEthernet1/1
ip address 10.0.2.254 255.255.255.0
!
router ospf 1
router-id 3.3.3.3
network 10.0.0.0 0.255.255.255 area 0
!

R3
!
interface FastEthernet1/0
ip address 10.0.0.6 255.255.255.252
!
interface FastEthernet1/1
ip address 10.0.1.254 255.255.255.0
!
router ospf 1
router-id 2.2.2.2
network 10.0.0.0 0.255.255.255 area 0
!

1st Problem:

El router principal (R2) presenta la siguiente tabla de rutas:

sm200#sh ip route
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
C        10.0.0.0/30 is directly connected, FastEthernet1/0
L        10.0.0.1/32 is directly connected, FastEthernet1/0
O        10.0.0.2/32 [110/2] via 10.0.0.6, 00:22:55, FastEthernet1/1
C        10.0.0.4/30 is directly connected, FastEthernet1/1
L        10.0.0.5/32 is directly connected, FastEthernet1/1
O        10.0.1.0/24 [110/2] via 10.0.0.6, 00:22:55, FastEthernet1/1
O        10.0.2.0/24 [110/2] via 10.0.0.2, 00:21:39, FastEthernet1/0

En este router, la primera ruta señalada corresponde a la directamente conectada, o sea, a la subnet configurada en la interfaz fast1/0. La segunda ruta señalada es una ruta local, que se crea cómo una subnet /32 para las direcciones ip de cada interfaz activa. La tercera ruta señalada señala el error cometido. En este caso, se aprende una ruta específica /32 para la loopback 1 del router R1. Cuando se trata de dar ping a la ip 10.0.0.2, que debería salir por la subnet directamente conectada (10.0.0.0/30, si no se hubiera cometido un error en el direccionado), resulta que se va por la ruta más específica.

Esto se puede ver con un tracert:

sm200#traceroute 10.0.0.2
Type escape sequence to abort.
Tracing the route to 10.0.0.2
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.0.6 28 msec 48 msec 44 msec
Además, se origina el error flood-war en R3:

*Nov 15 14:08:46.571: %OSPF-4-FLOOD_WAR: Process 1 flushes LSA ID 10.0.0.1 type-2 adv-rtr 1.1.1.1 in area 0

Esto se debe a que R2, es el root en el enlace entre R2-R1, por lo que genera un lsa type 2 con id 10.0.0.1, cuando este se lo anuncia a R3, y este ya tiene una interfaz loopback 1 que coincide con el lsa id.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s