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 »

viernes, 5 de junio de 2009

BGP/MPLS IP VPNs II

Posted by Nicolas | viernes, 5 de junio de 2009 | Category: , , , , , | 1 comentarios

Corresponde ahora configurar los clientes. Cada CE será configurado por ahora con una ruta default al PE.


En los PEs se asociará las interfaces correspondientes a la VRF configurada.

PE1#sh run int f2/0
Building configuration...

Current configuration : 185 bytes
!
interface FastEthernet2/0
ip vrf forwarding Customer
ip address 10.0.0.1 255.255.255.252
speed auto
duplex auto
end

PE2#sh run int f2/0
Building configuration...

Current configuration : 185 bytes
!
interface FastEthernet2/0
ip vrf forwarding Customer
ip address 10.0.0.5 255.255.255.252
speed auto
duplex auto
end

Seguir leyendo »

martes, 2 de junio de 2009

BGP/MPLS IP VPNs I

Posted by Nicolas | martes, 2 de junio de 2009 | Category: , , , , | 1 comentarios

Dentro de los nuevos tópicos a incluir en la versión 4 del examen de R&S está MPLS (RFC 3031), en particular MPLS/VPN, descrito en el RFC 4364 (deja obsoleto 2547). Es por esto que a continuación se describirá el algunos conceptos básicos para el set-up de VPNs utilizando esta tecnología. Se utilizará la topología de la figura.

Primero que nada se setea el IGP de nuestra red, tomando en consideración que debemos insertar en la tabla de ruteo una dirección de host (/32) que identifique a cada equipo como se describe en el punto 5 (Forwarding) del RFC 4364. En nuestro caso se utilizará Integrated IS-IS usando la dirección de Loopback 0 seteada en cada equipo. A continuación la configuración relevante en uno de los PEs para lo señalado.

Seguir leyendo »

viernes, 22 de mayo de 2009

Números de Sistema Autónomo (ASN)

Posted by Nicolas | viernes, 22 de mayo de 2009 | Category: , , | 2 comentarios

En los ejemplos anteriores se utilizaron los números de Sistema Autónomo (ASN) 64512 y 65534 (el criterio para el uso y registros de éstos se define en el RFC 1930). Esto no es casualidad, ya que son el comienzo y final del rango de números de Sistema Autónomo para uso privado, que en total suman 1023. Lo anterior es similar a la definición del rango de direcciones IP privadas del RFC 1918 (Address Allocation for Private Internets).

El organismo que administra tanto las direcciones IP como los números de Sistema Autónomo es IANA. La distribución y asignación de números de Sistema Autónomo se puede ver en el siguiente link; http://www.iana.org/assignments/as-numbers/. Entre otras cosas se puede ver.

23456...............AS_TRANS
55296-64511.........Reserved by the IANA
64512-65534.........Designated for private use

El ASN 23456 es definido en el RFC 4893 (BGP Support for Four-octet AS Number Space), el cual introduce el uso de números de Sistema Autónomo de 4 bytes y quién mejor que Jeff Doyle para explicar su uso en Understanding 4-Byte Autonomous System Numbers.

El RFC 5396 define tres formas de representación textual para los números de Sistema Autónomo.
  • asplain: Usa notación decimal. El número de AS 65526 se representa con el string "65526", en tanto 65546 con "65546".
  • asdot+: El número de AS es dividido en dos valores unidos por un punto. 65526 es representado por "0.65526", en tanto 65546 por "1.10".
  • asdot: Números de AS menores a 65535 usan la notación asplain y aquellos mayores o igual 65536 usan la notación asdot+.
Esto se asemeja a la notación de las comunidades (RFC 1997) en BGP, que también constan de dos partes de 2 bytes cada una. Con el comando ip bgp-community new-format se pueden ver expresada de la forma AA:NN, de lo contrario será un numero único de 32 bits.

Por otra parte el RFC 5398 define dos bloques de 16 ASN contiguos para usar en documentación acerca de la transcición al uso de números de Sistema Autónomo de 4 bytes. Uno en el rango de los de 16 bits y otro en el de 32 bits; 64496-64511 y 65536-65551 respectivamente.

Por último Cisco señala que en las releases de IOS 12.0(32)S12, 12.4(24)T, Cisco IOS XE Release 2.3 y posteriores se representarán los ASN en notación asdot: BGP Autonomous System Number Formats.

jueves, 21 de mayo de 2009

BGP: Balanceo de carga II

Posted by Nicolas | jueves, 21 de mayo de 2009 | Category: , , | 0 comentarios

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.

Seguir leyendo »

miércoles, 20 de mayo de 2009

BGP: Balanceo de carga I

Posted by Nicolas | miércoles, 20 de mayo de 2009 | Category: , , | 1 comentarios

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.

Seguir leyendo »
Suscribirse a: Entradas (Atom)