La RFC 2328 desarrolla OSPFv2.
La RFC 5340 lo desarrolla para IPv6.
El IP Protocol para que usa para el transporte es el 89.
Al ser un protocolo link state mantiene las 3 tablas:
La RFC 5340 lo desarrolla para IPv6.
El IP Protocol para que usa para el transporte es el 89.
Al ser un protocolo link state mantiene las 3 tablas:
- Neighbor
- Topology - llamada LSDB (Link State Database). Todos los equipos del área la comparten
- Routing
Usa el algoritmo Dijkstra para calcular la mejor ruta.
La métrica en OSPF prefiere siempre el coste menor. El coste
es: 108 /bandwidth
Para llegar de R1 a R7 el camino que tomará es el de
R3-R5-R6 porque aunque tenga más routers de por medio, OSPF suma el coste hasta
destino y ve que es menor.
Podemos manipular el coste de los enlaces para forzar que
vaya por un camino u otro con el siguiente comando.
(config-if)#ip ospf cost X
Cómo se
puede observar, FastEhternet, Giga Ethernet y 10 Giga Ethernet tienen asignado
el mismo coste por defecto, es decir, 1. Esto nos crea un problema porque consideraría
a los 3 enlaces con el mismo coste siendo claramente unos mejores que otros.
Con el siguiente comando, dentro del proceso OSPF, cambiamos la referencia del coste por defecto
y se asignan otros valores:
-
(config-router)#auto-cost
reference-bandwidth 1000
Las áreas administrativas
La
arquitectura de OSPF se basa en áreas. Cada una de ellas manda un tipo de LSA
donde viene la información del protocolo OSPF. Es una manera de jerarquizar y dar escabilidad a la red. Hay varios tipos:
-
Standard
-
Stub
-
Totally-Stub
-
Not-So-Stubby
-
Totally
Stubby Not-So-Stubby
Todos los equipos de un área comparten la misma topología. Si se produce un cambio dentro del área, se inunda (flooding) con LSA's y se ejecuta el algoritmo SPF, es decir, recalcula.
Podemos decir que OSPF jerarquiza en dos niveles globales:
- Area 0 o Backbone - sumariza pero las rutas deben ser contiguas. Para comunicarse entre las otras áreas, estas deben pasar obligatoriamente por el área 0.
- No Area Backbone - tiene que estar conectadas al área 0 obligatoriamente.
STUBBING EN DETALLE
Si tenemos una red muy grande, podemos sumarizar direcciones de la manera normal o podemos usar las áreas stub. En realidad hace lo mismo pero con LSA's. El ABR filtrará las tipo 3, 4 y 5 dependiendo del tipo de stub y generará una ruta por defecto 0.0.0.0/0.
Esta arquitectura que propone nos da la posibilidad de decirle a los routers que tipo de área y, por lo tanto, qué tipo de vecino tenemos. El equipo que está conectado directamente al área 0 (ABR) filtrará un tipo de rutas tanto para el área 0 como para los equipos del otro área:
- Standard: vemos todas
- Stub: vemos las O, las O IA y genera una default 0.0.0.0. No deja entrar rutas externas.
- Totally-Stub:
- Not-So-Stubby:
- Totally Stubby Not-So-Stubby: vemos las O, las externas y una default 0.0.0.0. El equipo conectado al backbone convierte los LSA tipo 7 a tipo 5 para permitirlas en el área 0
Para configurar las áreas, tenemos que configurarla dentro del proceso OSPF:
- Stub: area X stub - en todos los equipos de ese área
- Totally-Stub:
- Not-So-Stubby: area X nssa - en todos los equipos de ese área
- Totally Stubby Not-So-Stubby:
Tipos de Ruta en la Routing Table
O - Intra-Area - Tipo 1 y 2
I OA - Inter-Area - Tipo 3 y 4
E1 - Externa que cambia la métrica durante el camino - Tipo 5
E2 - Externa que no cambia la métrica durante el camino - Tipo 5
N1 - Externa que cambia la métrica durante el camino - Tipo 7
N2 - Externa que no cambia la métrica durante el camino - Tipo 7
El algoritmo SPF siempre preferirá una O a una I OA. La regla de preferencia entre los tipos de ruta es:
- O - I OA - E1 - E2 - N1 - N2
Tipos de LSA
LSA Tipo 1 - los generan todos los routers. No traspasa el propio área
LSA Tipo 2 - los generan solo los DR. No traspasa el propio área. Reducen el numero de adyacencias, por lo que simplifican el cálculo SPF.
LSA Tipo 3 - los genera el ABR desde el área 0 a otras áreas y viceversa. Describe cómo llegar a los enlaces de otras áreas. Incluye costes pero oculta la ruta final a destino que sí que sabe el propio ABR
LSA Tipo 4 - los genera el ABR desde la 0 a otras áreas y viceversa.
Describe cómo llegar a los ASBR que están en otras áreas. Incluye costes pero
oculta la ruta final a destino que sí que sabe el propio ABR.
Para los tipos 3 y 4, el algoritmo SPF no se ejecuta. Es decir, para calcular los costes lo que hace el ABR es sumar los costes independientes de cada área.
LSA Tipo 5 - las genera el ASBR. Las envía a todas las áreas non-stub. Describe las rutas redistribuidas: su métrica, que puede ser E1 o E2 (esta por defecto), la dirección ip y una etiqueta. Dependiendo del tipo de externa, la métrica se considera de una manera:
- E1: toma el coste del ASBR y el del resto del camino.
- E2: toma solo el coste del ASBR. Si hay varias rutas con el mismo coste, entonces si usa el resto del camino.
En OSPFv3 han introducido dos nuevas:
LSA Tipo 8 (Link) - usada para las "link Local Addresses"
LSA Tipo 9 (Intra Area Prefix) - usada para los direcciones de los enlaces.
Comandos show relativos a las áreas:
show ip ospf database - para ver todos las Áreas y los LSA
de esas áreas.
show ip ospf database router - para ver los LSA tipo 1
show ip ospf database network - para ver los LSA tipo 2
show ip ospf database summary - para ver los LSA tipo 3
Ospf
requiere una estructura jerárquica para evitar largos tiempos de convergencia si
tenemos muchos equipos en la misma área.
Todas las
áreas deben conectar al área 0.
Los equipos
que conectan dos áreas pueden ser:
- ABR (Area Border Router): conecta las áreas normales al backbone (área 0)
- ASBR (Autonomous System Boundary Router): conecta áreas fuera de OSPF
- Backbone Router: al menos tiene una interface conectada al backbone.
Dependiendo del rol que tenga el equipo (DR, ABR, ASBR), generará unos LSA u otros. Configuraremos en el laboratorio los distintos tipos de área
y veremos sus LSA's.
La formación de
vecindad (adjency)
Las relaciones de vecindad se forman con equipos de dentro de
la misma área.
Los equipos tienen un ROUTER ID que es el nombre del router
para el proceso OSPF. La interface con la dirección ip más alta será la elegida
como ROUTER ID. Siempre preferirá primero la configuración manual y, después, si no hemos configurado manualmente elegirá la IP más alta de una de las interfaces loopback y si no hay, finalmente escoge la IP más alta de las interfaces físiscas activas. Si añadimos una
dirección ip a una interface loopback y esta es más alta que la elegida por OSPF, este la cambiará pero se reseteará la vecindad. Cisco recomienda configurarlo manualmente y con una
loopback, así siempre mantendrá el mismo ROUTER ID. Para IPv6, en OSPFv3 también se usa una ip de 4 octetos para el ROUTER-ID.
(config-router)#
router –id X.X.X.X
Para formar la vecindad, escribimos el comando network para propagar OSPF por el interface del rango que hemos configurado y el área al que pertenece:
(config-router)#network X.X.X.X X.X.X.X area X
Si quisieramos aegurarnos de que una interface no envía updates y no formaría relaciones de vecindad, usamos:
config-router)#passive-interface X
(config-router)#network X.X.X.X X.X.X.X area X
Si quisieramos aegurarnos de que una interface no envía updates y no formaría relaciones de vecindad, usamos:
config-router)#passive-interface X
DR/BDR
En una estructura de OSPF en redes multiacceso, que no
son Point-To-Point, OSPF crea 3 roles de equipo:
Designated Router (DR): Principal
Backup Designated
Router (BDR): Backup
DRother: el
resto
Esta configuración nos permite no tener que conectar todos
con todos y ahorrar procesamiento en los equipos. Además, nos da una
organización jerárquica más clara para resolver posibles problemas. En
segmentos de redes ethernet quizás no sea relevante, pero en Frame Relay sí lo
es: el DR no puede ser cualquiera por cuestiones de arquitectura.
Los DRothers envían updates multicast solo al DR y al BDR
a la dirección 224.0.0.6. El DR contesta a todos los equipos con la 224.0.0.5. Por ejemplo, si un DRother pierde una red, en vez de mandar por multicast a todos, solo se lo comunica al DR y BDR a través de la 224.0.0.6 que son los únicos que contestan a esta dirección de multicast. Y luego, solo es el DR quien a través de la 224.0.0.5 se lo notifica a los demás.
En conexiones punto a punto hablan con la 224.0.0.5 también.
En IPv6 las direcciones son: FF02::5 y FF02::6
La elección de DR/BDR se basa en:
- Prioridad: de 0 a 255 (por defecto es 1 y gana la más alta)
- Router-ID: la dirección más alta de una interface activa
El DR es el encargado de enviar los updates. Si se cae el DR directamente se promociona al BDR. Y se elige otro BDR nuevo.
Para configurar el DR y el BDR hay que modificar la prioridad. Si le configuramos la prioridad a 0, directamente sacamos a ese equipo de la elección del DR y BDR.
El estado de OSPF en DR y BDR será siempre FULL.
El estado de los
DROTHERS en un entorno ethernet será:
- FULL: con el DR y el BDR
- 2-WAY: con los otros
DROTHERS.
Cuando se
forma la vecindad se dan 8 estados entre
los vecinos.
1. Down: no se reciben
“hello” desde el vecino
2. Attempt: solo
en redes NBMA cuando configuramos manualmente el vecino. Se ha enviado un hello unicast y no se recibe respuesta.
3. Init: se ha
enviado un hello (cuando configuramos el comando network se empiezan a mandar
los hello) y se espera la respuesta. Los hello se envían:
- Cada 10 segundos en redes broadcast o P2P
- Cada
30 segundos en redes NBMA
Estos tiempos se pueden modificar. El “dead time” es 4 veces
más de lo configurado. Si llega a ese tiempo (40 segundos en P2P, por ejemplo)
se cae la vecindad.
Contenido del paquete hello:
- Router
ID, Hello y Dead Time, Área, Prioridad, Vecinos, ip de DR y BDR, máscara y si
tiene autenticación, el password.
- Ambos
equipos deben tener los mimos valores.
Cuando un equipo recibe
un hello desde un vecino con la lista de vecinos y no se ve él mismo en esa lista, empieza el proceso
Init. Comprueba los valores del hello y, si coinciden, manda un “reply hello”.
Si todo es correcto, se procede al siguiente paso.
Si no pasa el chequeo, se
queda en estado Init, por lo que si vemos que un equipo pasa de
down-init-down-init y, probablemente sea una cuestión de valores.
4. 2-way: cuando
al intercambiar los “hello” , el router ve su ROUTER ID en el campo neighbor. Si la vecindad ya está formada, resetea el “dead time". También es el estado de los DROthers cuando forman vecindad entre ellos.
5. Exstart: aquí
se da la elección del DR y el BDR (master/slave). Se determina por la prioridad
o la ROUTER ID más alto.
6. Exchange: Una
vez elegido el DR manda un paquete DBD (su base de datos) y el BDR hace lo
mismo. En el DBD van los LSA (link State Advertisements).
7. Loading: se
carga la info recibida. Durante este proceso sucede lo siguiente:
- Slave pide detalles (LSR – Link State Request)
- Master pide detalles (LSR – Link State Request)
8. Full:
totalmente sincronizados. Ahora es cuando se ejecuta el algoritmo Disjkstra
para calcular la ruta más corta
Hay muchos atributos que tienen que coincidir:
- Área, hello y dead intervals
- Direcciones de red de las interfaces
- MTU
- Tipo de Red
- Autenticación y las "stub flags", para saber que tipo de área
- Instance ID para OSPFv3
- Otras adicionales
Tipos de paquetes OSPF
- Hello:
- DBD (Database description): es como un índice de la información con un número de secuencia que se usa para las retransmisiones y para los "ackownledgement"
- LSR (Link-State Request): pregunta por redes
- LSU (Link-State Update): Es como el sobre que lleva dentro los LSA
- LACK (Link-State Acknowledge): es la respuesta a todos los paquetes excepto para el
hello y el propio LACK. Esto hace de OSPF un protocolo confiable (reliable).
Podemos ver todos los LSA con el comando:
show ip ospf database - es como el sh ip eigrp topology
Para habilitar OSPF a nivel global. Tiene que haber al menos una interface activa:
Para habilitarlo a nivel de interface:
Para habilitar OSPF a nivel global. Tiene que haber al menos una interface activa:
- (config)#ip routing
- (config)#ipv6 unicast-routing (obviamente para IPv6)
- (config)#router ospf X - número de proceso que solo tiene significancia local
- (config)#router ospfv3 X
- (config-router)#network X.X.X.X X.X.X.X area X - red, wildcard mask y número de área
Para habilitarlo a nivel de interface:
- (config-if)#ip ospf X area X - número de proceso y número de área
- (config-if)#ipv6 ospf X area X - número de proceso y número de área
- (config-if)#ospfv3 X ipvX area X - número de proceso, address family (ipv4 o ipv6) y número de área. OSPFv3 mantiene bases de datos separadas para IPv4 e IPv6.
Para IPv6 solo hace falta habilitarlo a nivel de "link local".
Cuando habilitamos OSPF enlas interfaces, también se propagan las direcciones ip secundarias. Esto es por defecto pero podemos deshabilitarlo:
- (config-if)#ip ospf X area X secondaries none
Incluso si cambiamos la dirección ip de la interface, el proceso OSPF no se resetea.
Tabla de intervalos de envío de Hello y Dead Intervals
| Network Type | Hello Interval (secs) | Dead Interval (secs) |
| Point-to-Point | 10 | 40 |
| Point-to-Multipoint | 30 | 120 |
| Broadcast | 10 | 40 |
| Non-Broadcast | 30 | 120 |
El intervalo de hello se puede configurar más bajo para un convergencia más rápida. Esto puede aumentar el procesamiento del equipo. Para eso es mejor usar BFD.
Cada LSA lleva un coste del enlance. El más bajo será el elegido como mejor ruta.
Cuando el equipo recibe un LSA se compara con la base de datos:
- Hace un "checksum"
- Chequea el tipo de LSA
- Mira el número de secuencia (seq#) para ver si es nuevo o antiguo
- Mira el tiempo (age) para ver el tiempo que lleva
Nota: Cuando un cambio es detectado se genera un nuevo LSA y se envía por todos los enlaces. OSPF no usa split horizon. Cuando recibe un LSA donde ve que el mismo es el router que lo orgina, directamente lo descarta.
Virtual Links
Si tenemos una topología como la siguiente:
El área 2 rompe la regla de estar conectada al área 0. Este
problema lo solucionamos creando un virtual link. Crea una especie de túnel lógico. Los puntos finales deben ser alcanzables por las áreas estándar, es decir, no pueden estar en un área stub, ya que esta filtra LSA. Es la misma razón por la que en esos puntos no se deben filtrar LSA.
Otra cosa a tener en cuenta es que el coste de OSPF al montar el virtual link no puede ser mayor de 65535. Así que hay que tener cuidado si le aumentamos el ancho de banda de referencia de nuestro escenario OSPF.
- ABR(config-router)#area 1 virtual-link X.X.X.X – Router ID
- routerX(config-router)#area
1 virtual-link X.X.X.X – Router ID
Para comprobarlo:
- sh ip ospf virtual-links
Veremos las rutas
marcadas como “O IA”
Los virtual links funcionan bajo demanda. Para asegurarnos de que funcionan en un entorno de laboratorio, podemos hacer un clear ip ospf process y ver que levanta.
Gestión y modificación
de las rutas en OSPF
-
Filtros
Como OSPF no
envía rutas, sino que envía LSU's donde viene en esas rutas (LSA's) y, dentro del área
todos los equipos tienen que conocer todos los LSA para evitar bucles, no se
permite establecer filtros dentro del área. Solo se permite:
o
En
un ABR filtrar los LSA tipo 3
o
En
un ASBR filtrar los LSA tipo5
Para configurar un filtro podemos hacerlo de 2 maneras:
o
Filter-list: llamamos a un prefix-list que hemos creado donde vienen las rutas
que queremos filtrar.
(config-router)#area X filter-list X out/in
o
Distribute-list: aquí filtramos para que no entre
información en la “routing table”. También llama a un prefix-list o
access-list.
(config-router)#distribute-list X out/in Interface
-
Sumarización
Los únicos
equipos que pueden sumarizar son el ABR y el ASBR:
o
ABR:
area X range X.X.X.X mask [not-advertise]
o
ASBR:
summary-address X.X.X.X mask [not-advertise] [nssa-only]
Cuando configuramos nssa-only, el P-bit lo ponemos a 0. Con una analizador de tráfico como whireshark veremos en el LSA que pone NP. Esto es útil para escenario donde tenemos un red externa y queremos que los equipos de esa área, que es una nssa conozcan esa red externa pero el resto del escenario OSPF no. Es decir, los routers nssa no traducirán los LSA tipo 7 en tipo 5.
-
Ruta por defecto
En OSPF se
llama Default-Information Originate, Lo que hace es crear un LSA tipo 5 como
ruta por defecto.
(config-router)#default-information originate always
- Autenticación:
Podemos establecerla con texto plano o encriptada con md5, sha e ipsec, este último en la versión 3. Protege el Control Plane de ataques como el "routing injection". En la cabecera de cada paquete OSPF se incluye la información de autenticación. Autenticación no quire decir encriptación. En OSPFv2 el payload sigue en texto plano. Para OSPFv3, como tiene IPSEC, podemos encriptarlo.
En la cabecera podemos encontrar 3 tipos de autenticación:
Se establece por áreas y tenemos dos opciones: en la configuración del proceso y por interface:
La buena praxis es configurarla por interface:
Con texto plano:
(config-if)#ip ospf authentication
(config-if)#ip ospf authentication-key 1 xxxx
(config-if)#ospfv3 authentication null
Con MD5:
(config-if)#ip ospf authentication message-digest
(config-if)#ip ospf message-digest-key 1 md5 xxxx
(config-if)#ospfv3 encription ipsec spi X esp-aes cbc X X md5/sha
Nota: Si tenemos habilitado tanto a nivel global como a nivel de interface, se prefiere la de nivel interface.
Para OSPFv3 la autenticación es con IPSEC AH o con ESP.
Para OSPFv3 la encriptación es con IPSEC ESP. No usa ISAKMP.
Cisco recomienda utilizar el "service password-encryption" para proteger las contraseñas.
En una tipo broadcast como Ethernet, quizás no nos importe el equipo que cumple la función de DR, pero en HUB-SPOKE tenemos que asegurarnos de que el DR es el equipo HUB. En las de tipo broadcast se permite multicast y broadcast, por lo que los equipos se descubren solos y todos se ven con todos. En Ethernet, OSPF asigna automáticamente el tipo Broadcast.
En las de tipo Point-To-Point, usado para enlaces PPP, HDLC o para túneles GRE, se configuran como las ethernet. Habilitamos la interface, la ip y el network en OSPF. Descubre vecinos pero no hay elección de DR/BDR. Se envían los hellos a la 224.0.0.5. Se suelen configurar sobre subinterfaces.
Nota: Por cierto, si por ejemplo tenemos una loopback configurada con una /24, OSPF la propagará como si fuera una dirección con una máscara /32. Si queremos eliminar este comportamiento para que se propague con una /32, podemos usar esta opción:
(config)#interface loopback X
(config-if)#ip ospf network point-to-point
En las de tipo Non-Broadcast tenemos que configurar los vecinos manualmente. Los hello se mandan en unicast. Se elige DR/BDR, usan LSA tipo 2. La típica red Non-Broadcast son las Frame-Relay o las ATM. Tenemos varias arquitecturas para las redes de este tipo.
Configuramos la interface y en OSPF el network y neighbor:
POINT - TO - MULTIPOINT
Se pueden considerar un conjunto de enlaces point-to-pont. Envían hellos a la 224.0.0.5. No hay elección del DR/BDR. Muy usado para redes NMBA.
Aquí tenemos 3 opciones: broadcast, non-broadcast y interface multipoint.
Lo configuramos sobre subinterfaces y siempre con el atributo multipoint.
(config)#interface serial 1/0.10 multipoint
En Point-To-MultiPoint con broadcast, además:
(config)#interface serial 1/0.10 multipoint
(config-subif)#ip ospf network broadcast - en todos los equipos
(config-subif)#frame-relay map ip X.X.X.X DLCI broadcast - en todos los equipos
En Point-To-MultiPoint non-broadcast. NO envían hellos a la 224.0.0.5, por lo que es unicast y, por tanto, tenemos que configurar los vecinos. Una ventaja es que nos permite asignar coste por circuito:
(config)#interface serial 1/0.10 multipoint
(config-subif)#frame-relay map ip X.X.X.X DLCI broadcast - en todos los equipos
(config-router)# neighbor X.X.X.X - en los SPOKE
Y tenemos una tercera opción que es la Multipoint con Point-To-Point Network.
(config)#interface serial 1/0.10 multipoint
Ahora vamos a R2 y le cambiamos el tipo de red. Recordad, que al ser un interface ethernet, directamente le asigna el tipo de red broadcast.
Para cambiar el tipo de red:
Vemos que se cae la vecindad y vuelve a levantar. Podemos comprobar que el tipo de network para la interface f0/0 de R2 ha cambiado. Pero aún así, forma la vecindad con el router-id de la loopback y sin embargo, si chequeamos que rutas conocemos, la loopback del vecino no aparece. De hecho, si le hacemos un ping no se llega. Hay que estar atentos porque no nos propagará ninguna red.
Ejemplo de configuración en el LABORATORIO OSPF.
Podemos establecerla con texto plano o encriptada con md5, sha e ipsec, este último en la versión 3. Protege el Control Plane de ataques como el "routing injection". En la cabecera de cada paquete OSPF se incluye la información de autenticación. Autenticación no quire decir encriptación. En OSPFv2 el payload sigue en texto plano. Para OSPFv3, como tiene IPSEC, podemos encriptarlo.
En la cabecera podemos encontrar 3 tipos de autenticación:
- 0 - Null
- 1 - Texto plano
- 2 - md5/sha
Se establece por áreas y tenemos dos opciones: en la configuración del proceso y por interface:
- (config-router)#area 0 authentication message-digest - habilita todas las interfaces
La buena praxis es configurarla por interface:
Con texto plano:
(config-if)#ip ospf authentication
(config-if)#ip ospf authentication-key 1 xxxx
(config-if)#ospfv3 authentication null
Con MD5:
(config-if)#ip ospf authentication message-digest
(config-if)#ip ospf message-digest-key 1 md5 xxxx
(config-if)#ospfv3 encription ipsec spi X esp-aes cbc X X md5/sha
Nota: Si tenemos habilitado tanto a nivel global como a nivel de interface, se prefiere la de nivel interface.
Para OSPFv3 la autenticación es con IPSEC AH o con ESP.
Para OSPFv3 la encriptación es con IPSEC ESP. No usa ISAKMP.
Cisco recomienda utilizar el "service password-encryption" para proteger las contraseñas.
Tipos de redes OSPF
TIPO DE INTERFACE
|
USA DR/BDR?
|
DESCUBRE VECINOS
|
INTERVALO HELLO
|
Broadcast
|
SI
|
SI
|
10s
|
Point-To-Point
|
NO
|
SI
|
10s
|
Nonbroadcast
|
SI
|
NO
|
30s
|
Point-to-Multipoint
|
NO
|
SI
|
30s
|
Point-to-Multipoint
Nonbroadcast
|
NO
|
NO
|
30s
|
En una tipo broadcast como Ethernet, quizás no nos importe el equipo que cumple la función de DR, pero en HUB-SPOKE tenemos que asegurarnos de que el DR es el equipo HUB. En las de tipo broadcast se permite multicast y broadcast, por lo que los equipos se descubren solos y todos se ven con todos. En Ethernet, OSPF asigna automáticamente el tipo Broadcast.
 |
| Network Type BROADCAST en Interface Ethernet |
(config-subif)#ip ospf network broadcast
(config-subif)#ip ospf priority 1 – Prioridad 0 deja fuera a ese interface del proceso DR.
En las de tipo Point-To-Point, usado para enlaces PPP, HDLC o para túneles GRE, se configuran como las ethernet. Habilitamos la interface, la ip y el network en OSPF. Descubre vecinos pero no hay elección de DR/BDR. Se envían los hellos a la 224.0.0.5. Se suelen configurar sobre subinterfaces.
(config)#interface serial 1/1.0 point-to-point
Nota: Por cierto, si por ejemplo tenemos una loopback configurada con una /24, OSPF la propagará como si fuera una dirección con una máscara /32. Si queremos eliminar este comportamiento para que se propague con una /32, podemos usar esta opción:
(config)#interface loopback X
(config-if)#ip ospf network point-to-point
En las de tipo Non-Broadcast tenemos que configurar los vecinos manualmente. Los hello se mandan en unicast. Se elige DR/BDR, usan LSA tipo 2. La típica red Non-Broadcast son las Frame-Relay o las ATM. Tenemos varias arquitecturas para las redes de este tipo.
Configuramos la interface y en OSPF el network y neighbor:
(config-subif)#ip ospf network non-broadcast
(config-subif)#frame-relay map ip X.X.X.X DLCI broadcast - en todos los equipos
(config-router)#network X.X.X.X X.X.X.X area X
(config-subif)#frame-relay map ip X.X.X.X DLCI broadcast - en todos los equipos
(config-router)#network X.X.X.X X.X.X.X area X
(config-router)#neighbor X.X.X.X
POINT - TO - MULTIPOINT
Se pueden considerar un conjunto de enlaces point-to-pont. Envían hellos a la 224.0.0.5. No hay elección del DR/BDR. Muy usado para redes NMBA.
Aquí tenemos 3 opciones: broadcast, non-broadcast y interface multipoint.
Lo configuramos sobre subinterfaces y siempre con el atributo multipoint.
(config)#interface serial 1/0.10 multipoint
En Point-To-MultiPoint con broadcast, además:
(config)#interface serial 1/0.10 multipoint
(config-subif)#ip ospf network broadcast - en todos los equipos
(config-subif)#frame-relay map ip X.X.X.X DLCI broadcast - en todos los equipos
En Point-To-MultiPoint non-broadcast. NO envían hellos a la 224.0.0.5, por lo que es unicast y, por tanto, tenemos que configurar los vecinos. Una ventaja es que nos permite asignar coste por circuito:
(config)#interface serial 1/0.10 multipoint
(config-subif)#frame-relay map ip X.X.X.X DLCI broadcast - en todos los equipos
(config-router)# neighbor X.X.X.X - en los SPOKE
Y tenemos una tercera opción que es la Multipoint con Point-To-Point Network.
(config)#interface serial 1/0.10 multipoint
(config-subif)#ip ospf network point-to-multipoint
(config-subif)#frame-relay map ip X.X.X.X DLCI broadcast - en todos los equipos
(config-subif)#frame-relay map ip X.X.X.X DLCI broadcast - en todos los equipos
En todas ellas tendremos que mapear los DLCI si estamos en una red Frame-Relay
(config-subif)#frame-relay map ip 172.16.70.12 412 broadcast
(config-subif)#frame-relay map ip 172.16.70.12 412 broadcast
Para
la compatibilidad entre ellas, podemos decir los tipos de redes que
usan LSA de tipo 2 pueden formar adyacencias entre ellas aunque en cada
equipo esté configurado con un tipo. Y al revés igual, si no usan LSA
tipo 2 pueden formar adyacencia:
Un ejemplo de la confusión que nos pueden crear los tipos de redes en OSPF.
Tenemos dos routers enfrentados y conectados por Ethernet, y cada uno con un loopback para propagar por OSPF.
Configuramos OSPF básico:
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 0
router-id 192.168.1.X - la x sustituirla por 1 o 2 dependiendo del router que sea
Vemos que se forman las adyacencias. El vecino es el router-id que hemos configurado y también podemos ver que se propagan las loopback. Todo correcto.
- Broadcast y Non-Broadcast pueden formar adyacencia porque generan tipo 2
- Point-to-Point, Point-to-Multipoint, Point-to-Multipoint NonBroadcast pueden formar adyacencia porque no generan LSA tipo 2
Un ejemplo de la confusión que nos pueden crear los tipos de redes en OSPF.
Tenemos dos routers enfrentados y conectados por Ethernet, y cada uno con un loopback para propagar por OSPF.
Configuramos OSPF básico:
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 0
router-id 192.168.1.X - la x sustituirla por 1 o 2 dependiendo del router que sea
Vemos que se forman las adyacencias. El vecino es el router-id que hemos configurado y también podemos ver que se propagan las loopback. Todo correcto.
 |
| En R2 tenemos lo mismo con las direcciones ip de R1 |
 |
| En R1 es lo mismo |
- R2(config-if)#ip ospf network point-to-point
Ejemplo de configuración en el LABORATORIO OSPF.
Algunos comandos útiles:
show ip ospf
show ospfv3
show ip ospf interface
show ospfv3 interface
show ospfv3
show ip ospf interface
show ospfv3 interface
show ip ospf database
show ospfv3 database
show ospfv3 database
show ip ospf neighbors
show ospfv3 neighbors
show ospfv3 neighbors
debug ip ospf adj
debug ospfv3 adj
clear ip ospf process
debug ospfv3 adj
clear ip ospf process
No hay comentarios:
Publicar un comentario