CCIE en Español

The INE 2012 Scholarship

2012-04-30T19:30:00.001-04:00

Inmejorable oportunidad para prepararse para el CCIE!!. Todos los detalles en: http://www.ine.com/ccie-scholarship.htm.

As part of Brian Dennis' and Brian McGahan’s ongoing commitment to the CCIE community, INE is pleased to announce the INE 2012 Scholarship.

For CCIE Routing & Switching applicants, we will be choosing a scholarship recipient per region (Africa, Asia, Canada, Europe, Middle East, North America (US/Mexico), Oceanic (Australia) and South America) from the applicant pool. For those interested in CCIE Voice Training, we will be choosing two recipients from around the world. INE is providing a total of 10 CCIE Training Scholarships valued at $120,000!

The scholarship recipients will each receive CCIE Lab training from start to finish including:

2 Year All Access Pass (access to all of our videos)
1500 Tokens for Rack Rentals or Mock Labs Exams
CCIE Lab Exam Voucher (value $1500 to $1800)
Complete Set of CCIE Workbooks
Live Onsite 10-Day Bootcamp Seat

Eligibility Requirements

Ability to travel.
Must be 18 years of age or older.
CCIE Written exam passed or scheduled.

CCIE Data Center

2012-03-20T10:50:00.002-03:00

Se anunció este nuevo track de CCIE: https://learningnetwork.cisco.com/community/certifications/ccie_data_center

CCIE Data Center Lab Exam Topics

The CCIE Data Center lab exam topics provided are general guidelines for the content likely to be included on the lab exam. However, other related topics may also appear on any specific delivery of the exam. In order to better reflect the contents of the exam and for clarity purposes, the guidelines below may change at any time without notice.

Cisco Data Center Infrastructure - NXOS

Implement NXOS L2 functionality
Implement VLANs and PVLANs
Implement Spanning-Tree Protocols
Implement Port-Channels
Implement Unidirectional Link Detection (UDLD)
Implement Fabric Extension via the Nexus family

Implement NXOS L3 functionality
Implement Basic EIGRP in Data Center Environment
Implement Basic OSPF in Data Center Environment
Implement BFD for Dynamic Routing protocols
Implement ECMP
Implement FabricPath

Implement Basic NXOS Security Features
Implement AAA Services
Implement SNMPv3
Configure IP ACLs, MAC ACLs and VLAN ACLs
Configure Port Security
Configure DHCP Snooping
Configure Dynamic ARP Inspection
Configure IP Source Guard
Configure Cisco TrustSec

Implement NXOS High Availability Features
Implement First-Hop Routing Protocols
Implement Graceful Restart
Implement nonstop forwarding
Implement Port-channels
Implement vPC and VPC+
Implement Overlay Transport Protocol (OTV)

Implement NXOS Management
Implement SPAN and ERSPAN
Implement NetFlow
Implement Smart Call Home
Manage System Files
Implement NTP, PTP
Configure and Verify DCNM Functionality

NXOS Troubleshooting
Utilize SPAN, ERSPAN and EthAnalyzer to troubleshoot a Cisco Nexus problem
Utilize NetFlow to troubleshoot a Cisco Nexus problem
Given an OTV problem, identify the problem and potential fix
Given a VDC problem, identify the problem and potential fix
Given a vPC problem, identify the problem and potential fix
Given an Layer 2 problem, identify the problem and potential fix
Given an Layer 3 problem, identify the problem and potential fix
Given a multicast problem, identify the problem and potential fix
Given a FabricPath problem, identify the problem and potential fix
Given a Unified Fabric problem, identify the problem and potential fix

Cisco Storage Networking

Implement Fiber Channel Protocols Features
Implement Port Channel, ISL and Trunking
Implement VSANs
Implement Basic and Enhanced Zoning
Implement FC Domain Parameters
Implement Fiber Channel Security Features
Implement Proper Oversubscription in an FC environment

Implement IP Storage Based Solution
Implement IP Features including high availability
Implement iSCSI including advanced features
Implement SAN Extension tuner
Implement FCIP and Security Features
Implement iSCSI security features
Validate proper configuration of IP Storage based solutions

Implement NXOS Unified Fabric Features
Implement basic FC in NXOS environment
Implement Fiber channel over Ethernet (FCoE)
Implement NPV and NPIV features
Implement Unified Fabric Switch different modes of operation
Implement QoS Features
Implement FCoE NPV features
Implement multihop FCoE
Validate Configurations and Troubleshoot problems and failures using Command Line, show and debug commands.

Cisco Data Center Virtualization

Manage Data Center Virtualization with Nexus1000v
Implement QoS, Traffic Flow and IGMP Snooping
Implement Network monitoring on Nexus 1000v
Implement n1kv portchannels
Troubleshoot Nexus 1000V in a virtual environment
Configure VLANs
Configure PortProfiles

Implement Nexus1000v Security Features
DHCP Snooping
Dynamic ARP Inspection
IP Source Guard
Port Security
Access Control Lists
Private VLANs
Configuring Private VLANs

Cisco Unified Computing

Implement LAN Connectivity in a Unified Computing Environment
Configure different Port types
Implement Ethernet end Host Mode
Implement VLANs and Port Channels.
Implement Pinning and PIN Groups
Implement Disjoint Layer 2

Implement SAN Connectivity in a Unified Computing Environment
Implement FC ports for SAN Connectivity
Implement VSANs
Implement FC Port Channels
Implement FC Trunking and SAN pinning

Implement Unified Computing Server Resources
Create and Implement Service Profiles
Create and Implement Policies
Create and Implement Server Resource Pools
Implement Updating and Initial Templates
Implement Boot From remote storage
Implement Fabric Failover

Implement UCS Management tasks
Implement Unified Computing Management Hierarchy using ORG and RBAC
Configure RBAC Groups
Configure Remote RBAC Configuration
Configure Roles and Privileges
Create and Configure Users
Implement Backup and restore procedures in a unified computing environment
Implement system wide policies

Unified Computing Troubleshooting and Maintenance
Manage High Availability in a Unified Computing environment
Configure Monitoring and analysis of system events
Implement External Management Protocols
Collect Statistical Information
Firmware management
Collect TAC specific information
Implement Server recovery tasks

Cisco Application Networking Services – ANS

Implement Data Center application high availability and load balancing
Implement standard ACE features for load balancing
Configuring Server Load Balancing Algorithm
Configure different SLB deployment modes
Implement Health Monitoring
Configure Sticky Connections
Implement Server load balancing in HA mode

Nuevo examen CCIE Security

2012-02-02T13:52:00.002-03:00

Extracto de: http://www.cisco.com/cisco/web/solutions/small_business/resource_center/articles/be_more_productive/how_to_become_an_it_security_expert/index.html.

The Real Life of an Expert: Introducing the New CCIE Security

CCIE Security 4.0 is unusual among security certificates for its up-to-date, real-world content. It emphasizes security competency and efficient problem solving in networks that use cloud services, carry voice and multimedia traffic, and are accessed by a variety of wireless devices.

The content, currently in development, may include real-world applications that involve:

Securing both wireless and wired networks, including managing security policy by device and service
Extending application awareness to security devices, moving security up to Layer 7 from the stateless packets of Layers 3 and 4, and applying policy on a per-identity basis
Applying security policy in a network that has voice and video traffic
Securing networks that use managed services, dual ISPs, IPv6, or IP multicast

Cisco will soon announce the blueprints for the CCIE Security 4.0 written and lab exams; the first exam will take place approximately six months later.
Although there are no prerequisites for registration, Cisco offers a preparation path through its CCNA and/or CCNP Security levels, and recommends that candidates have at least three years of hands-on network security experience.

CCIE Mobile Lab en Buenos Aires

2012-02-02T13:46:00.000-03:00

Durante la semana del 5 de marzo del presente año se podrá rendir el examen del CCIE de los tracks de Routing & Switching, Security y Voice en Buenos Aires, Argentina.

Pueden encontrar la lista completa de sitios en esta modalidad Mobile en: https://learningnetwork.cisco.com/docs/DOC-3224. Al día de hoy se informa:

Lab Locations	2012 Dates	Status	Lab
Mexico City, Mexico	Jan 9 - 13	R	Routing & Switching, Security and Voice
Johannesburg, South Africa	Jan 23 - 27	R	Routing & Switching, Security
Bangkok, Thailand	Jan 30 -Feb 3	R	Routing & Switching, Security
Riyadh, Saudi Arabia	Feb 4 - 8	R	Routing & Switching, Security
Sao Paulo, Brazil	Feb 13 - 17	R	Routing & Switching, Security
Cairo, Egypt	Feb 19 - 23	R	Routing & Switching, Security
Buenos Aires, Argentina	Mar 5 - 9	R	Routing & Switching, Security and Voice
Moscow, Russia	Mar 19 - 23	R	Routing & Switching, Security
Seoul, South Korea	Mar 19 - 23	R	Routing & Switching, Security and Voice
Mexico City, Mexico	Apr 2 - 6	R	Routing & Switching, Security and Voice
Istanbul, Turkey	Apr 16 - 20	R	Routing & Switching, Security
Lagos, Nigeria	Apr 30 - May 4	R	Routing & Switching, Security
Moscow, Russia	May 14 - 18	R	Routing & Switching, Security
Johannesburg, South Africa	May 28 - Jun 1	R	Routing & Switching, Security
Singapore, Singapore	Jun 4 - 8	R	Routing & Switching, Security and Voice
Rio de Janeiro, Brazil	Jun 11 - 15	R	Routing & Switching, Security
Toronto, Canada	Jun 18-22	R	Routing & Switching, Security and Voice
Warsaw, Poland	Jun 25 - 29	R	Routing & Switching, Security
Shanghai, PR China	Jul 23 - 27	R	Routing & Switching, Security

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