Mostrando entradas con la etiqueta BGP. Mostrar todas las entradas
Mostrando entradas con la etiqueta BGP. Mostrar todas las entradas

martes, 13 de abril de 2010

Doble NAT?

Posted by Nicolas | martes, 13 de abril de 2010 | Category: , , , , , , , | 0 comentarios

Primero que nada agradecer a Narbik Kocharians y Dan Shechter por el excelente concurso de Troubleshooting que realizaron hace unas semanas (Troubleshooting Challenge lab)... Gracias a éste gané una copia de sus workbooks Advanced Routing and Switching 2.0 WB y Troubleshooting WB :) ...Ahora a trabajar en ellos para alcanzar la meta!

Bueno, uno de los Tickets que me tuvo de cabeza por un buen rato fue el número 9. Enunciaba lo siguiente:

Ticket 9
R6 can NOT ping 24.24.24.3.
You should fix this problem without configuring BGP or any redistribution.

La topología completa se puede ver en; Topología, IGP y BGP. Para la referencia de este post se utilizará la siguiente imagen:

Básicamente R5 y R1 tienen una sesión iBGP, sin embargo no es posible alcanzar los prefijos que R1 le anuncia a R5, puesto que R4 no tiene información de cómo rutear estos destinos.

Desde R5 se puede ver se reciben 6 prefijos desde R1 (136.85.1.1).

R5#sh ip bgp sum | b Neighbor
Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
136.85.1.1      4         15   21600   21447       12    0    0 2w0d            6
136.85.56.6     4          6   21452   21453       12    0    0 2w0d            0
R5#

Si en particular se revisa el prefijo 24.24.24.3/32 se verá que se conoce a través de R1 con next-hop 136.85.241.24, el que R1 resolverá recursivamente para determinar que la interface de salida es F0/0...hasta ahí, todo bien.

R5#sh ip bgp 24.24.24.3
BGP routing table entry for 24.24.24.3/32, version 11
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
 1
24
136.85.241.24 (metric 66) from 136.85.1.1 (136.85.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R5#

R5#sh ip cef 24.24.24.3
24.24.24.3/32
nexthop 136.85.45.44 FastEthernet0/0
R5#

Sin embargo cuando se intenta hacer ping al destino se obtiene un mensaje ICMP que señala que el host es desconocido (Type 3, Code 1).

R5#ping 24.24.24.3 r 2

Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 24.24.24.3, timeout is 2 seconds:
U.
Success rate is 0 percent (0/2)

R5#

Para los que no saben el por qué se ve U.U.U en vez de UUUUU se recomienda leer: Dissecting a U.U.U ping response.

Siguiente paso sería verifican quién origina los mensajes de destino no alcanzable.

*Apr 13 17:52:49.241: IP: s=136.85.45.5 (local), d=24.24.24.3 (FastEthernet0/0), len 100, sending
*Apr 13 17:52:49.241:     ICMP type=8, code=0
---snip---
*Apr 13 17:52:49.245: IP: s=136.85.45.44 (FastEthernet0/0), d=136.85.45.5, len 56, input feature
*Apr 13 17:52:49.245:     ICMP type=3, code=1

Como era de esperar, R4 (136.85.45.44) no sabe cómo rutear los paquetes con destino a 24.24.24.3.

R4#sh ip rou 24.24.24.3
% Network not in table
R4#

¿Qué se puede hacer en este caso?. Bueno, la respuesta enunciada en Challenge lab - Solution, sugiere que se levante LDP entre R5<>R4 y R4<>R1, lo cual por supuesto funciona.

R5#sh ip cef 24.24.24.3
24.24.24.3/32
nexthop 136.85.45.44 FastEthernet0/0 label 16
R5#

R5#ping 24.24.24.3 r 2

Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 24.24.24.24, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 56/58/60 ms
R5#


Sin embargo esto no pasó por mi mente en ese momento, si no una solución alternativa que sin embargo no es óptima puesto que sólo corrige el problema para este prefijo en particular, pero de todos modos resuelve el inconveniente enunciado y se explicará a continuación, de manera de mostrar cómo se puede usar NAT de manera extravagante. Para detalles respecto a esta tecnología se sugiere revisar alguno o todos los siguientes links:
De vuelta al Ticket en cuestión, lo que se hizo fue utilizar NAT tanto en R4 como R1. La configuración aplicada fue:

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#int FastEthernet0/0
R4(config-if)#ip nat out
R4(config-if)#
R4(config-if)#int Serial1/0.14                
R4(config-subif)#ip nat in
R4(config-subif)#
R4(config-subif)#ip nat inside source static 136.85.134.3 24.24.24.3
R4(config)#

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int Serial1/0.14          
R1(config-subif)#ip nat out
R1(config-subif)#int f0/0
R1(config-if)#ip nat in
R1(config-if)#ip nat inside source static 24.24.24.3 136.85.134.3
R1(config)#


Esto corresponde a lo que se muestra en la siguiente figura:


Entonces cuando R5 (y por ende R6 como se solicita originalmente en el Ticket) envía un paquete destinado a 24.24.24.3 llegará a la interface F0/0 de R4. Ahí se aprovechará que el proceso de NAT outside to inside se realiza previo a la decisión de ruteo según se especifica en NAT Order of Operation, entonces 24.24.24.3 se transformará en 136.85.134.3. R4 sabe cómo rutear paquetes destinados a esta dirección y por lo tanto serán enviados a través de su interface Serial1/0.14 con destino R1 (DLCI 401).

R4#sh ip rou 136.85.134.3
Routing entry for 136.85.134.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Serial1/0.14
Route metric is 0, traffic share count is 1

R4#

R4#sh frame map interface Serial1/0.14
Serial1/0.14 (up): point-to-point dlci, dlci 401(0x191,0x6410), broadcast
status defined, active
R4#

Una vez en R1, se repite el proceso de NAT para hacer la conversión inversa. Esta vez se cambia 136.85.134.3 por 24.24.24.3 por ende R1 rutea los paquetes con el destino original de 24.24.24.3 y R1 sí sabe cómo alcanzar ese host. Luego el host sólo tiene que responder los mensajes ICMP al origen de los paquetes, cuya dirección no fue modificada durante el trayecto.

R5#ping 24.24.24.3 r 2

Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 24.24.24.3, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 56/58/60 ms
R5

:)

lunes, 8 de febrero de 2010

BGP Best Path

Posted by Nicolas | lunes, 8 de febrero de 2010 | Category: , | 2 comentarios

Uno de los links más recurrentes por aquellos que están aprendiendo el funcionamiento de BGP es: BGP Best Path Selection Algorithm. Éste se puede resumir en que un determinado path en la tabla BGP será preferido sobre otro basado en alguno de sus atributos que son revisados en el siguiente orden hasta lograr el desempate:

  1. WEIGHT: Sólo equipos Cisco.
  2. LOCAL PREFERENCE: Mayor valor es preferido y es local al número de Sistema Autónomo.
  3. Se preferirán aquellos originados localmente (comandos network/redistribute/aggregate-address)
  4. AS PATH: El más corto es preferido.
  5. ORIGIN: Se prefiere IGP sobre EGP y éste último es preferido sobre INCOMPLETE (?). Ojo!, IGP no tiene nada que ver con OSPF , EIGRP, etc. en este caso y no creeránlo antiguo que es EGP.
  6. MED: También conocido como metric. Menor valor es preferido.
  7. eBGP sobre iBGP paths. De existir un desempate, se pasa al paso 9.
  8. Menor métrica IGP al next hop.
  9. Chequea si Multipath está activo.
  10. Si ambos paths son externos, preferir el que fue recibido primero (si es que bgp bestpath compare-routerid no está activo).
  11. Menor router ID.
  12. Menor longitud de cluster list (escenarios con Route Reflectors).
  13. Menor dirección IP del neighbor.
A continuación se analizará cómo modificar la configuración de BGP para preferir distintos path sin necesidad de modificar sus atributos y en qué caso se considera Multipath. Los ejemplos estarán basados en el escenario de la figura (hacer click en ella para ver con más detalle):


Se supondrá que por cualquiera sean las razones, siempre se aprenderán los prefijos en el siguiente orden; primero desde R2, luego R3, R4 y finalmente desde R1. Dado que la línea de comandos (CLI) muestra los prefijos (paths) en el orden inverso del que fueron aprendidos inicialmente se tendrá lo siguiente:

R6#sh ip bgp 10.0.0.0
BGP routing table entry for 10.0.0.0/8, version 2
Paths: (4 available, best #4, table Default-IP-Routing-Table)
 Advertised to update-groups:
       1    2
 64777 64999 65222
   192.0.2.1 from 192.0.2.1 (192.0.2.1)
     Origin IGP, localpref 100, valid, external
 64555 65222
   192.0.2.4 from 192.0.2.4 (192.0.2.4)
     Origin IGP, localpref 100, valid, external
 64888 65222
   192.0.2.3 from 192.0.2.3 (192.0.2.3)
     Origin IGP, localpref 100, valid, external
  64555 65222
    192.0.2.2 from 192.0.2.2 (192.0.2.2)
      Origin IGP, localpref 100, valid, external, best

Es importante destacar que la comparación de prefijos se efectúa de arriba hacia abajo, o sea de manera inversa a cómo fueron aprendidos.

Se puede ver que se prefiere el prefijo de más abajo, el desempate se logra debido a que R2 anuncia 10.0.0.0/8 primero que el resto de los vecinos. El path por R1 se descarta por su longuitud de tres números de sistema autónomo al ser comparado con el path por R4. Éste último se descarta en compararción contra el aprendido por R3 por la antiguedad del anuncio en la tabla de BGP. Cabe destacar que no se compara MED de paths provenientes de distintos sistemas autónomos a no ser que así sea especificado como se verá más adelante. Finalmente el path por R2 es preferido por sobre el de R3 también por una cosa de tiempo. Interesante resulta que el óden en que son comparados los prefijos es FUNDAMENTAL, puesto que de haber sido comparado el path de R2 contra el de R4, el path que resulta ahora como mejor opción hubiese sido descartado por MED.

1. Ignorar el AS PATH y comparar el router ID previo a revisar antiguedad del prefijo (path).

R6#
R6#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R6(config)#router bgp 65111          
R6(config-router)#bgp bestpath as-path ignore
R6(config-router)#bgp bestpath compare-routerid
R6(config-router)#end
R6#

Lugeo de realizar los respectivos clear en el orden mencionado al comienzo se obtiene:

R6#sh ip bgp 10.0.0.0
BGP routing table entry for 10.0.0.0/8, version 111
Paths: (4 available, best #1, table Default-IP-Routing-Table)
Flag: 0x10820
 Advertised to update-groups:
       2
  64777 64999 65222
    192.0.2.1 from 192.0.2.1 (192.0.2.1)
      Origin IGP, metric 200, localpref 100, valid, external, best
 64888 65222
   192.0.2.3 from 192.0.2.3 (192.0.2.3)
     Origin IGP, localpref 100, valid, external
 64555 65222
   192.0.2.4 from 192.0.2.4 (192.0.2.4)
     Origin IGP, localpref 100, valid, external
 64555 65222
   192.0.2.2 from 192.0.2.2 (192.0.2.2)
     Origin IGP, metric 100, localpref 100, valid, external
R6#

Primero que nada se ha ignorado la longuitud del AS PATH con bgp bestpath as-path ignore, que en todo caso debería haber determinado el path por R2 como el preferido puesto que es el más antiguo, sin embargo bgp bestpath compare-routerid ha sobrepuesto esta comparación permitiendo el resultado observado (R1 tiene el menor Router ID).

2. Comparar MED incluso si provienen de distintos Sistemas Autónomo.

R6#
R6#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R6(config)#router bgp 65111
R6(config-router)#bgp always-compare-med
R6(config-router)#

Luego de realizar los respectivos clear en el orden mencionado al comienzo se obtiene:

R6#sh ip bgp 10.0.0.0   
BGP routing table entry for 10.0.0.0/8, version 9
Paths: (4 available, best #2, table Default-IP-Routing-Table)
Flag: 0x10800
 Advertised to update-groups:
       1    2
 64777 64999 65222
   192.0.2.1 from 192.0.2.1 (192.0.2.1)
     Origin IGP, metric 200, localpref 100, valid, external
  64555 65222
    192.0.2.4 from 192.0.2.4 (192.0.2.4)
      Origin IGP, localpref 100, valid, external, best
 64888 65222
   192.0.2.3 from 192.0.2.3 (192.0.2.3)
     Origin IGP, metric 100, localpref 100, valid, external
 64555 65222
   192.0.2.2 from 192.0.2.2 (192.0.2.2)
     Origin IGP, metric 100, localpref 100, valid, external
R6#

Se puede apreciar bgp always-compare-med fuerza se comparen valores de MED para prefijos aprendidos de distintos sistemas autónomo. Si bien el path por R2 no muestra ningún valor de MED (metric) es simplemente por que no se le ha asignado ninguno y por defecto toma el valor de 0, por ende se convierte en el path más conveniente en ese sentido. Para variar esto se puede utilizar bgp bestpath med missing-as-worst como se verá a continuación.

R6#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R6(config)#router bgp 65111
R6(config-router)#bgp bestpath med missing-as-worst
R6(config-router)#

R6#sh ip bgp 10.0.0.0   
BGP routing table entry for 10.0.0.0/8, version 11
Paths: (4 available, best #4, table Default-IP-Routing-Table)
Flag: 0x10820
 Advertised to update-groups:
       1    2
 64777 64999 65222
   192.0.2.1 from 192.0.2.1 (192.0.2.1)
     Origin IGP, metric 200, localpref 100, valid, external
 64555 65222
   192.0.2.4 from 192.0.2.4 (192.0.2.4)
     Origin IGP, metric 4294967295, localpref 100, valid, external
 64888 65222
   192.0.2.3 from 192.0.2.3 (192.0.2.3)
     Origin IGP, metric 100, localpref 100, valid, external
  64555 65222
    192.0.2.2 from 192.0.2.2 (192.0.2.2)
      Origin IGP, metric 100, localpref 100, valid, external, best
R6#

O sea, el valor por defecto asignado en caso que MED no sea setado manualmente es infinito (desde la perspectiva del router => 4294967295).

3. Agrupar prefijos por Sistema Autónomo.

R6#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R6(config)#router bgp 65111        
R6(config-router)#no bgp bestpath med missing-as-worst
R6(config-router)#bgp deterministic-med
R6(config-router)#

R6#sh ip bgp 10.0.0.0
BGP routing table entry for 10.0.0.0/8, version 14
Paths: (4 available, best #3, table Default-IP-Routing-Table)
Flag: 0x10800
 Advertised to update-groups:
       1    2
 64777 64999 65222
   192.0.2.1 from 192.0.2.1 (192.0.2.1)
     Origin IGP, metric 200, localpref 100, valid, external
 64888 65222
   192.0.2.3 from 192.0.2.3 (192.0.2.3)
     Origin IGP, metric 100, localpref 100, valid, external
  64555 65222
    192.0.2.4 from 192.0.2.4 (192.0.2.4)
      Origin IGP, localpref 100, valid, external, best
 64555 65222
   192.0.2.2 from 192.0.2.2 (192.0.2.2)
     Origin IGP, metric 100, localpref 100, valid, external
R6#

En este caso, bgp deterministic-med agrupará los paths aprendidos de un mismo sistema autónomo, por ende el mejor representante de este grupo será comparado con los paths aprendidos de otros sistemas autónomo. Los prefijos en este caso no son desplegados en relación exacta a cuándo fueron aprendidos, si no más bien considerando que aquellos provenientes de un mismo sistema autónomo deben estar uno al lado del otro. Se evita suceda lo que se vió en el caso inicial, escogiendo efectivamente en esta oportunidad el path con mejores atributos.

4. Involucrando ORIGIN.

En este caso sí se moficará un atributo de los paths en cuestión. Originalmente el prefijo 10.0.0.0/8 es generado en R7 con el comando network, por ende su ORIGIN es IGP. Se cambiará a INCOMPLETE (?) al insertar el prefijo con el comando redistribute.

R7#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R7(config)#
R7(config)#ip prefix-list CONNECTED permit 10.0.0.0/8
R7(config)#
R7(config)#route-map REDISTRIBUTE
R7(config-route-map)#
R7(config-route-map)#match ip address prefix-list CONNECTED
R7(config-route-map)#
R7(config-route-map)#router bgp 65222             
R7(config-router)#no network 10.0.0.0
R7(config-router)#redistribute connected route-map REDISTRIBUTE
R7(config-router)#^Z
R7#
R7#clear ip bgp *

R6#sh ip bgp 10.0.0.0
BGP routing table entry for 10.0.0.0/8, version 75
Paths: (4 available, best #3, table Default-IP-Routing-Table)
Flag: 0x10820
 Advertised to update-groups:
       2
 64777 64999 65222
   192.0.2.1 from 192.0.2.1 (192.0.2.1)
     Origin incomplete, metric 200, localpref 100, valid, external
 64888 65222
   192.0.2.3 from 192.0.2.3 (192.0.2.3)
     Origin incomplete, metric 100, localpref 100, valid, external
  64555 65222
    192.0.2.4 from 192.0.2.4 (192.0.2.4)
      Origin incomplete, localpref 100, valid, external, best
 64555 65222
   192.0.2.2 from 192.0.2.2 (192.0.2.2)
     Origin incomplete, metric 100, localpref 100, valid, external
R6#

Como se ve todas las entradas muestran ORIGIN incomplete (además que aún no se ha desactivado bgp deterministic-med). En R4 se modificará el valor de ORIGIN para que así R6 seleccione el path por R4.

R4# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#route-map SET-ORIGIN
R4(config-route-map)#set origin IGP
R4(config-route-map)#router bgp 64555
R4(config-router)#neighbor 192.0.2.6 route-map SET-ORIGIN out
R4(config-router)#end
R4#

R6#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R6(config)#router bgp 65111
R6(config-router)#no bgp deterministic-med
R6(config-router)#end
R6#

R6#sh ip bgp 10.0.0.0
BGP routing table entry for 10.0.0.0/8, version 79
Paths: (4 available, best #2, table Default-IP-Routing-Table)
Flag: 0x10820
 Advertised to update-groups:
       1
 64777 64999 65222
   192.0.2.1 from 192.0.2.1 (192.0.2.1)
     Origin incomplete, metric 200, localpref 100, valid, external
  64555 65222
    192.0.2.4 from 192.0.2.4 (192.0.2.4)
      Origin IGP, localpref 100, valid, external, best
 64888 65222
   192.0.2.3 from 192.0.2.3 (192.0.2.3)
     Origin incomplete, metric 100, localpref 100, valid, external
 64555 65222
   192.0.2.2 from 192.0.2.2 (192.0.2.2)
     Origin incomplete, metric 100, localpref 100, valid, external
R6#

5. Igualando dos prefijos => ¿Multipath?

Se modificará ORIGIN en R3 y no se tocará MED para así los paths a través de R3 y R4 puedan ser considerados iguales para así considerar dos paths como preferidos (Multipath).

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#route-map SET-ORIGIN
R3(config-route-map)#set origin IGP
R3(config-route-map)#
R3(config-route-map)#do sh run | i neighbor 192.0.2.6 route-map
neighbor 192.0.2.6 route-map SET-MED out
R3(config-route-map)#
R3(config-route-map)#router bgp 64888
R3(config-router)#neighbor 192.0.2.6 route-map SET-ORIGIN out 
R3(config-router)#
R3(config-router)#do sh run | i neighbor 192.0.2.6 route-map
neighbor 192.0.2.6 route-map SET-ORIGIN out
R3(config-router)#
R3(config-router)#end
R3#

Se configura Multipath.

R6#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R6(config)#router bgp 65111
R6(config-router)#maximum-paths 2
R6(config-router)#end
R6#

Revisando no pareciera haber funcionado. Se está escogiendo sólo un path (a través de R3)

R6#sh ip bgp 10.0.0.0
BGP routing table entry for 10.0.0.0/8, version 80
Paths: (4 available, best #3, table Default-IP-Routing-Table)
Multipath: eBGP
Flag: 0x820
 Advertised to update-groups:
       1    2
 64777 64999 65222
   192.0.2.1 from 192.0.2.1 (192.0.2.1)
     Origin incomplete, metric 200, localpref 100, valid, external
 64555 65222
   192.0.2.4 from 192.0.2.4 (192.0.2.4)
     Origin IGP, localpref 100, valid, external
  64888 65222
    192.0.2.3 from 192.0.2.3 (192.0.2.3)
      Origin IGP, localpref 100, valid, external, best
 64555 65222
   192.0.2.2 from 192.0.2.2 (192.0.2.2)
     Origin incomplete, metric 100, localpref 100, valid, external
R6#

El truco acá es que si bien pareciera que ambos paths tienen iguales atributos, existe uno que difiere; AS PATH.... Hmmmmm...pero no es sólo su longitud lo que interesa, ah?. Sucede que Cisco IOS seleccionará dos prefijos como best path sí y sólo sí sus AS PATH's son idénticos. Esto por cierto puede ser modificado con un comando oculto; bgp bestpath as-path multipath-relax.

R6#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R6(config)#router bgp 65111
R6(config-router)#
R6(config-router)#bgp bestpath ?
compare-routerid  Compare router-id for identical EBGP paths
cost-community    cost community
med               MED attribute

R6(config-router)#bgp bestpath as-path multipath-relax
R6(config-router)#

R6#sh ip bgp 10.0.0.0
BGP routing table entry for 10.0.0.0/8, version 84
Paths: (4 available, best #3, table Default-IP-Routing-Table)
Multipath: eBGP
Flag: 0x1820
 Advertised to update-groups:
       1    2
 64777 64999 65222
   192.0.2.1 from 192.0.2.1 (192.0.2.1)
     Origin incomplete, metric 200, localpref 100, valid, external
 64555 65222
    192.0.2.4 from 192.0.2.4 (192.0.2.4)
      Origin IGP, localpref 100, valid, external, multipath
 64888 65222
    192.0.2.3 from 192.0.2.3 (192.0.2.3)
      Origin IGP, localpref 100, valid, external, multipath, best
 64555 65222
   192.0.2.2 from 192.0.2.2 (192.0.2.2)
     Origin incomplete, metric 100, localpref 100, valid, external
R6#

:)

martes, 8 de diciembre de 2009

ORF: Outbound Route Filtering

Posted by Nicolas | martes, 8 de diciembre de 2009 | Category: , , | 2 comentarios

Es muy común que un cliente de un ISP no quiera recibir la tabla completa de prefijos a través de BGP, la cuál ya sobrepasó las 300.000 entradas (Active BGP entries), seguramente por que algunas compañías NO hacen muy bien su labor de agregación de rutas (Aggregation Summary).

En fin, una simple forma es que el proveedor anuncie todas las rutas y el cliente filtre en su CPE. Sin embargo esto implica se esté haciendo uso de recursos que no son necesarios. Para esto existe ORF (RFC 5291) que permite el CPE le indique a su uplink router qué prefijos quiere recibir y así se evite éste anuncie prefixos no deseados para que luego sean filtrados, ahorrando recursos en ambos equipos. Se mostrará esto en acción con los dos routers de la figura.

Seguir leyendo »

miércoles, 4 de noviembre de 2009

BFD y Fast Hellos

Posted by Nicolas | miércoles, 4 de noviembre de 2009 | Category: , , | 0 comentarios

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.

Seguir leyendo »

jueves, 3 de septiembre de 2009

Etiquetas IGP y VPN I

Posted by Nicolas | jueves, 3 de septiembre de 2009 | Category: , , , , , | 0 comentarios

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.

Seguir leyendo »
Suscribirse a: Entradas (Atom)