CCIE en Español

World IPv6 Launch

2012-01-17T20:21:00.002-03:00

Se ha hecho anuncio del World IPv6 Launch para el 6 de junio de este año. Esta vez no sólo se habilitará el protocolo por un día como sucedió en el World IPv6 Day, si no que esta vez será para siempre en varios websites famosos como Facebook, Google, etc. y en los productos y servicios de grandes ISP's como Comcast, AT&T, etc. y por supuesto en productores de equipamiento como Cisco.

Más info en: http://blogs.cisco.com/news/launching-a-new-internet-protocol/.

Libro: IPv6 para Todos

2012-01-04T12:55:00.001-03:00

ISOC Argentina, en cooperación con el proyecto 6DEPLOY, ha publicado un nuevo libro de IPv6 "IPv6 para Todos: Guía de uso y aplicación para diferentes entornos".

Está orientado a diferentes tipos de lectores, incluyendo usuarios finales, redes residenciales, empresas, redes académicas y de investigación, así como a ISPs. También incluye un capítulo acerca de como desplegar diversos servicios IPv6.

El libro puede ser descargado en Castellano, Catalán, Vasco, Gallego e Inglés.

IPv6 Knowledge Base Portal

2011-12-06T19:23:00.001-03:00

Cisco lanzó recientemente IPv6 Knowledge Base Portal: http://www.cisco.com/web/solutions/netsys/ipv6/knowledgebase/index.html. Acá se pueden encontrar links a un sinnúmero de guías de configuración, white papers, etc. al respecto. Conviene darse una vuelta para aprender un poco ;)

OSPFv3

2011-08-08T17:21:00.012-04:00

A continuación un ejemplo básico de configuración de OSPFv3, con la particularidad que un vecino estará corriendo IOS XR. La topología es sencilla y se muestra en la siguiente figura:

Primero se configura el direccionamiento IPv6 en las interfaces que interconectan a R1 y R2.

RP/0/1/CPU0:R1#conf t
RP/0/1/CPU0:R1(config)#int Gi0/0/0/1
RP/0/1/CPU0:R1(config-if)#ipv6 add 2001:db8:1212::1/48
RP/0/1/CPU0:R1(config-if)#commit

R2#conf t
R2(config)#interface GigabitEthernet1/0/0
R2(config-if)#ipv6 add 2001:db8:1212::2/48

Se verifica conectividad básica.

RP/0/1/CPU0:R1(config-if)#do ping 2001:db8:1212::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:db8:1212::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/23/87 ms

Luego se configura direccionamiento IPv6 en las Loopbacks.

RP/0/1/CPU0:R1(config)#int lo0
RP/0/1/CPU0:R1(config-if)#ipv6 add 2001:db8:1111:1111::1/128
RP/0/1/CPU0:R1(config-if)#commit

R2(config)#int lo0
R2(config-if)#ipv6 add 2001:db8:2222:2222::2/128

Posteriormente se configura el proceso 1 de OSPFv3 y ambos routers en el área 0.

RP/0/1/CPU0:R1(config)#router ospfv3 1
RP/0/1/CPU0:R1(config-ospfv3)#area 0
RP/0/1/CPU0:R1(config-ospfv3-ar)#int Gi0/0/0/1
RP/0/1/CPU0:R1(config-ospfv3-ar-if)#commit

R2(config)#ipv6 uni
R2(config)#interface GigabitEthernet1/0/0
R2(config-if)#ipv6 ospf 1 a 0

Se verifica la vecindad se haya establecido.

RP/0/1/CPU0:R1#sh ospfv3 neighbor

Neighbors for OSPFv3 1

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2         1     FULL/DR         00:00:39    17              GigabitEthernet0/0/0/1
Neighbor is up for 00:00:38

Total neighbor count: 1
RP/0/1/CPU0:R1#

Se agregan las Loopbacks al proceso de OSPFv3.

RP/0/1/CPU0:R1#sh run int lo0

interface Loopback0
ipv4 address 1.1.1.1 255.255.255.255
ipv6 address 2001:db8:1111:1111::1/128

R2#sh run int lo0

interface Loopback0
ip address 2.2.2.2 255.255.255.255
ipv6 address 2001:DB8:2222:2222::2/128

RP/0/1/CPU0:R1#conf t
RP/0/1/CPU0:R1(config)#router ospfv3 1
RP/0/1/CPU0:R1(config-ospfv3)#area 0
RP/0/1/CPU0:R1(config-ospfv3-ar)#int lo0
RP/0/1/CPU0:R1(config-ospfv3-ar-if)#commit

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int lo0
R2(config-if)#ipv6 ospf 1 area 0

Se verifica la tabla de ruteo.

RP/0/1/CPU0:R1#sh route ipv6

Gateway of last resort is not set

L    2001:db8:1111:1111::1/128 is directly connected,
      00:12:10, Loopback0
C    2001:db8:1212::/48 is directly connected,
      00:05:22, GigabitEthernet0/0/0/1
L    2001:db8:1212::1/128 is directly connected,
      00:05:22, GigabitEthernet0/0/0/1
O    2001:db8:2222:2222::2/128
      [110/1] via fe80::21e:f7ff:fef7:5340, 00:00:14, GigabitEthernet0/0/0/1

...y por último conectividad entre las Loopbacks.

R2#ping 2001:db8:1111:1111::1 sou lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:1111:1111::1, timeout is 2 seconds:

Packet sent with a source address of 2001:DB8:2222:2222::2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/14/64 ms

PASS (english)

2011-08-01T18:16:00.005-04:00

Wow…It has been a very long, long journey… I started studying for the CCIE® some time after getting my CCNA/CCNP/CCIP combo more than two years ago on the v3 days. I followed the blueprint and I realized that it wasn’t detailed enough, so I went with the extended version of it. Initially with the unofficial (Thanks Anthony), which latter turned out to be quite similar to the official they posted afterwards. I keep track until these days of my progress on the different topics/sections.

So I started reading a bunch of books while doing some mini labs I would create to prove the concepts. At that time I only had one old PC which could barely run 3-4 routers simultaneously on GNS3. I noted that some of the new things I was learning were rapidly vanishing from my mind, so I decided to take notes regularly, save config examples, etc. and then this blog was born, which would force me to write notes as clear as possible that I could review afterwards. Unfortunately writing posts with a decent format consumes a lot of time so I couldn’t really post everything, but I will now try to blog more regularly to share some of my findings along the way..

After some time I managed to get a mix of 2600’s and 2800’s and a single 2950 that would let me build larger topologies. Narbik came up with this amazing Troubleshooting Challenge which got me a couple of workbooks to work with. I was feeling well from the theory perspective, but I really had no much idea what the CCIE lab was all about before starting to work on the workbooks. I remember the first time I sent my answers of the Troubleshooting Challenge to Dan I included changes on the BB routers; I had no idea you couldn’t touch them back then!!.

I would follow several blogs. To name a few, I strongly recommend reading Petr posts to any candidate (I would even say some of them are a MUST, OSPF Route Filtering Demystified per instance), doing Dan’s TS Tickets, and so on..

Last year I got a job offer I couldn’t resist from a company which would provide me access to full racks, so I had no more excuses… time to schedule the lab!... I had the feeling I had a good understanding of the technologies on the blueprint and that I just needed to get used to do a lab for 8 straight hours. I looked for alternatives for graded labs. I think only 360 (NMC) and INE offer them, being the latter option much cheaper, so I scheduled five Mock Labs with them on which I scored in the range of 60-70. At the same time IPexpert offered me their Vol III and rack rental time in exchange of that banner you see on the left. After all that I felt ready… but then I couldn’t pass the config part of the exam (only passed the troubleshooting section) back in march.

I scheduled again for july. Narbik provided me his updated 4.0 Workbook which I used to practice on those areas I felt I wasn’t confident enough and to keep discovering that there is always something you don’t know …

….And a couple of days ago I finally got my Number !!!

PASS (español)

2011-08-01T18:07:00.004-04:00

Guau… ha sido una travesía muy, muy larga… Comencé a estudiar para el CCIE® tiempo después de haber obtenido las certificaciones CCNA/CCNP/CCIP hace más de dos años. Me guié por el blueprint el cual no es lo suficientemente detallado, por lo que basé mis estudios en la versión extendida no oficial que a fin de cuentas es muy similar a la versión extendida oficial que publicaron luego. Hasta el día de hoy sigo mi progreso en las distintas secciones de ésta.

Comencé a leer una serie de libros mientras hacía mini laboratorios que creaba para probar conceptos. Por esos días sólo tenía un PC antiguo que con suerte podía correr 3-4 routers simultáneamente en GNS3. Me dí cuenta que alguna de las cosas nuevas que iba aprendiendo, pronto las olvidaba por lo que decidí tomar notas regularmente, guardar ejemplos de configuraciones y es entonces que nació este blog que me forzaría a escribir notas tan claras como fuera posible para poder revisar luego. Lamentablemente escribir posts con un formato adecuado consume mucho tiempo, por lo que no he podido realmente escribir todo aquí. Trataré ahora de escribir más seguido para compartir más acerca de mi aprendizaje.

Después de un tiempo conseguí armar un lab con varios 2600’s, 2800’s y un 2950 que me permitieron armar topologías más grandes. Narbik realizó un Troubleshooting Challenge que me hizo acreedor de un par de workbook para practicar. A esa altura me sentía bien desde el punto de vista de la parte teórica, pero estaba un tanto perdido de lo que realmente era el laboratorio.

Seguía/sigo muchos blogs. Por nombrar algunos, recomiendo encarecidamente leer los post de Petr a todo candidato (por ejemplo: OSPF Route Filtering Demystified), hacer los labs que publica Dan, etc..

El año pasado me cambié de trabajo a una compañía que tiene rack completos para practicar, por lo que ya no tuve más excusa.. era hora de agendar el examen!... Tenía la impresión de tener comprender bastante bien las tecnologías en el blueprint y sólo me faltaba acostumbrarme a hacer un laboratorio por 8 horas seguidas.Las únicas alternativas que encontré de exámenes de prácitca con evaluación fueron 360 (NMC) e INE, este última opción bastante más económica, por lo que agendé 5 labs de práctica con ellos en los que obtuve entre 60 y 70 puntos. Al mismo tiempo IPexpert me ofreció el Voulume III de sus workbooks y tiempo en sus racks a cambio del banner que ven a la izquierda. Después de todo eso, sentí estaba listo pero no pude pasar la parte de configuración en marzo (sólo pasé la parte de troubleshooting).

Agendé nuevamente para julio. Narbik me facilitó su Workbook 4.0 actualizado el que utilicé para practicar aquellas áreas que no me sentía lo suficientemente seguro y para continuar descubriendo que siempre hay algo que uno no sabe …

…y hace un par de días finalmente obtuve mi número!!!

RSH en routers Cisco

2011-07-20T00:38:00.004-04:00

Un pequeño post con una herramienta que si bien no muy recomendable desde el punto de vista de seguridad, bastante interesante y que desconocía hasta hoy de su existencia en routers Cisco. La topología a utilizar es muy sencilla y se probará cómo ejecutar comandos en un router de manera remota con RSH.

La configuración se realiza en el router al que se accederá remotamente, en este caso Rack1R2:

hostname Rack1R2
!
username R2 privilege 15 password cisco
!
ip rcmd rsh-enable
ip rcmd remote-host R2 129.1.124.1 Rack1R1 enable

Con ip rcmd rsh-enable se habilita el feature y con ip rcmd remote-host se especifica el usuario local que ejecutará los comandos (R2), la dirección IP del host remoto (129.1.124.1) y el usuario remoto que accesará (Rack1R1). Luego sólo queda probar desde Rack1R1.

Rack1R1#rsh 129.1.124.2 /user R2 show clock

*11:16:05.285 UTC Wed Jul 20 2011

Rack1R1#

En Rack1R2 se puede hacer debug con debug ip tcp rcmd.

Rack1R2#
*Jul 20 11:16:05.265: RCMD: [514 <- 129.1.124.1:960] recv \0
*Jul 20 11:16:05.265: RCMD: [514 <- 129.1.124.1:960] recv Rack1R1\0R2\0show clock\0
*Jul 20 11:16:05.269: RCMD: [514 -> 129.1.124.1:960] send

World IPv6 Day

2011-05-26T23:25:00.005-04:00

En un par de semanas (8 de Junio) se llevará el World IPv6 Day. Un número importante de sitios como Google, Facebook, Yahoo!, Akamai, Limelight Networks, entre otros estará accesible via IPv6. Varios paises estarán realizando actividades relacionadas ese día, por ejemplo los casos de Chile, España y Colombia.

Cisco tiene un sitio de preguntas y respuestas al respecto en: https://supportforums.cisco.com/community/netpro/network-infrastructure/ipv6-transition.

Al día de hoy la adopción de IPv6 alcanza a un 0.34%: http://www.google.com/intl/en/ipv6/statistics/.

Para saber si tienes conectividad IPv6, ir al siguiente sitio: http://test-ipv6.com/. Para validar si un sitio es compatible con IPv6: http://ipv 6-test.com/validate.php.

Problemas?: Troubleshoot IPv6 Issues.

Un excelente libro gratis de referencia para IPv6 en: The Second Internet.

ISATAP

2011-05-17T18:58:00.001-04:00

En Transición a IPv6 se dejó pendiente revisar un método de encapsulación de IPv6 en IPv4; ISATAP. Si bien también existe 6rd, este método se escapa del contexto del examen de CCIE® de R&S. Para ver ISATAP en acción se usará la topología de la figura, suponiendo conectividad a nivel de IPv4 previamente configurada.

Lo primero que conviene revisar es la forma de las direcciones del los túneles ISATAP. El prefijo (primeros 64 bits) son definidos por el usuario, en tanto que el identificador de la interface tiene la siguiente forma de acuerdo al RFC 5214:

6.1.  ISATAP Interface Identifiers

 ISATAP interface identifiers are constructed in Modified EUI-64
 format per Section 2.5.1 of [RFC4291] by concatenating the 24-bit
 IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 32-bit
 IPv4 address in network byte order as follows:

 |0              1|1              3|3                              6|
 |0              5|6              1|2                              3|
 +----------------+----------------+--------------------------------+
 |000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm|
 +----------------+----------------+--------------------------------+

 When the IPv4 address is known to be globally unique, the "u" bit
 (universal/local) is set to 1; otherwise, the "u" bit is set to 0.
 "g" is the individual/group bit, and "m" represents the bits of the
 IPv4 address.

En palabras sencillas, los primeros 32 bits serán 0:5efe (o una pequeña variación dependiendo de los bits "u" y "g") . Los siguientes 32 corresponderán a la representación hexadecimal de una dirección IPv4.

En ambos routers (R2 y R3) se configura la interface tunnel especificando como origen las loopbacks de cada equipo (2.2.2.2 y 3.3.3.3 respectivamente).

interface Tunnel23
ipv6 address 2001:db8:a:a::/64 eui-64
tunnel source Loopback0
tunnel mode ipv6ip isatap

Se puede ver que automáticamente el router asigna los identificadores de interface:

R2#sh ipv6 int tu23 | i address|subnet
IPv6 is enabled, link-local address is FE80::5EFE:202:202
No Virtual link-local address(es):
Global unicast address(es):
  2001:DB8:A:A:0:5EFE:202:202, subnet is 2001:DB8:A:A::/64 [EUI]
Joined group address(es):
Hosts use stateless autoconfig for addresses.

R3#sh ipv6 int tu23 | i address|subnet
IPv6 is enabled, link-local address is FE80::5EFE:303:303
No Virtual link-local address(es):
Global unicast address(es):
  2001:DB8:A:A:0:5EFE:303:303, subnet is 2001:DB8:A:A::/64 [EUI]
Joined group address(es):
Hosts use stateless autoconfig for addresses.

Para probar conectividad se configura EIGRPv6 especificando el neighbor dada la naturaleza NBMA de los túneles que no tienen destino específico. Entonces ¿Cómo averigua el destino del tunel un paquete a través de estas interfaces?. Pues bien lo deduce de la IPv4 embebida en la dirección IPv6 para cada paquete.

interface tunnel 23
ipv6 eigrp 1
!
ipv6 router eigrp 1
neighbor fe80::5efe:202:202 tunnel 23
no shut

interface tunnel 23
ipv6 eigrp 1
!
ipv6 router eigrp 1
neighbor fe80::5efe:303:303 tunnel 23
no shut

En cada router se configura una red como se detalla a continuación y se hace parte del protocolo de ruteo.

R2#sh run int lo100
Building configuration...

Current configuration : 91 bytes
!
interface Loopback100
no ip address
ipv6 address 2001:DB8:0:2::2/64
ipv6 eigrp 1
end

R3#sh run int lo100
Building configuration...

Current configuration : 91 bytes
!
interface Loopback100
no ip address
ipv6 address 2001:DB8:0:3::3/64
ipv6 eigrp 1
end

Finalmente se prueba conectividad.

R2#ping 2001:db8:0:3::3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:3::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/40/44 ms
R2#

R3#ping 2001:db8:0:2::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/41/44 ms

Notar que se tiene conectividad IPv6, pese a que R1 sólo habla IPv4. Por otro lado se puede terminar un tunel en un ordenador corriendo Windows como muestran en este ejemplo: Ipv6 ISATAP tunneling.

CCIE SP v3.0 Sample Lab

2011-05-16T14:11:00.007-04:00

Disponible en los siguientes enlaces:

O descarga en un único archivo: CCIE SP v3.0 Sample Lab.pdf Enlace será agregado a: Material Gratis.

Frame Relay Switching

2011-05-09T14:04:00.006-04:00

A continuación uno de los tópicos que antiguamente era considerados como una caja negra para el examen de laboratorio del CCIE® de Routing & Switching. A partir de la versión 4 de este examen, Frame-Relay Switching es un tópico que los candidatos deben manejar y saber configurar. Para el siguiente ejemplo se configura las interfaces seriales de R2 y R3 hacia R1 como se ve en la figura.

R2#sh run int s2/0
Building configuration...

Current configuration : 116 bytes
!
interface Serial2/0
ip address 192.0.2.2 255.255.255.224
encapsulation frame-relay
serial restart-delay 0
end

R3#sh run int s3/0
Building configuration...

Current configuration : 116 bytes
!
interface Serial3/0
ip address 192.0.2.3 255.255.255.224
encapsulation frame-relay
serial restart-delay 0
end

Dado que se está haciendo una configuración back-to-back Frame Relay, los circuitos se mantendrán caídos (down) hasta que o bien se deshabilite el keepalive de las interfaces o bien se configure R1 como frame relay switch como se verá a continuación.

frame switching
!
int s2/0
frame-relay intf-type dce
!
int s3/0
frame-relay intf-type dce

A esta altura obviamente no exitirá información de PVC's en los spokes ya que no se ha configurado nada aún.

R2#sh frame pvc

R2#

R3#sh frame pvc

R3#

Se configurará Frame-Relay Switching con el comando connect (Frame Relay).

R1(config)#connect R2-R3 s2/0 222 s3/0 333

Luego se podrá ver en los spokes que la información de los PVC's disponibles ha sido transmitida.

R2#sh frame pvc

PVC Statistics for interface Serial2/0 (Frame Relay DTE)

        Active     Inactive      Deleted       Static
Local          1            0            0            0
Switched       0            0            0            0
Unused         0            0            0            0

DLCI = 222, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0

input pkts 0             output pkts 0            in bytes 0
out bytes 0              dropped pkts 0           in pkts dropped 0
out pkts dropped 0                out bytes dropped 0
in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
out BECN pkts 0          in DE pkts 0             out DE pkts 0
out bcast pkts 0         out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:00:13, last time pvc status changed 00:00:13

R3#sh frame pvc

PVC Statistics for interface Serial3/0 (Frame Relay DTE)

        Active     Inactive      Deleted       Static
Local          1            0            0            0
Switched       0            0            0            0
Unused         0            0            0            0

DLCI = 333, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0

input pkts 1             output pkts 1            in bytes 34
out bytes 34             dropped pkts 0           in pkts dropped 0
out pkts dropped 0                out bytes dropped 0
in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
out BECN pkts 0          in DE pkts 0             out DE pkts 0
out bcast pkts 1         out bcast bytes 34
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:00:16, last time pvc status changed 00:00:16

Pero no sólo se tendrá eso, dado que no se ha desabilitado frame-relay inverse-arp, se tendrá:

R2#sh frame map
Serial2/0 (up): ip 192.0.2.3 dlci 222(0xDE,0x34E0), dynamic,
        broadcast,
        CISCO, status defined, active

R3#sh frame map
Serial3/0 (up): ip 192.0.2.2 dlci 333(0x14D,0x50D0), dynamic,
        broadcast,
        CISCO, status defined, active

...y eso sería todo:

R2#ping 192.0.2.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/41/48 ms

Otra forma sería con el comando frame-relay route:

R1(config)#no connect R2-R3 s2/0 222 s3/0 333
R1(config)#
R1(config-if)#int s2/0
R1(config-if)#frame-relay route 222 interface s3/0 333
R1(config-if)#
R1(config-if)#int s3/0
R1(config-if)#frame-relay route 333 interface s2/0 222

R2#ping 192.0.2.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/40/44 ms

My Lab Experience

2011-03-17T04:05:00.009-03:00

Ok, this is going to be the single exception to the rule to post in Spanish, but wanted to give visibility to a wider audience as most of my preparation has been based on things I have read on groupstudy or some other blogs (see blog list at the bottom), so gotta contribute back somehow to the community.
Unfortunately I did NOT pass this time. I really felt like I was prepared, but was proven wrong.

1. Troubleshooting: I did pass this section, I was able to answer all the tickets. I now regret I did not move on to the config part sooner. I knew what I was doing, but in order to secure the points I went through all the tickets once again after I completed them all in order to verify the fixes, burning valuable 25 minutes or so (I did not change anything from what I had done on that time). Overall one or two tickets kept me thinking, the rest of them were pretty clear on what they were asking for.

2. Configuration: I failed this part. More difficult and definitely much longer than what I was expecting to. Dividing the total time for the number of questions, you have less than 15 minutes for each one and in my opinion some of them need a little more thinking than that…but since other people do pass it, looks like I’m just too slow. There are some questions that might be straight forward, but you need to know very well what you are doing and there is no room for mistakes. Then there are other questions that will mix things, so the understanding of it needs to go a bit deeper. And last but not least, questions that will test all your knowledge on certain technologies ..including its “tricks”!!.

I started very slow, trying to make sure I was covering every single requirement on L2. In the middle of L3 I came into something that didn’t work for me at first try, a very challenging scenario. Tried different options until things seemed to be working as requested. Then I had to run through the rest of the exam, which I managed to complete, but skipping some bullets in certain sections that I was not 100% sure of. I would supposedly complete them afterwards. I didn’t do much verifications, just typed as fast as I could what I thought it might fulfill the requirements. Unfortunately I ran short of time, and since there are no partial points I did not reach the 80% goal.

Overall I feel I did my best and not sure what else I could have done to succeed on this attempt. I got a decent amount of points, even a 100% on one section, but certainly not enough to pass the exam. I’m really frustrated after all the hard work. I could work on speed, but there will always be something you don’t know…. We will see.

What materials I have used to prepare the exam?.

a. Several books. I have something around 15 on my bookshelf, but you don’t really need to read them all (I haven’t). The one I do recommend reading for starters is Routing TCP/IP.

b. The first workbooks I ever used were Narbik’s, which I won on a troubleshooting contest.

c. I worked with a couple of workbooks from Internetwork Expert and did 5 of their graded Mock Labs (got an excellent discount). If you want a reference I scored between 60 and 70 on all of them, so you probably want to reach 80 on those before the real deal.

d. I went through the Vol III of IPexpert that the nice banner on the left bought for me :)

e. I based all my studies on the following list: CCIE R/S 4.X Expanded Study Blueprint. I also created an Anki deck, mapping each topic to the most useful commands to implement given feature/technology/etc., that I would review on a daily basis.

f. I’m a big fan of tech blogs, most of the ones I follow are listed on the bottom of this page (some of them are no longer updated, but have very valuable info). I might be missing some, as I lost the original list when changed my blog design template.

g. Don't miss the free sessions the different vendors offer (INE, IPX, Narbik, NMC )... I used to update this list: Material Gratis regularly, but I haven’t in the last months as I was doing labs on my spare time.

h. Don't forget to watch this: CCIE R&S v4.0 Lab Exam Demo, before you go to your lab.

I’m taking a short break now to get up to date at work and to be with my loved ones, then I will start planning the strategy for my second attempt…

I’ll keep posting in Spanish as soon as I get back on my feet…

L2 en sección de Troubleshooting

2011-01-14T19:09:00.004-03:00

En Cisco Learning Network se anunció que a partir del 17 de enero del 2011 la sección de troubleshooting del examen CCIE® de R&S incluirá tickets de capa 2, en particular de switching, funcionalidad que no estaba hasta ahora integrada en sus simuladores.

Introducing inclusion of new Layer 2 switching capability in
the virtual lab environment of the CCIE R&S Troubleshooting exam

In alignment with CCIE level requirements, Cisco is adding L2 switching features
to the CCIE R&S Troubleshooting exam through L2 IOS software on Unix (L2IOU)
virtual environment. The new feature will be available starting January 17, 2011.

The CCIE R&S exam consists of 2 sections – the troubleshooting (TS) section which
runs two hours, and the Configuration (Config) section which is six hours. The Config
lab utilizes actual physical devices in racks, whereas, the TS lab uses a virtual
environment under IOU. IOU offers a very realistic simulation of router (L3+)
features in the TS lab but until now had no L2 switch capability. With the addition
of the new L2IOU, the TS lab will now include both L2 and L3 capabilities in the
virtual environment.

Note:

With this new capability you may notice some subtle cosmetic and functional differences
between the behaviors of the physical switch and the virtual switch. However, the
function of the devices is fundamentally the same, and these differences should not
affect your ability to apply what you have learned to succeed in the lab exam.

Fuente: New L2 Virtual Switching Capability Added to CCIE R&S Lab Exam

Boot Camp en Latinoamerica

2010-11-23T09:24:00.002-03:00

Ricardo Guerra está haciendo gestiones para realizar un Boot Camp para la preparación del examen de CCIE R&S en Latinoamérica. Según me indica sería en Lima, Perú entre enero y febrero del 2011. Están en conversaciones con Narbik Kocharians para traer su programa CCIE End-to-End descrito a continuación:

Programa: CCIE End-to-End
Instructor: Narbik Kocharians
Duración: 12 días
Componentes:

Al momento de registrarse recibirán el ebook "The Fundation Workbook 2.0" valorizado en $100.00 dólares. El participante deberá hacer los labs contenidos en el workbook y estar familiarizados con los ejercicios contenidos en el.

El primer día del boot camp, los participantes recibirán el siguiente material:

"Advanced CCIE R&S 2.0" valorizado en $350.00 dolares
"Bootcamp 2.0", el mejor libro a la fecha para el CCIE R&S 4.0
Manual oficial del programa CCIE 360 R&S (vol I, II and lab guide)

Los participantes tendrán acceso, 24 horas x 12 días para realizar los ejercicios del Boot camp del instructor compuesto de 9 routers y 4 switches

Los participantes tendran acceso a los racks del programa CCIE 360 y desarrollarán 2 assessment labs. Estos son mock labs con calificación que emulan el examen CCIE R&S

Los participantes tendrán acceso a 10 "eight hour Troubleshooting Mock Labs"

Si los participantes fallan en el examen, recibirán por parte de Cisco un voucher que cubre al 100% el costo del siguiente examen. Esta oferta es limitada y puede verse en el siguiente enlace : https://learningnetwork.cisco.com/docs/DOC-5857

Interesados por favor contactarse con Ricardo Guerra.

OSPF Filter; Inter Area

2010-11-10T10:24:00.012-03:00

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.

OSPF Filter; Intra Area con distribute-list

2010-10-26T20:18:00.017-03:00

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.

Frame Relay Timers

2010-08-14T21:30:00.026-04:00

Quizás una de las tareas menos intuitivas dentro del contexto del examen de laboratorio del CCIE® de Routing & Switching sea configurar los timers de Frame-Relay. Principalmente por que los comandos no son fáciles de recordar, además que no es directo distinguir la diferencia entre éstos. A continuación se comentará brevemente los comandos disponibles extraídos de la página de soporte de Cisco, lo que se conocía antiguamente como DocCD.

Entre el router y switch Frame-Relay se correrá LMI, de este modo el router enviará, por defecto, cada 10 segundos un Status Inquire indicando que el tipo de reporte solicitado es un número de secuencia (Sequence Number Exchange), a lo que el switch responde con el mismo mensaje con el número de secuencia incrementado en 1 y así sucesivamente. Esto permite que el switch conozca el estatus del subscritor (keepalive) y viceversa. A su vez, cada 60 segundos, por defecto, el tipo de reporte solicitado será Full Status, al lo que el switch responde con el estado de los PVC, para cada uno de los DLCI configurados en el circuito.

Para modificar estos valores se utilizan los comandos especificados en: Explicitly Configuring the LMI. En particular para cambiar el intervalo en que se envían los mensajes de Status Inquire se utiliza keepalive (LMI) y para modificar el intervalo en que se se solicita un Full Status se utiliza: frame-relay lmi-n391dte.

Además se puede manipular otras variables asociadas a estos valores, pero en su mayoría aplican al lado del Switch (DCE), ver: Setting the LMI Polling and Timer Intervals.

R2(config-if)#frame-relay lmi-?
lmi-n391dte  lmi-n392dce  lmi-n392dte  lmi-n393dce
lmi-n393dte  lmi-t392dce  lmi-type

Vale la pena señalar que para conexiones back-to-back Frame-Relay entre dos routers, que por ende no utilizarán LMI, será necesario deshabilitarlo con: no keepalive.

Pero si se quisiera tener un keepalive que cubriese el PVC extremo a extremo, es decir de router a router y no sólo router a switch, es necesario configurar: Frame Relay End-to-End Keepalive. Básicamente se configura un map-class Frame-Relay con map-class frame-relay, al que se le especifica la función de keepalive end-to-end con: frame-relay end-to-end keepalive mode, que variará de acuerdo a qué router hace los requerimientos y cuál responde (puede ser bi-direccional también). Luego se aplica el map-class a la interface correspondiente con frame-relay class.

R2(config)#map-class frame-relay NAME
R2(config-map-class)#frame-relay end-to-end keepalive mode ?
bidirectional  Set bidirectional mode
passive-reply  Set passive-reply mode
reply          Set unidirectional reply mode
request        Set unidirectional request mode

R2(config-if)#frame-relay class NAME

Los timers para esta funcionalidad se configuran con los comandos detallados abajo:

Nombre de vecinos en OSPF/IS-IS

2010-08-08T00:37:00.007-04:00

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.

CCIE R&S v4.0 Lab Exam Demo

2010-07-08T12:15:00.005-04:00

Disponible en el siguiente enlace: CCIE R&S v4.0 Lab Exam Demo.
Enlace agregado a: Material Gratis.

El Examen III

2010-05-07T15:07:00.002-04:00

Para complementar/actualizar lo señalado en El Examen y El Examen II, Cisco acaba de anunciar que suprimirá la sección de Open Ended Questions del examen CCIE® tracks Routing & Switching y Voice.

Update to the CCIE Lab Question Format

Beginning May 10, 2010, CCIE R&S lab exams in all global locations will no longer
include the four, open-ended Core Knowledge questions.
The total lab exam time will remain eight hours. CCIE R&S candidates will begin
with the 2-hour Troubleshooting section, followed by a 6-hour Configuration section.

Fuente: CCIE ROUTING AND SWITCHING TRACK, Lab Exam

Rip Timers

2010-05-03T12:15:00.003-04:00

Después de leer dos excelentes posts respecto de los timers de RIP, específicamente; How basic are RIP timers? y RIP Timers, uno podrá notar que que si bien aparenta ser un tema sencillo, realmente puede ser muy confuso.

Los timers definidos para RIPv2 RFC 2453 son claros. Además del intervalo de update, están timeout (invalid en routers Cisco) y garbage-collection (flush en routers Cisco), que definen el tiempo que debe transcurrir sin escuchar updates para una detrminada ruta antes de declararla como inválida y el tiempo que debe transcurrir para definitivamente remover la ruta de la tabla de ruteo resectivamente. Sin embargo la implementación de Cisco incluye otros dos timers; holddown y sleep. En particular se pueden encontrar múltiples referencia a holdown, la cuales en muchos casos son contradictoria. Es por eso a continuación se verá seis ejemplo para sacar conclusiones. Se utilizará el diagrama que se muestra a continuación y los output de debugs corresponderán a R3, que está corriendo IOS versión 12.4(23).
Por defecto los timers en router Cisco son; update 30 segundos, invalid 180, hold down 180 y flush 240. Para el escenario en que se trabajará los timers serán seteados a 20, 60, 60 y 180 respectivamente con el comando timers basic. Si se quiere modificar el perídodo de update para una interface en particular se puede utilizar el comando ip rip advertise, como se especifica en la descripción del bug CSCdy77097.

router rip
version 2
 timers basic 20 60 60 180
network 192.0.2.0
network 198.51.100.0
network 203.0.113.0
no auto-summary

Por ende los timer se comportarán como se muestra proporcionalmete en la siguiente figura.

Para los debugs se utilizarán los comandos debug ip routing y debug ip routing. Adicionalmete se revisará la tabla de ruteo y la base de datos de RIP con show ip rip database. Por útimo en R4 se manipularán los anuncios con offset-list y distribute-list out. Para estos propositos se agregan además dos listas de acceso.

R4(config)#access-list 1 deny 192.0.2.44
R4(config)#access-list 1 permit any
R4(config)#access-list 2 permit 192.0.2.44

1) Se recibe update de una ruta con mayor métrica a la actual previo a que Invalid expire.

Como paso preliminar se filtra el anuncio de la ruta de interés (192.0.2.44/32) por una de las interfaces de R4:

R4(config)#router rip
R4(config-router)#distribute-list 1 out s0/0/0

Se observa en R3 se recibe una actualización períodica a las 21:06:09.

May  1 21:06:09.864: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:06:09.864:      192.0.2.44/32 via 0.0.0.0 in 1 hops

Se revisa la tabla de ruteo.

R3#sh clock
21:06:12.145 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/1] via 198.51.100.144, 00:00:02, FastEthernet0/0

Posteriormente se envía desde R4 la ruta con mayor mayor métrica. Se puede observar en el siguiente update períodico se recibe la ruta con la nueva métrica.

May  1 21:06:29.554: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:06:29.558:      192.0.2.44/32 via 0.0.0.0 in 11 hops
May  1 21:06:29.558: RT: rip's 192.0.2.44/32 (via 198.51.100.144) metric changed from distance/metric [120/1] to
[120/11]

La ruta aparece inmediatamente después con la nueva métrica en la tabla de ruteo.

R3#sh clock
21:06:30.570 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/11] via 198.51.100.144, 00:00:01, FastEthernet0/0

Se gatilla entonces un triggered update a sus vecinos (menos a través de F0/0 debido a la regla de split horizon).

May  1 21:06:31.558: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (198.51.100.133)
May  1 21:06:31.558: RIP: build flash update entries - suppressing null update

May  1 21:06:31.558: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (203.0.113.133)
May  1 21:06:31.558: RIP: build flash update entries
May  1 21:06:31.558:    192.0.2.44/32 via 0.0.0.0, metric 12, tag 0

Posteriormente se aumenta la métrica nuevamente desde R4.

R4(config-router)#offset-list 2 out 10 f0/0

En el siguiente update períodico se recibe la ruta con la nueva métrica.

May  1 21:06:49.016: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:06:49.016:      192.0.2.44/32 via 0.0.0.0 in 13 hops
May  1 21:06:49.016: RT: rip's 192.0.2.44/32 (via 198.51.100.144) metric changed from distance/metric [120/11] to
[120/13]

Como se puede apreciar la ruta es insertada inmediatamente en la tabla de ruteo, por ende la ruta NO entró nunca en holddown.

R3#sh clock
21:06:50.048 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/13] via 198.51.100.144, 00:00:01, FastEthernet0/0

2) Se recibe update de una ruta con métrica 16 previo a que Invalid expire.

Como paso preliminar se filtra el anuncio de la ruta de interés (192.0.2.44/32) por una de las interfaces de R4:

R4(config)#router rip
R4(config-router)#distribute-list 1 out s0/0/0

Se recibe una actualización períodica a las 21:24:36.

May  1 21:24:36.275: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:24:36.275:      192.0.2.44/32 via 0.0.0.0 in 1 hops

Se revisa la tabla de ruteo.

R3#sh clock
21:24:39.563 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/1] via 198.51.100.144, 00:00:03, FastEthernet0/0

Posteriormente se envía desde R4 la ruta con métrica 16.

R4(config-router)#offset-list 2 out 16 f0/0

En el siguiente update períodico se recibe la ruta con la nueva métrica (16 = inaccessible)

May  1 21:24:53.568: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:24:53.568:      192.0.2.44/32 via 0.0.0.0 in 16 hops  (inaccessible)
May  1 21:24:53.568: RT: delete route to 192.0.2.44 via 198.51.100.144, rip metric [120/1]
May  1 21:24:53.568: RT: no routes to 192.0.2.44, entering holddown

R3#sh clock
21:24:54.516 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44/32 is possibly down,

La ruta entra automáticamente en holddown.

3) Se recibe update de una ruta con mayor métrica durante el periodo de holddown proveniente del mismo vecino que anunciaba la ruta originalmente.

Como paso preliminar se filtra el anuncio de la ruta de interés (192.0.2.44/32) por una de las interfaces de R4:

R4(config)#router rip
R4(config-router)#distribute-list 1 out s0/0/0

Posteriormente se deja de anuncia por completo la ruta.

R4(config-router)#distribute-list 1 out f0/0

Como se verá a continuación a las 20:20:27 se recibe el último update de 192.0.2.44/32 a través de F0/0.

May  1 20:20:27.159: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 20:20:27.159:      192.0.2.44/32 via 0.0.0.0 in 1 hops

Aproximadamente 60 segundos después, una vez concluido el Invalid timer la ruta entra en holddown puesto que no se ha recibido nueva información de ésta.

May  1 20:21:34.821: RT: delete route to 192.0.2.44 via 198.51.100.144, rip metric [120/1]
May  1 20:21:34.821: RT: no routes to 192.0.2.44, entering holddown

R3 envía triggered updates con métrica 16 a sus vecinos.

May  1 20:21:36.821: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (198.51.100.133)
May  1 20:21:36.821: RIP: build flash update entries
May  1 20:21:36.821:    192.0.2.44/32 via 0.0.0.0, metric 16, tag 0

May  1 20:21:36.821: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (203.0.113.133)
May  1 20:21:36.821: RIP: build flash update entries
May  1 20:21:36.821:    192.0.2.44/32 via 0.0.0.0, metric 16, tag 0

R3 recibe de la ruta de vuelta desde R6 con métrica 16 (poison reverse).

May  1 20:21:38.825: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  1 20:21:38.825:      192.0.2.44/32 via 0.0.0.0 in 16 hops  (inaccessible)

A todo esto el timer de holdown a comenzado a contar. A las 20:21:44 ya han pasado 10 segundos desde que la ruta entró en holdown, restarían otros 50 segundos.

R3#sh clock
20:21:44.766 UTC Sat May 1 2010
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:17 ago
Hold down timer expires in 50 secs

La ruta aparece como possibly down tamto en la tabla de ruteo como la base de datos de RIP.

R3#sh ip route | i 192.0.2.44
R       192.0.2.44/32 is possibly down,

R3#sh ip rip database 192.0.2.44 255.255.255.255
192.0.2.44/32 is possibly down

Desde R4 se configura para volver a anunciar la ruta pero con mayor métrica.

R4(config-router)#offset-list 2 out 10 f0/0
R4(config-router)#no distribute-list 1 out f0/0

A las 20:21:45, R3 recibe un anuncio desde el mismo vecino con mayor métrica (11).

May  1 20:21:45.738: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 20:21:45.742:      192.0.2.44/32 via 0.0.0.0 in 11 hops

Sin embargo la ruta es ignorada.

R3#sh clock
20:21:47.518 UTC Sat May 1 2010
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:20 ago
Hold down timer expires in 47 secs

46 segundos después, o sea 106 segundos desde que esto comenzó ya se está a punto de conlcluir el periodo de holddown.

R3#sh clock
20:22:33.570 UTC Sat May 1 2010
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:02:06 ago
Hold down timer expires in 1 secs

Una vez fuera de holddown se instalará la nueva ruta con métrica 11, tan pronto el update periodico con esta información se reciba, esto pasa a las 20:22:42.

May  1 20:22:42.482: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 20:22:42.482:      192.0.2.44/32 via 0.0.0.0 in 11 hops
May  1 20:22:42.486: RT: add 192.0.2.44/32 via 198.51.100.144, rip metric [120/11]

Así se puede comprobar en la tabla de ruteo.

R3#sh clock
20:22:45.282 UTC Sat May 1 2010

R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/11] via 198.51.100.144, 00:00:02, FastEthernet0/0

4) Se recibe update de una ruta con mayor métrica durante el periodo de holddown proveniente de un vecino distinto al que anunciaba la ruta originalmente.

Como paso preliminar se filtra el anuncio de la ruta de interés (192.0.2.44/32) por una de las interfaces de R4:

R4(config)#router rip
R4(config-router)#distribute-list 1 out s0/0/0

Se recibe update periodico.

May  1 22:05:40.276: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 22:05:40.276:      192.0.2.44/32 via 0.0.0.0 in 1 hops

Posteriormente se deja de anuncia por completo la ruta.

R4(config)#router rip
R4(config-router)#distribute-list 1 out f0/0

Aproximadamente 60 segundos después, una vez concluido el Invalid timer la ruta entra en holddown puesto que no se ha recibido nueva información de ésta.

May  1 22:06:45.513: RT: delete route to 192.0.2.44 via 198.51.100.144, rip metric [120/1]
May  1 22:06:45.513: RT: no routes to 192.0.2.44, entering holddown

R3#sh clock
22:06:48.221 UTC Sat May 1 2010
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:07 ago
Hold down timer expires in 57 secs

R3#
R3#sh ip rip database 192.0.2.44 255.255.255.255
192.0.2.44/32 is possibly down

Una vez que la ruta entra en holddown, R4 anuncia la ruta a través de s0/0/0 de modo que R3 la reciba por F0/1 con una mayor métrica.

R4(config-router)#no distribute-list 1 out serial0/0/0

R4 debe propagar esta info a R5, éste útimo a su vez a R6 para que así finalmente le llegue la nueva ruta a R3. Ésto sucede por primera vez a las 22:07:10.

May  1 22:07:10.815: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  1 22:07:10.819:      192.0.2.44/32 via 0.0.0.0 in 3 hops

Sin embargo R3 ignora esta info como se ve del output de la tabla de ruteo.

R3#sh clock
22:07:11.499 UTC Sat May 1 2010
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:31 ago
Hold down timer expires in 33 secs

Se recibe otro update de la ruta durante el periodo de holddown, que es también ignorado.

May  1 22:07:28.940: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  1 22:07:28.940:      192.0.2.44/32 via 0.0.0.0 in 3 hops

Luego de transcurrido el tiempo de holddown los updates podrán gatillar una actualización de la tabla de ruteo.

May  1 22:07:47.334: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  1 22:07:47.338:      192.0.2.44/32 via 0.0.0.0 in 3 hops

May  1 22:07:47.338: RT: 192.0.2.44 came out of holddown
May  1 22:07:47.338: RT: add 192.0.2.44/32 via 203.0.113.166, rip metric [120/3]

5) Se recibe update de una ruta con menor métrica durante el periodo de holddown proveniente del mismo vecino que anunciaba la ruta originalmente.

Como paso preliminar se filtra el anuncio de la ruta de interés (192.0.2.44/32) por una de las interfaces de R4 y se aumenta su métrica hacia R3:

R4(config)#router rip
R4(config-router)#distribute-list 1 out s0/0/0
R4(config-router)#offset-list 2 out 5 f0/0

Se recibe update períodico.

May  1 21:43:30.583: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:43:30.583:      192.0.2.44/32 via 0.0.0.0 in 6 hops

Se revisa la tabla de ruteo.

R3#sh clock
21:43:34.600 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/6] via 198.51.100.144, 00:00:04, FastEthernet0/0

Se suprime el anuncio para entrar en holddown después de 60 segundos aprox.

R4(config-router)#distribute-list 1 out f0/0

R3 anuncia la ruta ha entrado en holddown.

May  1 21:44:35.405: RT: delete route to 192.0.2.44 via 198.51.100.144, rip metric [120/6]
May  1 21:44:35.405: RT: no routes to 192.0.2.44, entering holddown

Se revisa la base de datos de RIP.

R3#sh clock
21:44:38.625 UTC Sat May 1 2010
R3#
R3#sh ip rip database 192.0.2.44 255.255.255.255
192.0.2.44/32 is possibly down

Luego se reestablece el anuncio con una mejor métrica.

R4(config-router)#no offset-list 2 out 5 f0/0
R4(config-router)#no distribute-list 1 out f0/0

A las 21:45:00 se escucha por primera vez nuevamente la ruta.

May  1 21:45:00.511: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:45:00.511:      192.0.2.44/32 via 0.0.0.0 in 1 hops

Sin embargo la ruta es ignorada como se aprecia en la tabla de ruteo donde sigue como possibly down.

R3#sh clock
21:45:03.699 UTC Sat May 1 2010
R3#
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:33 ago
Hold down timer expires in 31 secs

R3#sh ip route | i 192.0.2.44
R       192.0.2.44/32 is possibly down,

Una vez concluido el holddown timer la ruta podrá ser insertada en la tabla de ruteo una vez se reciba.

May  1 21:45:19.872: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:45:19.872:      192.0.2.44/32 via 0.0.0.0 in 1 hops

May  1 21:45:37.366: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:45:37.366:      192.0.2.44/32 via 0.0.0.0 in 1 hops
May  1 21:45:37.366: RT: 192.0.2.44 came out of holddown
May  1 21:45:37.370: RT: add 192.0.2.44/32 via 198.51.100.144, rip metric [120/1]

R3#sh clock
21:45:37.698 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/1] via 198.51.100.144, 00:00:00, FastEthernet0/0

6) Se recibe update de una ruta con menor métrica durante el periodo de holddown proveniente de un vecino distinto al que anunciaba la ruta originalmente.

Como paso preliminar se filtra el anuncio de la ruta de interés (192.0.2.44/32) por una de las interfaces de R4 y se aumenta su métrica hacia R3:

R4(config)#router rip
R4(config-router)#distribute-list 1 out s0/0/0
R4(config-router)#offset-list 2 out 10 f0/0

Se recibe update periodico.

May  2 20:57:57.220: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  2 20:57:57.220:      192.0.2.44/32 via 0.0.0.0 in 11 hops

Se suprime el anuncio.

R4(config)#router rip
R4(config-router)#distribute-list 1 out f0/0

Aproximadamente 60 segundos después la ruta entra en holddown.

May  2 20:59:02.601: RT: delete route to 192.0.2.44 via 198.51.100.144, rip metric [120/11]
May  2 20:59:02.601: RT: no routes to 192.0.2.44, entering holddown

R3#sh clock
20:59:04.221 UTC Sun May 2 2010
R3#
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:07 ago
Hold down timer expires in 58 secs

R3#sh ip route | i 192.0.2.44
R       192.0.2.44/32 is possibly down,

Una vez que la ruta entra en holddown, R4 anuncia la ruta a través de s0/0/0 de modo que R3 la reciba por F0/1 con una menor métrica.

R4(config-router)#no distribute-list 1 out serial0/0/0

A las 20:59:14 se recibe por primera vez.

May  2 20:59:14.342: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  2 20:59:14.342:      192.0.2.44/32 via 0.0.0.0 in 3 hops

Pero una vez más se puede observar que durante el holddown no se acepta ninguna info. respecto la ruta indiferente cuál sea su métrica.

R3#sh clock
20:59:15.614 UTC Sun May 2 2010
R3#
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:18 ago
Hold down timer expires in 46 secs

R3#sh ip route | i 192.0.2.44
R       192.0.2.44/32 is possibly down,

Sólo cuando haya concluido el holddown se podrá actualizar la ruta

May  2 20:59:29.023: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  2 20:59:29.023:      192.0.2.44/32 via 0.0.0.0 in 3 hops

May  2 20:59:48.497: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  2 20:59:48.497:      192.0.2.44/32 via 0.0.0.0 in 3 hops

May  2 21:00:07.631: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  2 21:00:07.631:      192.0.2.44/32 via 0.0.0.0 in 3 hops
May  2 21:00:07.631: RT: 192.0.2.44 came out of holddown
May  2 21:00:07.631: RT: add 192.0.2.44/32 via 203.0.113.166, rip metric [120/3]

R3#sh clock
21:00:09.135 UTC Sun May 2 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/3] via 203.0.113.166, 00:00:01, FastEthernet0/1

PPP sobre Frame Relay

2010-04-19T11:40:00.003-04:00

El RFC 1973 (PPP in Frame Relay) describe las particularidades de cómo transportar paquetes encapsulados en PPP sobre redes Frame-Relay. El método de cómo se encapsulan protocolos sobre Frame Relay es descrito en el RFC 2427 (Multiprotocol Interconnect over Frame Relay). Cisco a su vez lo describe en; PPP over Frame Relay.

Dentro del contexto del examen CCIE® de Routing & Switching, una de la aplicaciones que debe manejar es la autentificación de circuitos Frame-Relay utilizando PPP. Para esto se debe especificar un virtual template para un determinado DLCI. Ésto se hace con el comando frame-relay interface-dlci [ppp virtual-template-name], para luego configurar los parámetros dentro de interface virtual-template. Por defecto la encapsulación de un virtual template es PPP.

Como ejemplo se utilizará el esquema señalado en la figura de abajo. Para conectarse a R1 se deberá autentificar con PAP (PPP Authentication Protocol, RFC 1334) y a su vez para conectar a R2 se utilizará CHAP (Challenge Handshake Authentication Protocol, RFC 1994). Recordar que la autentificación es un proceso unidireccional en este caso.
Para comenzar simplemente se levantará PPP sobre Frame-Relay sin autentificación y luego se añadirá ésta según se especificó anteriormente.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface s0/0.12
R1(config-subif)#frame-relay interface-dlci 102 ppp virtual-template 2
R1(config-fr-dlci)#interface virtual-template 2
R1(config-if)#ip address 192.0.2.1 255.255.255.0
R1(config-if)#

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#interface s0/0/0.21
R2(config-subif)#frame-relay interface-dlci 201 ppp virtual-template 1
R2(config-subif)#interface virtual-template 1
R2(config-if)#ip address 192.0.2.2 255.255.255.0
R2(config-if)#

Una rápida verificación probará que todo parece estar funcionando.

R2(config-if)#do ping 192.0.2.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/56 ms
R2(config-if)#

A continuación se configura la autentificación. Se comenzará con PAP, ésto se especifica con el comando ppp authentication en el router que solicitará la autentificación (R1) que contrastará los datos de autentificación en este caso contra los usuarios locales configurados en el router. Con el comando username se configura uno a modo de ejemplo. El router que se autentificará (R2) utilizará los datos que se ingresar con el comando ppp pap sent-username.

R1(config)#interface virtual-template 2
R1(config-if)#ppp authentication pap
R1(config-if)#username USER password ccie.en.espanol
R1(config)#

R2(config)#interface virtual-template 1
R2(config-if)#ppp pap sent-username USER password ccie.en.espanol
R2(config-if)#

Con debug ppp authentication se puede ver el detalle del proceso de autentificación.

R1(config)#
R1(config)#do debug ppp authentication
PPP authentication debugging is on
R1(config)#int s0/0
R1(config-if)#shut
R1(config-if)#
*Mar  3 16:14:35.516: %LINK-5-CHANGED: Interface Serial0/0, changed state to administratively dow
*Mar  3 16:14:35.520: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
*Mar  3 16:14:36.516: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down
*Mar  3 16:14:36.520: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
R1(config-if)#no shut
R1(config-if)#
*Mar  3 16:14:48.896: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
*Mar  3 16:14:48.900: Vi1 PPP: Using default call direction
*Mar  3 16:14:48.900: Vi1 PPP: Treating connection as a dedicated line
*Mar  3 16:14:48.900: Vi1 PPP: Session handle[EF000491] Session id[320]
*Mar  3 16:14:48.900: Vi1 PPP: Authorization required
*Mar  3 16:14:50.888: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar  3 16:14:51.888: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
*Mar  3 16:15:09.524: Vi1 PPP: Authorization required
*Mar  3 16:15:09.544: Vi1 PAP: I AUTH-REQ id 1 len 25 from "USER"
*Mar  3 16:15:09.544: Vi1 PAP: Authenticating peer USER
*Mar  3 16:15:09.544: Vi1 PPP: Sent PAP LOGIN Request
*Mar  3 16:15:09.548: Vi1 PPP: Received LOGIN Response PASS
*Mar  3 16:15:09.548: Vi1 PPP: Sent LCP AUTHOR Request
*Mar  3 16:15:09.548: Vi1 PPP: Sent IPCP AUTHOR Request
*Mar  3 16:15:09.548: Vi1 LCP: Received AAA AUTHOR Response PASS
*Mar  3 16:15:09.548: Vi1 IPCP: Received AAA AUTHOR Response PASS
*Mar  3 16:15:09.552: Vi1 PAP: O AUTH-ACK id 1 len 5
*Mar  3 16:15:09.560: Vi1 PPP: Sent IPCP AUTHOR Request
*Mar  3 16:15:10.552: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

Se puede observar la autentificación de entrada (I) y el acknowledge de salida (O). En el otro sentido ahora se configurará CHAP.

R2(config-if)#interface Virtual-Template1
R2(config-if)#ppp authentication chap
R2(config-if)#
Apr 19 08:58:58.255: Vi1 PPP: Authorization required
Apr 19 08:58:58.339: Vi1 PAP: Using hostname from interface PAP
Apr 19 08:58:58.339: Vi1 PAP: Using password from interface PAP
Apr 19 08:58:58.339: Vi1 PAP: O AUTH-REQ id 156 len 25 from "USER"
Apr 19 08:58:58.339: Vi1 CHAP: O CHALLENGE id 151 len 23 from "R2"
Apr 19 08:58:58.363: Vi1 PAP: I AUTH-ACK id 156 len 5
Apr 19 08:58:59.251: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down

Como se puede apreciar se ha perdido la conexión. Para reestablecerla en R2 se debe configurar contra qué se contrastará la información de autentificación que envíe R1 (CHAP utiliza por defecto el hostname del router como usuario, por ende sólo faltaría el password).

R2(config)#username R1 password cisco

R1 a su vez puede configurar la credencial a enviar configurando el usuario R2 dado wue es el usuario por defecto a utilizar.

R1(config)#username R2 password cisco
R1(config)#
Apr 19 09:04:08.668: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
R1(config)#

O bien puede configurar el password con ppp chap password. Si se desea modificar el usuario se puede hacer con: ppp chap hostname.

R1(config)#interface Virtual-Template2
R1(config-if)#ppp chap password cisco
R1(config-if)#
Apr 19 09:07:04.924: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
R1(config-if)#

Por último notar que existen otros protocolos de autentificación como EAP (Extensible Authentication Protocol, RFC 3748).

R1(config-if)#ppp authentication ?
chap        Challenge Handshake Authentication Protocol (CHAP)
eap         Extensible Authentication Protocol (EAP)
ms-chap     Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)
ms-chap-v2  Microsoft CHAP Version 2 (MS-CHAP-V2)
pap         Password Authentication Protocol (PAP)

Para EAP se debe señalar explícitamente con ppp eap local que se utilizarán los usuarios locales configurados en el router para contrastar los intentos de autentificación. A su vez en el router que se autentifica, el usuario y password a enviar se configuran con ppp eap identity y ppp eap password respectivamente.

Links de interés:

Troubleshooting PPP (CHAP or PAP) Authentication (Cisco)
Configuring and Troubleshooting PPP Password Authentication Protocol (PAP) (Cisco)
Ooooo… You Want Me to Authenticate WHAT??? (Scott Morris)
PPP Authentication Using the ppp chap hostname and ppp authentication chap callin Commands (Cisco). En particular notar; Treating connection as a callin - Treating connection as a callout vs Treating connection as a dedicated line en los ejemplos de este post.

Doble NAT?

2010-04-13T11:48:00.005-04:00

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 Sw itching 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

BGP Trust

2010-04-09T16:19:00.000-04:00

En las dos últimas semanas se han visto dos sucesos que han impactado Internet y su origen proviene de China.

El primero suceso se debe a que China Telecommunications Corporation (ASN 23724), un ISP que normalmente anuncia 40 prefijos anunció alrededor de 37.000 prefijos por un lapso de 15 minutos, que luego su upstream provider China Telecom (ASN 4134) propagó mundialmente. El inconveniente es que obviamente estos prefijos no le pertenecían por ende se convirtió en un blackhole para un sinnúmero de paquetes. Más detalles en; Chinese ISP hijacks the Internet.

Esto se suma a lo que sucedió reciéntemente a nivel de DNS donde uno de los 13 root name server comenzó a resolver hostnames con direcciones IP's inválidas. Cada uno de estos root name servers tienen múltiple fuentes alredeor del globo, en particular el server "i" tienen una fuente que es sólo visible en China y que se encarga de filtrar diversos web sites para ese país. Sin embargo por unos días China Internet Network Information Center (ASN 24151) lo hizo visible fuera de las fronteras de este país afectando a aquellas compañías que resuelven con este servidor. NIC Chile fue quién dio cuenta de ésto, su anuncio oficial se encuentra en; Comportamiento anómalo DNS del 24/03/2010. Los detalles de qué sucedió se pueden encontrar en; Accidentally Importing Censorship.

CCIE R&S Lab Checklist

2010-03-28T05:59:00.005-03:00

Extracto de: CCIE Routing and Switching Lab Exam Checklist.

1.0	Implementing Layer 2 Technologies Configuring and Troubleshooting Layer 2 Technologies
1.01	Frame Relay
1.01.1	Frame Relay Multipoint Links on a Physical Interface Using Inverse ARP
1.01.2	Frame Relay Multipoint Links on a Physical Interface Without Using Inverse ARP
1.01.3.	Frame Relay Multipoint Link on a Subinterface Using Inverse ARP
1.01.4.	Frame Relay Multipoint Link on a Subinterface Without Using Inverse ARP
1.01.5.	Frame Relay Point-to-Point Subinterfaces
1.01.6.	PVC with a Multipoint Interface on One Side and a Subinterface on the Other Side
1.01.7.	Authentication on a Frame Relay Link Using PPP
1.2	Catalyst Configuration
1.2.01.	Trunks Using an Industry-Standard Encapsulation
1.2.02.	Trunks Using a Cisco Proprietary Encapsulation
1.2.03.	Creating, Deleting, and Editing VLANs
1.2.04.	VTP in Client/Server Mode
1.2.05.	VTP in Transparent Mode
1.2.06.	VTP Authentication
1.2.07.	VTP Pruning
1.2.08.	Controlling VLANs That Cross a Trunk
1.2.09.	Optimizing STP by STP Timers
1.2.10.	PortFast
1.2.11.	Loop Guard
1.2.12.	BPDU Guard
1.2.13.	BPDU Filters
1.2.14.	UplinkFast
1.2.15.	BackboneFast
1.2.16.	MSTP
1.2.17.	Selecting the Root Bridge for VLANs in a PVST Environment
1.2.18.	Selecting the Root Bridge for an MST Instance in an MST Environment
1.2.19.	Setting the Port Priority to Designate the Forwarding Ports
1.2.20.	EtherChannel Using an Industry-Standard Protocol
1.2.21.	EtherChannel Using a Cisco Proprietary Protocol
1.2.22.	Disabling Protocols on the EtherChannel
1.2.23.	Load-Balancing Type on the EtherChannel
1.2.24.	SNMP Management on the Switch
1.2.25.	Telnet and SSH Management on the Switch
1.2.26.	Controlling Inbound and Outbound Telnet on the Switch
1.2.27.	Regular and Smart Macros
1.2.28.	Switch Banners
1.2.29.	UDLD
1.2.30.	Switch Virtual Interfaces (SVIs) for IP Routing
1.2.31.	Router on a Stick
1.2.32.	SPAN
1.2.33.	RSPAN
1.2.34.	IP Routing on the Switch Using RIPv2, EIGRP, OSPF, and BGP
1.2.35.	IP Phones to Connect to the Catalyst Switch
1.2.36.	Dot1q Tunneling
1.3	Other Layer 2 Technologies
1.3.1.	HDLC
1.3.2.	PPP
1.3.3.	PPP over Ethernet
2.0	Implementing IPv4 Configuring and Troubleshooting IPv4
2.1.	IPv4 Addressing
2.1.1.	IPv4 Addressing
2.1.2.	IPv4 Subnetting
2.1.3.	IPv4 VLSM
2.2.	OSPFv2
2.2.01.	OSPF on a Broadcast Multicast Access Network (Ethernet)
2.2.02.	OSPF over a Frame Relay Multipoint Network by Changing Network Types
2.2.03.	OSPF over a Frame Relay Multipoint Network by Using the neighbor Command
2.2.04.	OSPF over a Frame Relay Point-to-Point Network
2.2.05.	Virtual Links
2.2.06.	Stub Areas
2.2.07.	Totally Stubby Areas
2.2.08.	NSSA Areas
2.2.09.	NSSA and Stub Areas
2.2.10.	NSSA and Totally Stubby Areas
2.3.	EIGRP
2.3.1.	Basic EIGRP
2.3.2.	Passive Interfaces
2.3.3.	EIGRP Stub on Routers and Switches
2.3.4.	EIGRP Update—Bandwidth Control
2.3.5.	Changing the Administrative Distance of EIGRP
2.3.6.	Unequal-Cost Load Balancing for EIGRP
2.4.	Filtering, Redistribution, and Summarization
2.4.01.	Route Filtering for OSPF Within the Area Using a Distribute List with an ACL and Prefix Lists
2.4.02.	Route Filtering for OSPF Between Areas
2.4.03.	Summarization of OSPF Routes Between Areas
2.4.04.	Summarization of External Routers Within OSPF
2.4.05.	Filtering with a Distribute List Using an ACL and Prefix Lists
2.4.06.	Using Advanced ACLs and a Prefix List for Filtering Routes
2.4.07.	Summarizing Routes with EIGRP
2.4.08.	Route Summarization for RIP
2.4.09.	Redistribution Between OSPF and EIGRP
2.4.10.	Redistribution Between RIP and EIGRP
2.4.11.	Redistribution of Directly Connected Routes
2.4.12.	Redistribution of Static Routes
2.4.13.	Redistribution with Filtering Using ACLs and Prefix Lists
2.4.14.	Redistribution with Filtering Using Route Tagging
2.5.	IBGP
2.5.1.	IBGP Peering
2.5.2.	Advertising Routes in BGP
2.5.3.	Next-Hop Attribute
2.5.4.	Route Reflectors
2.5.5.	Redundancy by Neighbor Relationships Based on Loopbacks
2.6.	EBGP
2.6.1.	EBGP Peering
2.6.2.	EBGP Peering Based on Loopbacks
2.7.	BGP Advanced Features
2.7.01.	Filtering Using ACLs
2.7.02.	Filtering Using Prefix Lists
2.7.03.	Filtering Using AS Path Filters
2.7.04.	Redistributing Connected Routes into BGP
2.7.05.	Redistributing Dynamic Routing Protocols into BGP
2.7.06.	BGP Aggregation
2.7.07.	BGP Aggregation with the Summary Only Parameter
2.7.08.	BGP Aggregation with Suppress Maps
2.7.09.	BGP Aggregation with Unsuppress Maps
2.7.10.	BGP Best-Path Selection – Weight
2.7.11.	BGP Best-Path Selection – Local Preference
2.7.12.	BGP Best-Path Selection – MED
2.7.13.	BGP Communities – No-Export
2.7.14.	BGP Communities – No-Advertise
2.7.15.	BGP Confederation
2.7.16.	BGP Local AS
2.7.17.	Working with Private AS Numbers
2.7.18.	Route Dampening
2.7.19.	Conditional Advertising
2.7.20.	Peer Groups
3.0	Implementing IPv6 Configuring and Troubleshooting IPv6
3.1.	IPv6
3.1.1.	IPv6 Addresses
3.1.2.	OSPFv3
3.1.3.	EIGRPv6
3.1.4.	IPv6 Tunneling
3.1.5.	IPv6 on a Frame Relay Network – Multipoint
3.1.6.	IPv6 on a Frame Relay Network – Point-to-Point
3.1.7.	Route Filtering with a Distribute List Using an ACL and Prefix Lists
3.1.8.	Route Redistribution Between OSPFv3 and EIGRPv6
4.0	Implementing MPLS Configuring and Troubleshooting MPLS
4.1.	MPLS Unicast Routing
4.1.1.	MPLS Unicast Routing Using LDP
4.1.2.	Controlling Label Distribution
4.2.	MPLS VPN
4.2.1.	MPLS VPN Using Static Routing Between PE-CE
4.2.2.	MPLS VPN Using EIGRP as the PE-CE Routing Protocol
4.2.3.	MPLS VPN Using OSPF as the PE-CE Routing Protocol
4.2.4.	MPLS VPN Using EBGP as the PE-CE Routing Protocol
4.2.5.	Controlling Route Propagation Using the Route Target with Import and Export Maps
4.3.	VRF-Lite
4.3.1.	VRFs at the Customer Sites Using VRF-Lite
5.0	Implementing IP Multicast Configuring and Troubleshooting IP Multicast
5.1.	PIM and Bidirectional PIM
5.1.1.	PIM Dense Mode
5.1.2.	PIM on an NMBA Network
5.1.3.	PIM Sparse Mode – Static Rendezvous Point
5.1.4.	PIM Sparse Mode – Multiple Static Rendezvous Points
5.1.5.	PIM Sparse Mode – Auto Rendezvous Point
5.1.6.	PIM Sparse Mode with Multiple Rendezvous Points Using the Auto Rendezvous Point
5.1.7.	Bidirectional PIM
5.2.	MSDP
5.2.1.	MSDP
5.2.2.	MSDP to an Anycast Rendezvous Point
5.3.	Multicast Tools
5.3.1.	Multicast Rate Limiting
5.3.2.	IGMP Filtering on the Switch
5.3.3.	Use of the Switch to Block Multicast Traffic
5.3.4.	Multicasting Through a GRE Tunnel
5.3.5.	Multicast Helper Address
5.4.	IPv6 Multicast
5.4.1.	IPv6 Multicast Routing Using PIM
5.4.2.	IPv6 Multicast Listener Discovery (MLD) Protocol
6.0	Implementing Network Security Configuring and Troubleshooting Network Security
6.1.	AAA and Security Server Protocols
6.1.1.	Use of a Router to Authenticate Against a AAA Server Using TACACS+
6.1.2.	Use of a Router to Authenticate Against a AAA Server Using RADIUS
6.1.3.	Local Privilege Authorization
6.1.4.	Accounting to a AAA Server Using TACACS+
6.1.5.	Accounting to a AAA Server Using RADIUS
6.2.	Access Lists
6.2.1.	Standard Access Lists
6.2.2.	Extended Access Lists
6.2.3.	Time-Based Access Lists
6.2.4.	Reflexive Access Lists
6.3.	Routing Protocol Security
6.3.1.	Routing Protocol Authentication for EIGRP
6.3.2.	Routing Protocol Authentication for OSPF – Area-Wide
6.3.3.	Routing Protocol Authentication for OSPF – Interface-Specific
6.3.4.	Routing Protocol Authentication for OSPF Virtual Links
6.3.5.	Routing Protocol Authentication for BGP
6.4.	Catalyst Security
6.4.1.	Storm Control
6.4.2.	Switch Port Security
6.4.3.	Dot1x Authentication
6.4.4.	Dot1x Authentication for VLAN Assignment
6.4.5.	VLAN Access Maps
6.4.6.	DHCP Snooping
6.4.7.	DAI
6.4.8.	IP Source Guard
6.4.9.	Private VLANs
6.5.	Cisco IOS and Zone-Based Firewalls
6.5.1.	Basic Cisco IOS Firewall
6.5.2.	DoS Protection on a Cisco IOS Firewall
6.5.3.	Basic Zone-Based Firewall
6.5.4.	Zone-Based Firewall with Deep Packet Inspection
6.6.	NAT
6.6.1.	Dynamic NAT
6.6.2.	PAT
6.6.3.	Static NAT
6.6.4.	Static PAT
6.6.5.	Policy-Based NAT
6.7.	Other Security Features
6.7.1.	Configuring the TCP Intercept Feature
6.7.2.	Configuring Blocking of Fragment Attacks
6.7.3.	Configuring Switch Security Features
6.7.4.	Configuring Antispoofing Using an ACL
6.7.5.	Configuring Antispoofing Using uRPF
6.7.6.	SSH on Routers and Switches
6.7.7.	Cisco IOS IPS
6.7.8.	Controlling Telnet and SSH Access to the Router and Switch
7.0	Implementing Network Services Configuring and Troubleshooting Network Services
7.1.	DHCP
7.1.1.	Configuring DHCP on a Cisco IOS Router
7.1.2.	Configuring DHCP on a Switch
7.1.3.	Using a Router and a Switch to Act as a DHCP Relay Agent (Helper Address)
7.2.	HSRP
7.2.1.	HSRP Between Two Routers
7.2.2.	Pre-empt for HSRP
7.2.3.	Authentication for HSRP
7.2.4.	VRRP
7.2.5.	GLBP
7.3.	IP Services
7.3.1.	Use of the Router for WCCP
7.3.2.	Use of the Router to Generate an Exception Dump Using TFTP
7.3.3.	Use of the Router to Generate an Exception Dump Using FTP
7.3.4.	Use of the Router to Generate an Exception Dump Using RCP
7.3.5.	Broadcast Forwarding for Protocols
7.4.	System Management
7.4.1.	Telnet Management on the Router and Switch
7.4.2.	SSH Management on the Router and Switch
7.4.3.	Disabling Telnet and the SSH Client on the Switch
7.4.4.	HTTP Management on the Router and Switch
7.4.5.	Controlling HTTP Management on the Router and Switch
7.5.	NTP
7.5.1.	NTP Using the NTP Master and NTP Server Commands
7.5.2.	NTP Without Using the NTP Server
7.5.3.	NTP Using NTP Broadcast Commands
8.0	Implementing QoS Configuring and Troubleshooting QoS
8.1.	Classification
8.1.1.	Marking Using DSCP
8.1.2.	Marking Using IP Precedence
8.1.3.	Marking Using CoS
8.2.	Congestion Management and Congestion Avoidance
8.2.1.	Priority Queuing
8.2.2.	Custom Queuing
8.2.3.	Weighted Fair Queuing
8.2.4.	WRED
8.2.5.	RSVP
8.3.	Policing and Shaping
8.3.1.	CAR Using Rate Limiting Under the Interface
8.3.2.	Frame Relay Traffic Shaping Using Map Classes
8.3.3.	Discard Eligible List
8.4.	Link Efficiency Mechanisms
8.4.1.	Compression
8.4.2.	Link Fragmentation and Interleaving (LFI) for Frame Relay
8.5.	Modular QoS CLI
8.5.1.	Policing
8.5.2.	Class-Based Weighted Fair Queuing (CB-WFQ)
8.5.3.	Low Latency Queuing (LLQ)
8.5.4.	Shaping Using MQC
8.5.5.	Random Early Detection Using MQC
8.5.6.	WRED Using MQC
8.5.7.	Using NBAR for QoS
8.5.8.	Discard Eligible Marking Using MQC
8.6.	Catalyst QoS
8.6.1.	WRR on the Catalyst Switch
9.0	Troubleshooting a Network Troubleshooting Network-Wide Connectivity Issues
9.1.	Troubleshooting Layer 2 Problems
9.1.1.	Troubleshooting Catalyst Switch Network Issues
9.1.2.	Troubleshooting Frame Relay Network Issues
9.2.	Troubleshooting Layer 3 Problems
9.2.1.	Troubleshooting IP Addressing Network Issues
9.2.2.	Troubleshooting Routing Protocol Network Issues
9.2.3.	Troubleshooting Routing Protocol Loop Issues
9.3.	Troubleshooting Application Problems
9.3.1.	Determining Which Aspects of the Network to Troubleshoot to Determine Network Functionality (Given a Set of Symptoms)
9.4.	Troubleshooting Network Services
9.4.1.	Troubleshooting Misconfigured NTP Setup
9.4.2.	Troubleshooting Misconfigured DHCP Setup
9.4.3.	Troubleshooting Misconfigured Telnet and SSH Setup
9.4.4.	Troubleshooting Misconfigured SNMP Setup
9.5.	Troubleshooting Security Services
9.5.1.	Troubleshooting Misconfigured ACLs
9.5.2.	Troubleshooting Misconfigured NAT
9.5.3.	Troubleshooting Misconfigured AAA Services
10.0	Optimizing a Network Configuring and Troubleshooting Optimization of a Network
10.1.	Logging In
10.1.1.	Logging into a Remote Syslog Server
10.1.2.	Logging into the Internal Buffer
10.2.	SNMP
10.2.1.	Use of a Router to Communicate to an SNMP Management Station
10.2.2.	Use of a Router to Generate SNMP Traps
10.3.	RMON
10.3.1.	Use of a Router to Generate SNMP Traps Using RMON
10.4.	Accounting
10.4.1.	IP Accounting
10.5.	SLA
10.5.1.	IP SLA
10.6.	Implementing Network Services on the Routers
10.6.1.	Use of a Router as an FTP Server
10.6.2.	Use of a Router as a TFTP Server
10.6.3.	Cisco IOS Embedded Event Manager
10.6.4.	NetFlow
10.6.5.	HTTP and HTTPS on a Router
10.6.6.	Telnet on a Router
10.6.7.	Implementing Secure Copy Protocol (SCP) on a Router

IPexpert hizo algunos cometarios en: Cisco Announces “Detailed Checklist” for Multiple CCIE Tracks.