IPv6 Will Make You Think Differently: We Don't Need No Stinking FHRP

I got into a discussion about the availability of HSRP for IPv6 being in higher end Cisco platforms but not the lower ones.  I didn't think too much of the question when first saw it, but in reading up on IPv6 last night I came across some of the details in Neighbour Discovery that I thought might be a good replacement.  Deep within RFC 2461 lies section 6.3.6:

6.3.6.  Default Router Selection

   The algorithm for selecting a router depends in part on whether or
   not a router is known to be reachable.  The exact details of how a
   node keeps track of a neighbor's reachability state are covered in
   Section 7.3.  The algorithm for selecting a default router is invoked
   during next-hop determination when no Destination Cache entry exists
   for an off-link destination or when communication through an existing
   router appears to be failing.  Under normal conditions, a router
   would be selected the first time traffic is sent to a destination,

   with subsequent traffic for that destination using the same router as
   indicated in the Destination Cache modulo any changes to the
   Destination Cache caused by Redirect messages.

   The policy for selecting routers from the Default Router List is as
   follows:

     1) Routers that are reachable or probably reachable (i.e., in any
        state other than INCOMPLETE) SHOULD be preferred over routers
        whose reachability is unknown or suspect (i.e., in the
        INCOMPLETE state, or for which no Neighbor Cache entry exists).
        An implementation may choose to always return the same router or
        cycle through the router list in a round-robin fashion as long
        as it always returns a reachable or a probably reachable router
        when one is available.

     2) When no routers on the list are known to be reachable or
        probably reachable, routers SHOULD be selected in a round-robin
        fashion, so that subsequent requests for a default router do not
        return the same router until all other routers have been
        selected.

        Cycling through the router list in this case ensures that all
        available routers are actively probed by the Neighbor
        Unreachability Detection algorithm.  A request for a default
        router is made in conjunction with the sending of a packet to a
        router, and the selected router will be probed for reachability
        as a side effect.

     3) If the Default Router List is empty, assume that all
        destinations are on-link as specified in Section 5.2.

Let's take a look at how we can use this to our advantage.

What the Heck is EIGRP Named Configuration?

While doing some MPLS labbing this week I came across something that I'd never seen before.  I decided that I wanted to use EIGRP as my PE-CE routing protocol, and I was using one router to simulate 4 CE's.  My line of thinking was that I'd just create four VRFs and it'd be no problem.  For some reason it never occurred to me that I could use 4 separate EIGRP instances in my config...  I instead just assumed that I could do a VRF aware EIGRP config without any trouble.  Well, I was wrong.  At least I was wrong in the way I originally tried to get it working.  So after a 'no router eigrp 1' I headed over to the DocCD and found me some EIGRP Named Configuration.

Tips and Tricks: Saving Device Configs with Mac OS X Terminal

One of the age old techniques to save your device config is to simply issue a "sh run" (or equivalent on non-Cisco devices) and copy and paste the resulting output into a text file.  This method certainly works in the absence of at TFTP server, but it's kind of a pain and when you have a few devices it becomes time consuming in a hurry.

In a Windows environment I use PuTTY.  PuTTY has a built in feature that allows you to save the terminal session you're working on.   At home I have a Mac.  To that end, here's how I save configs if there isn't a TFTP server available.

How IOS Cheats When Using the Network Command

When you type a command into the IOS CLI you normally expect IOS to execute your instruction as typed.  You don't expect IOS to modify what you typed, or to assume you meant something other than what you actually typed in.  In fact, to me that behavior is extremely undesirable.  I understand there are some assumed defaults where if you omit certain keywords then IOS imposes on for you.  That's fine.  But sometimes IOS changes what you typed in to something completely different.  The network command contains one such example.