From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Chapter 9

474 Words. Plan about 3 minute(s) to read this.

There are a number of commands used to configure EIGRP. Many of these were discussed in the previous EIGRP posts, but here’s a more complete review.

  • “router eigrp x” starts up an EIGRP process, where “x” is the autonomous system.
    • “network 172.16.0.0 0.0.1.255” would enable EIGRP on all interfaces with IP addresses falling within the range of 172.16.0.0 – 172.16.1.255.
    • “metric weights” allows you to tweak the K values used in EIGRP metric computation.
    • “passive-interface” prevents EIGRP hellos from being sent on a particular interface. In effect, inbound hellos are ignored as well.
    • “eigrp stub” makes the router a stub router. Stub routers announce themselves as such to neighbors. There are options of:
      • connected – advertise connected routes with matching network statements.
      • summary – advertise auto-summarized routes or statically configured summary routes.
      • static – advertise static routes, assuming you’re redistributing static routes into EIGRP.
      • redistributed – advertise redistributed routes, assuming you’re redistributing.
      • receive-only – don’t advertise any routes. This one has to be used by itself.
    • “variance” allows you to install 2 routes to the same destination into the routing table, as long as their computed metric is “pretty close” as defined by the variance command.
    • “maximum-paths” allows you to define how many equal-cost routes can be installed in the routing table, up to 6 with a default of 4.
    • “traffic-share balanced” balances across the multiple routes, giving more packets to lower-metric routes.
    • “traffic-share min” sends traffic only to the lowest-metric route, despite mutliple routes being in the routing table.
    • “traffic-share balanced across-interfaces” will cause the router will forward via different physical interfaces if possible, for better load balancing.
    • And if there is no “traffic-share” command you’ve configured, EIGRP will balance evenly across the routes in the routing table, with no regard for the specific EIGRP metric.
  • In the “interface” paragraph, there are a number commands impacting EIGRP.
    • “bandwidth” will be used in the metric computation.
    • “ip bandwidth-percent eigrp” limits the amount of bandwidth EIGRP traffic an utilize. That computation is based on defined bandwidth, so if you’ve artificially lowered the bandwidth as a way of tweaking the route metric, you can define that percentage over 100%.
    • “ip hello-interval eigrp” defines how many seconds in between hellos on this interface. This is an advertised value. EIGRP neighbors know to expect this interval.
    • “ip hold-time eigrp” defines how long to wait for contact from a neighbor before considering the neighbor dead, 3x the hello-interval by default.

It’s also good to note that like RIP (studied in the last chapter) and other protocols not yet discussed in the OECG, you can perform MD5 authentication (although not plaintext, which RIP does support), route filtering with distribute lists, offset-lists to tweak metrics, autosummarization which can be disabled with “no auto-summary”, and disablement of split-horizon with “no ip split-horizon eigrp”. You can also force eigrp to relear everything in his topology table with “clear ip eigrp neighbor”.