miércoles, 10 de noviembre de 2010
En este post se repasarán distintos métodos para filtrar prefijos en OSPFv2 de una área a otra a nivel de los ABR (Area Border Router). Se utilizarán los siguinetes comandos; area range, area filter-list y distribute-list in.
La topología a utilizar en éste y los otros posts de OSPF filter se muestra en la siguiente figura:
1. Evitar la generación de LSA 3 en ABR de origen con area range.
En particular se puede ver cómo R5 inserta en su tabla de ruteo el prefijo 5.5.5.5/32 proveniente de un LSA tipo 3 (summary) generado por R2 (2.2.2.2) para esa área en particular.
R4#sh ip rou 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "ospf 1", distance 110, metric 5, type inter area
Last update from 192.0.2.1 on Serial0/0, 00:17:45 ago
Routing Descriptor Blocks:
* 192.0.2.1, from 2.2.2.2, 00:17:45 ago, via Serial0/0
Route metric is 5, traffic share count is 1
R4#sh ip ospf data sum 5.5.5.5
OSPF Router with ID (4.4.4.4) (Process ID 1)
Summary Net Link States (Area 24)
Routing Bit Set on this LSA
LS age: 1122
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 5.5.5.5 (summary Network Number)
Advertising Router: 2.2.2.2
LS Seq Number: 80000001
Checksum: 0x8E8E
Length: 28
Network Mask: /32
TOS: 0 Metric: 4
R4#
Si bien es R2 (2.2.2.2) quien genera el LSA tipo 3 para el área 24, cabe señalar que es R5 quien originalmente anuncia el prefijo dentro de un LSA 1 que tiene scope limitado al área local (15). Luego R1 genera un LSA-3 y finalmente R2 lo re-genera.
R5#sh ip ospf data self-originate
OSPF Router with ID (5.5.5.5) (Process ID 1)
Router Link States (Area 15)
Link ID ADV Router Age Seq# Checksum Link count
5.5.5.5 5.5.5.5 1177 0x8000000B 0x00B405 3
Una manera de filtrar la generación del LSA tipo 3 es por ejemplo sumarizar el prefijo en un ABR (R1 en esta caso) y especificar la opción not-advertise.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router ospf 1
R1(config-router)#area 15 range 5.5.5.5 255.255.255.255 not
R1(config-router)#
R4#sh ip rou 5.5.5.5
% Network not in table
2. Evitar la generación de LSA 3 con filter-list out.
En este caso se filtra a la salida del área 15.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip prefix-li no-lsa3 deny 5.5.5.5/32
R1(config)#ip prefix-li no-lsa3 permit 0.0.0.0/0 le 32
R1(config)#router ospf 1
R1(config-router)#area 15 filter-list prefix no-lsa3 out
R4#sh ip rou 5.5.5.5
% Network not in table
3. Evitar la re-generación de LSA 3 con filter-list in.
En este caso se filtra a la entrada del área 24.
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip prefix-li no-lsa3 deny 5.5.5.5/32
R2(config)#ip prefix-li no-lsa3 permit 0.0.0.0/0 le 32
R2(config)#router ospf 1
R2(config-router)#area 24 filter-list prefix no-lsa3 in
R2(config-router)#
R4#sh ip rou 5.5.5.5
% Network not in table
4. Filtrar ruta a partir de un LSA 3 con distribute-list in.
Mismo caso que el punto anterior, distinto comando.
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#ip prefix-li no-lsa3 deny 5.5.5.5/32
R4(config)#ip prefix-li no-lsa3 permit 0.0.0.0/0 le 32
R4(config)#router ospf 1
R4(config-router)#distribute-l pre no-lsa3 in
R4#sh ip rou 5.5.5.5
% Network not in table
Otro método puede ser a través de una ruta estática en el ABR con mejor distancia administrativa que el prefijo en cuestión. Narbik explica muy bien éste método en el siguiente video: http://www.micronicstraining.com/videos/filtering-ospf-prefixes-section-1.zip.
Link recomendado para entender esto en profundidad: OSPF Route Filtering Demystified.
martes, 26 de octubre de 2010
OSPF Filter; Intra Area con distribute-list
En los siguientes posts se repasarán distintos métodos para filtrar prefijos en OSPFv2, cada uno con propósitos y alcances distintos. Para comenzar se verán distintos usos del comando distribute-list in para filtrar prefijos dentro de una misma área. Se combinará con prefix-list, access-list, route-map (match ip address, match ip next-hop y match ip route-source)
La topología a utilizar en este y los siguientes posts se muestra en la siguiente figura:
1. Filtrar prefijo Intra Area de la tabla de routeo. Notar que sin embargo seguirá estando en la base de datos de OSPF.
R1#sh ip rou 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 192.0.2.194 on Serial0/0, 1d02h ago
Routing Descriptor Blocks:
* 192.0.2.194, from 5.5.5.5, 1d02h ago, via Serial0/0
Route metric is 2, traffic share count is 1
R1#sh ip ospf data | i ^5.5.5.5
5.5.5.5 1.1.1.1 175 0x80000031 0x0038BA
5.5.5.5 5.5.5.5 1724 0x80000047 0x003C41 3
R1#
Se puede ver R1 recibe el prefijo 5.5.5.5/32 de R5 que tiene router-ID 5.5.5.5. Ahora en R1 se configura para filtrar este prefijo, lo que resulta exitoso, sin embargo esto no tendrá efecto sobre la base de datos de OSPF por lo que R1 propagará la ruta al área 0.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip prefix-li no-prefix deny 5.5.5.5/32
R1(config)#ip prefix-li no-prefix permit 0.0.0.0/0 le 32
R1(config)#router ospf 1
R1(config-router)#distribute-list prefix no-prefix in
R1(config-router)#
R1#sh ip rou 5.5.5.5
% Network not in table
R1#sh ip ospf data | i ^5.5.5.
5.5.5.5 1.1.1.1 657 0x80000031 0x0038BA
5.5.5.5 5.5.5.5 201 0x80000048 0x003A42 3
R1#
2. Mismo caso pero con access-list en vez de prefix-list.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#access-list 1 deny 5.5.5.5 255.255.255.255
R1(config)#access-list 1 permit any
R1(config)#router ospf 1
R1(config-router)#distribute-list 1 in
R1#sh ip rou 5.5.5.5
% Network not in table
3. Mismo caso, pero especificando el prefijo y next-hop.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#access-list 1 permit 5.5.5.5
R1(config)#access-list 2 permit 192.0.2.194
R1(config)#
R1(config)#route-map prefix-nexthop deny
R1(config-route-map)# match ip address 1
R1(config-route-map)# match ip next-hop 2
R1(config-route-map)#route-map prefix-nexthop permit
R1(config-route-map)#
R1(config-route-map)#router ospf 1
R1(config-router)#distribute-list route-map prefix-nexthop in
R1(config-router)#^Z
R1#
R1#sh ip rou 5.5.5.5
% Network not in table
4. En vez del next-hop se especifica la fuente del prefijo.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config-router)#route-map prefix-nexthop deny
R1(config-route-map)#match ip address 1
R1(config-route-map)#match ip route-source 1
R1(config-route-map)#route-map prefix-nexthop permit
R1(config-route-map)#
R1(config-route-map)#router ospf 1
R1(config-router)#distribute-list route-map prefix-nexthop in
R1(config-router)#^Z
Un par de consideraciones:
- Si se incluye la interface en el comando distribute-list in, se considera ésta como interface de sailda para el next-hop y sólo la ruta en ese sentido será considerada.
- Altamente recomendado evitar este tipo de filtrado (Inter Area) ya que puede llevar a blackholing.
domingo, 8 de agosto de 2010
Se configurará IS-IS a dos routers interconectados como muestra la figura.
R5(config)#int f0/0
R5(config-if)#ip add 192.0.2.5 255.255.255.0
R5(config-if)#no shut
R5(config-if)#
R5(config-if)#router isis
R5(config-router)#net 49.0001.0050.0500.5005.00
R5(config-router)#int f0/0
R5(config-if)#ip router isis
R5(config-if)#
R6(config)#int f0/0
R6(config-if)#ip add 192.0.2.6 255.255.255.0
R6(config-if)#no shut
R6(config-if)#
R6(config-if)#router isis
R6(config-router)#net 49.0001.0060.0600.6006.00
R6(config-router)#int f0/0
R6(config-if)#ip router isis
R6(config-if)#
Luego si en R5 se revisan los adjacencias con show isis neighbors, se verá que en lugar de mostrar la representación de 6 bytes del System ID del router vecino, se muestra en vez -para nuestra comodidad- el hostname.
R5#sh isis nei
System Id Type Interface IP Address State Holdtime Circuit Id
R6 L1 Fa0/0 192.0.2.6 UP 7 R6.01
R6 L2 Fa0/0 192.0.2.6 UP 7 R6.01
R5#
Esto es gracias a que el RFC 2763 definió un nuevo TLV (Dynamic Hostname, type 137) que permite a los routers corriendo IS-IS conocer el hostname asociado a un system ID (Dynamic Hostname Exchange) que luego el RFC 5301 hizo parte del estándar del protocolo.
A continuación se repetirá este procedimiento para OSPF.
R5(config)#int f0/0
R5(config-if)#ip add 192.0.2.5 255.255.255.0
R5(config-if)#no shut
R5(config-if)#
R5(config-if)#router ospf 1
R5(config-router)#int f0/0
R5(config-if)#ip ospf 1 area 0
R5(config-if)#
R6(config)#int f0/0
R6(config-if)#ip add 192.0.2.6 255.255.255.0
R6(config-if)#no shut
R6(config-if)#
R6(config-if)#router ospf 1
R6(config-router)#int f0/0
R6(config-if)#ip ospf 1 area 0
R6(config-if)#
Sin embargo el resultado no es el mismo al ejecuar show ip ospf neighbor, se ve simplemente el router ID, que para este protocolo es de 4 bytes.
R5#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
192.0.2.6 1 FULL/BDR 00:00:37 192.0.2.6 FastEthernet0/0
R5#
Una manera de visualizar el hostname es configurando OSPF para que resuelva a través de DNS. Bueno, además se tendrá que configurar uno de los routers (R6) para que sea el DNS server en el ejemplo con ip dns server, además de configurar los mapeos name/IP con ip host. Por otro lado se le indicará a R5 con ip name-server que debe hacer las consultas de DNS a R6.
R6(config)#ip host R5 192.0.2.5
R6(config)#ip host R6 192.0.2.6
R6(config)#ip dns server
R5(config)#ip name-server 192.0.2.6
Por último se configura OSPF para que resuelva con ip ospf name-lookup. Los routers que no tengan configurado el mapeo de host/IP además necesitarán además configurado ip domain lookup.
R5(config)#ip ospf name-lookup
R5#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
R6 1 FULL/BDR 00:00:31 192.0.2.6 FastEthernet0/0
R5#
Por último añadir que dado que para OSPFv3, en implementaciones nativas de IPv6, el ID de 4 bytes asociado a cada router no será mapeado a direcciones IPv4 en esas redes, por lo que pierde sentido resolver por DNS. Es por eso que el RFC 5642 define un nuevo TLV (Dynamic Hostname) para utilizar en un Opaque LSA (Router Information, type 4), basado en lo definido previamente para IS-IS. Sin embargo aún no está implementado (hasta donde tengo entendido) en Cisco IOS.
miércoles, 4 de noviembre de 2009
Supongamos que se tiene un escenario como el de la figura con OSPF corriendo como protocolo de ruteo en la LAN.
En caso que uno de los routers pierda su conexión al switch, ¿Cuánto demorará el proceso de OSPF en los otros routers en declarar que ha perdido la vecindad?. Bueno, si se consideran los tiempos por defecto en links broadcast serían alrededor de 40 segundos, es decir el RouterDeadInterval que a su vez es equivalente al envío de cuatro hellos (HelloInterval de diez segundos) sin la correspondiente respuesta (estos valores para otros protocolos IGP son claramente enunciados en: Hello timer behaviors). Hoy en día este tiempo de convergencia puede ser perjudicial para redes de alta disponibilidad.
jueves, 3 de septiembre de 2009
Etiquetas IGP y VPN I
A modo de continuar con lo que se vio en BGP/MPLS IP VPNs I y BGP/MPLS IP VPNs II, se verá ahora el papel que cumplen LDP y BGP en el intercambio de las etiquetas MPLS. Se utilizarán fragmentos de la maqueta a continuación.
Como IGP se utilizará OSPF (área 0) y todos los equipos residirán en el sistema autónomo 64512. Cada equipo tendrá configurada una interface Loopback (0) con dirección IP X.X.X.X, con X el número de router.
Además cada equipo tendrá configurada la VRF RouterX, con RD (Route Distinguisher) X:X, RT (Route Target) import X:1 y con varios RT export de la forma Y:1 (dependiendo en cada caso como se verá más adelante). Por otra parte se configurará una interface Loopback (1) dentro de la VRF configurada con dirección IP 192.168.0.X.
