This Week

Getting down to the wire for my lab attempt (22 days to go!)  I’ve been horrible about blogging my progress, but I’m going to try to be more consistent in the home stretch.  Overall I think I’m in good shape, but I really need to focus over the next 3 weeks to be completely ready.

Plans for this week:

  • IE just released their first v.5 full labs (lab 1 and lab 10).  I’ll probably skip Lab 1, since it’s only a level 5 and I’ve already watched the live Lab Meetup, but I’ll definitely be hitting lab 10 since it’s an 8.
  • I have IE rack rentals Tue-Thu.  My goal is to hit two full IE labs (v.5 lab 10 and probably v.4 lab 7)
  • IPexpert rack rentals Fri, Sat, Sun, Mon.  I want to get some solid lab hours in before the Christmas break.  Haven’t picked a set of labs yet, but at least book 3, labs 9 and 10.
  • I may try to pay for another IE mock lab during my current Christmas break.  My lab 4 attempt went pretty well (77, with a couple of sections I disagreed with the proctor on).
  • Reading:
    • Finish the QoS self-study book
    • Start the Cisco Press multicast and IPv6 books
    • IE workbook 1 v.5 solution guides.  These are terrific for individual technology focus.

InternetworkExpert Vol. 2, Lab 3 Notes

Switching

  • beware of pruning issues when some switches are transparent and some aren’t.  If not otherwise specified, make all switches transparent if one is.

IP Telephony

  • macro apply cisco-phone $access_vlan 5 $voice_vlan 4 sets most things properly
  • To change the CoS applied to traffic coming from the PC connected to a phone: switchport priority extend cos 1
  • Don’t forget to enable mls qos globally or nothing will work

PPP

  • as a general rule, use no peer neighbor-route on all PPP interfaces to avoid random /32 routes showing up in IGPs and redistributions.  They’re only needed if you have different subnets at each end of the link.

IGP’s — RIP

  • use the distribute-list gateway option along with a prefix-list to specify the routers from which we will accept routes.
  • don’t forget the prefix option (e.g. distribute-list prefix FOO not distribute-list FOO when filtering routing updates
  • remember, though, that a distribute-list doesn’t have to use a prefix-list.  It also works just fine with a regular ACL (useful for permit any or deny any).

Getting closer and closer…

What I’ve been up to:

  • IPExpert’s one week R&S bootcamp in San Jose
  • IPExpert’s one week mock lab workshop in San Jose
  • InternetworkExpert’s “Open Lecture” multicast troubleshooting (in progress)
  • InternetworkExpert’s 5-day lab bootcamp CoD (in progress)
  • InternetworkExpert’s Adv. Technology CoD on redistribution (in progress)
  • Working through IEWB3 to get better at core technology, especially redistribution

Study Notes — PPP and PPP Authentication

Sources:

  • IPexpert BLS class-on-demand
  • IPexpert v.10 Workbook 2
  • InternetworkExpert ATS CoD v4.5

Notes — PPP General:

  • By default, PPP will inject a directly-connected /32 route for the remote end into each device’s routing table.  Can be safely disabled unless both ends of the link are not on the same logical IP subnet (e.g. one side or both sides are using ‘ip unnumbered’).  To disable, use the ‘no peer-neighbor-route' interface-level command.
  • The ‘ppp quality‘ interface-level command enables Link Quality Monitoring (LQM), which will bring down the interface if the number of bytes transmitted vs. received over a link falls below a given percentage.
  • The ‘ppp reliable-link‘ command enables LAP-B numbered mode to negotiate a reliable link.

Notes — PPP Multilink

  • The ‘ppp multilink links minimum‘ interface option (under the Multilink interface) specifies how many physical circuits must be up before the bundle comes up.  The ‘mandatory‘ option brings the bundle down if the number of active links falls below the minimum.

Notes — PPP Authentication:

  • The ‘ppp authentication <protocol>‘ command is only required on the side of the link that is issuing the challenge (the “server” side).  This may also be referred to as the side that’s “doing authentication” or that is “authenticating <OtherRouter>”
  • CHAP (and EAP) will use the hostname of the router as the username, by default.  PAP requires the username to be explicitly specified with the ‘ppp pap sent-user‘ command. If you need to use a different username, you can specify it using the ‘ppp chap hostname‘ or ‘ppp eap identity‘ commands.
  • For CHAP, if you don’t want to specify the global username/password combo on the client (or you don’t know the server’s hostname), you can specify just the password to be sent to any remote authentication challenge with the ‘ppp chap password‘ command at the interface level.
  • If you want to use the same username in both directions with CHAP, use the ‘no ppp chap ignoreus‘ interface-level command, since by default CHAP will refuse to authenticate with “ourself” if the hostname matches.
  • EAP is an additional “secure” protocol distinct from CHAP.  MS-CHAP and MS-CHAPv2 probably aren’t “different enough” from CHAP to satisfy a lab requirement of two different secure protocols.
  • You must specify ‘ppp eap local‘ for EAP to work unless you have a radius server available.
  • EAP doesn’t use the shared password from the ‘username‘ statement when responding to a challenge.  You need to specify the password using ‘ppp eap password <pass>

IPExpert End-to-End Bootcamp

I’m in San Jose, CA for IPExpert’s two-week End-to-End route/switch bootcamp.  I was very lucky to win this training at Cisco Networkers this year and am definitely looking forward to it.  The flight out was a bit annoying (flew Airtran instead of Delta and you could really notice the little differences).  Just got back from dinner at Chipotle’s and am planning to take an early night and hopefully get my internal clock synced up.

Narbik/IPExpert Workbook EIGRP Notes

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

Narbik/IPExpert RIPv2 Notes

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

Technology Labs Checklists

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

My CCIE Study Schedule

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!