Archive for September, 2008

Timers

• Hello and Dead interval timers are set on a per-interface basis with
  ip hello-interval eigrp <AS> <seconds>
ip hold-time eigrp <AS> <seconds>
• The stuck-in-active (SIA) timer is configured with the router-level command
  timers active-time <seconds|disabled>

Metrics

• The metric calculation in an EIGRP AS can be changed with the router-level command
  metric weight 0 <bandwidth> <load> <delay> <offset> <reliability>
• The metric calculation formula is

  ( ( k1 * bandwidth ) +

    ( k2 * bandwidth ) / ( 256 - load ) +

    ( k3 * delay ) +

    ( k5 / reliability ) +

    k4

  ) * 256

• To configure the hop count considered unreachable (default 100) use router-level command
  metric maximum-hops <count>
• The administrative distance of internal and external routes can be configured using the router-level command
  distance eigrp <internal> <external>

Bandwidth Used for EIGRP

• EIGRP uses 50% of the interface bandwidth by default
• Can be changed using the interface-level command
  ip bandwidth-percentage eigrp <AS> <percent>

Stubs

• A stub can be configured to only receive (not send) routes using the router-level command
  eigrp stub receive-only

Logging

• no eigrp log-neighbor-changes
• eigrp log-neighbor-warning <interval> will log updates that are received from an IP not in the subnet of the receiving interface.

Summary Addresses

• The leak-map option to ip summary-address eigrp references a route-map that defines what component routes of a summary supernet are also injected along side the summary. It is only available on physical and VirtualTemplate interfaces (not on subinterfaces).

Load Balancing

• For unequal-cost load balancing, the AD of the worst route must be less than the FD
• Take the AD of the worst route and divide by the AD of the best route (rounding up) to get the variance.

Authentication

• same as RIP, but configured on a per-interface and per-AS basis
  ip authentication mode eigrp 300 md5

General Notes

• passive-interface default is recommended, due to the network statement being classful
• don’t forget to consider switch-based solutions like vlan access-maps and port access-lists (blocking udp/520) to prevent updates from propagating between routers if the task restricts your configuration options on the routers themselves.
• CCIE Links page updated with RIPv2 links

Timers

• default basic timers are 30/120/120/240 (update, invalid, hold down, flush)
• periodic updates can be delayed after a triggered update with the sleep parameter at the end of the timers basic router command.
• the “hold down” timer is Cisco-proprietary. Set it to 0 if you need to retain full compatibility with RFC 2453.

Distribute Lists

• distribute-list uses a separate ip prefix-list for defining the gateway and the routes

Default Originate

• the route-map option to default-information originate causes the 0/0 route to only be injected into RIP if the route-map is satisfied (e.g. if a route exists)

Multicast / Broadcast / Unicast

• RIPv2 defaults to sending updates via multicast (224.0.0.9)
• The passive-interface and neighbor router commands change it to unicast
• The ip rip v2-broadcast interface command changes it to broadcast
• A very tricky way to force unicast updates without using the neighbor command:

  ip nat outside udp X.X.X.X 520 224.0.0.9 520

  int se0/0/0

    ip nat outside

  This converts the inbound multicast updates to unicast, which will create a NAT table entry and translate all outbound RIP updates to unicast as well (NAT is bidirectional)

Authentication

• IOS 12.4 supposedly requires a valid send-lifetime configured for a key before it will work.
• RIP will always use the first valid key when sending updates out an interface.

Route Filtering

• The three methods to kill a route:
  • distribute-list with an ACL
  • offset-list pushing the metric beyond 16
  • distance command setting the AD to 255

Again, for my own benefit, checklists for the Narbik, IPExpert, and InternetworkExpert v.5 technology-focused workbook labs.

Narbik Book 1

• 3550/3560 — skipping for now
• 3550/3560 QoS — skipping for now
• Frame Relay — done!
• On-demand Routing
• RIP — done!
• EIGRP
• OSPF
• Policy-based Routing
• BGP
• IPv6

Narbik Book 2

• NAT
• IP Services
• GRE
• Multicast
• QOS
• Security
• Prefix-Lists

IPExpert Workbook 1

• General Lab Setup
• Catalyst PVST — skipping for now
• Catlayst MST — skipping for now
• Catalyst Rapid PVST — skipping for now
• Layer 2 Tunneling — skipping for now
• Frame Relay
• Bridging and Frame Relay
• RIP — done!
• EIGRP
• OSPG
• BGP
• Routing Protocol Redistribution
• ACLS and Filters for IP
• Router Security
• Router Redundancy
• Advanced Router Management
• Multicast
• QoS
• QoS/MQC Conversions
• GRE and Routing Protocols
• IPv6
• IPv6 Advanced Routing

InternetworkExpert v.5 Workbook 1

• Bridging and Switching — skipping for now
• Frame Relay
• IP Routing
• RIP
• EIGRP
• OSPF

This is a bit rough, but it’s more or less what I plan to do between now and January to get ready for the R&S lab.

Week of September 8

• Narbik technology labs
• IPExpert technology labs
• InternetworkExpert v.5 technology labs

Week of September 15

• Narbik technology labs
• IPExpert technology labs
• InternetworkExpert v.5 technology labs

Week of September 22

• IPExpert multi-protocol labs #1-5

Week of September 29

• Note:  work travel week
• IPExpert multi-protocol labs #6-10

Week of October 6

• Note:  work travel week
• IPExpert multi-protocol labs #11-15

Week of October 13

• InternetworkExpert workbook 2 full labs, #1-4
• InternetworkExpert workbook 3 core labs, #1-2

Week of October 20

• InternetworkExpert workbook 3 core labs, #3
• InternetworkExpert workbook 2 full labs, #5, 10, 12
• InternetworkExpert workbook 3 core labs, #4, 5

Week of October 27

• InternetworkExpert workbook 2 full labs, #16, 17, 18
• InternetworkExpert workbook 3 core labs, #6-7

Week of November 3

• InternetworkExpert workbook 3 core labs, #8-10
• InternetworkExpert workbook 2 full labs, two or three of #6-10, 11, 14-15, 19-20

Week of November 10

• IPExpert on-site bootcamp

Week of November 17

• IPExpert 5-day mock lab bootcamp

Week of November 24

• Note: Thanksgiving Week
• Review results of IPExpert bootcamp
• InternetworkExpert mock lab #1 and #2

Week of December 1

• IPExpert workbook 3 full labs, #1-4
• InternetworkExpert mock lab #3 and #4

Week of December 8

• IPExpert workbook 3 full labs, #5-8
• CCIE Accessor #1

Week of December 15

• IPExpert workbook 3 full labs, #9-12
• CCIE Accessor #2

Week of December 22

• Note: Christmas Week
• IPExpert workbook 3 full labs, #13-14

Week of December 29

• IPExpert workbook 3 full labs, two or three of #15-20

Week of January 5

• Final Review, travel and exam!

Lab 1: Hub and Spoke using Frame-Relay Map Statements

• On a multipoint interface, the router can’t ping itself unless you add a frame-relay map statement pointing the interface IP to one of the DLCI’s.
• When configuring frame-relay maps on the spokes, don’t use the broadcast keyword for mappings to other spokes.  Otherwise, the hub will get redundant routing information (broadcasts/multicasts).
• The keepalive command controls the LMI Status inquiry interval, and the frame-relay lmi-n391dte command controls the complete status enquiry interval.
• Status inquiries are LMI type 1 inquiries, full status inquiries are LMI type 0 inquiries.

Lab 2: Hub and Spoke using Point-to-Point Subinterfaces

• No need to manually disable inverse-arp when using subinterfaces.
• On a point-to-point interface, the router can reach all IP addresses (including itself) without a mapping, as long as the IP is in the routing table with a valid next hop.

Lab 3: Mixture of Point-to-Point and Multipoint Frame Relay

No notes.

Lab 4: Multipoint Frame Relay without Frame Relay Mapping

Using PPP between spoke and hub to distribute layer 3 information

! Hub
int serial1/0
  encap frame
  no ip address
  frame-relay interface-dlci 102 ppp Virtual-Template 1
  frame-relay interface-dlci 103 ppp Virtual-Template 1
  frame-relay interface-dlci 104 ppp Virtual-Template 1
!
int virtual-template 1
  ip address 150.0.0.1 255.255.255.0
!

! Spoke 2
int serial1/0
  encap frame-relay
  no ip address
  frame-relay interface-dlci 201 ppp Virtual-Template 2
!
int Virtual-Template 2
  ip address 150.0.0.2 255.255.255.0
!

• The virtual template ID must be different on each spoke, even though it’s the same on all DLCIs on the hub.

Lab 5:  Frame Relay and Authentication

• Yeah, I need to deep-dive on PPP authentication.  Very, very weak here.

Lab 6:  Frame Relay End-to-End Keepalive

map-class frame-relay FREEK12
 frame-relay end-to-end keepalive mode bidirectional
!
int ser1/0.12 point-to-point
 frame-relay interface-dlci 102
  class FREEK12
!

Timers that can be used to adjust FREEK:

frame-relay end-to-end keepalive [send|receive]

• timer
• error-threshold — how many failures must occur before the interface goes down
• success-events — how many successes must occur before the interface comes up
• event-window — how many recent events to consider when testing error-threshold or success-events

• PacketLife:  OSPFv3 and IPv6 - nice intro to configuring OSPFv3
• IOS Hints and Tips:  Sending an Email After a  Router Reload - using EEM
• 6200 Networks:  Cisco Security Deep Dive Portal - presentations from Cisco Sales

Real-life and work have continued to intrude on my preparation hours, but hopefully that’s about to change.  I now have the beginnings of a week-by-week strategy for labs and other prep tasks with enough slack to adjust for unexpected things popping up.

Haven’t done much lab work at all, but I have managed to get some reading done along with reviewing some video-on-demand:

Ongoing Reading:  QoS Exam Certification Guide (Odom)

Ad Hoc Reading:  Routing TCP/IP, Volume 1 (Doyle):  RIP, EIGRP

Video Lectures:  IPExpert EIGRP, RIP, IP Services, TCL, Access Lists

Assuming things go according to plan, this week and next will be spent working through the Narbik technology labs and (depending on time) some of the InternetworkExpert v5 labs.  Planning to use Dynamips for 100% of this, except for the switching stuff.  Will probably do at least one rack rental either next weekend or the weekend after to catch up on those.