Showing posts with label EIGRP. Show all posts
Showing posts with label EIGRP. Show all posts

Sunday, 18 November 2012

Differences between EIGRP for IPv4 and IPv6


  1. Configured on interface
  2. Must no shut the routing process
  3. 32-bit router ID
  4. Passive interface
  5. Route filtering: only distribute-list prefix-list
  6. Automatic summarisation
  7. Cisco IOS support: 12.4(6)T
  8. No auto-summary, as there is no classful concept anymore
CCIE Routing and Switching Certification Guide (4th edition)

Sunday, 4 November 2012

EIGRP Interface Load (K2)

EIGRP routing updates are triggered only by a change in network topology (interface up/down event, IP addressing change or configured bandwidth/delay change) and not by change in interface load or reliability. The load/reliability numbers are thus a snapshot taken at the moment of the topology change and should be ignored.

http://blog.ioshints.info/2009/06/eigrp-load-and-reliability-metrics.html

EIGRP routing over DMVPN (mGRE)

On Hub:

  • Disable as-member split-horizon
  • Disable as-member next-hop-self


Saturday, 3 November 2012

EIGRP traffic-share min

when you use the traffic-share command with the keyword min, the traffic is sent only across the minimum-cost path, even when there are multiple paths in the routing table. This is identical to the forwarding behaviour without use of the variance command. However, if you use the traffic-share min command and the variance command, even though traffic is sent over the minimum-cost path only, all feasible routes get installed into the routing table, which decreases convergence times.



  1. traffic-share balanced (default):
    1. Variance=1 (default):
      1. Traffic will be sent to successor(s) only (equal cost load balancing).
      2. Feasible successors are kept in EIGRP topology table.
      3. Feasible successors are not kept in the routing table.
    2. Variance=2+:
      1. Traffic will be sent to successor(s) and feasible successors(s).
      2. Traffic will be sent inversely proportional to their metrics.
      3. All successor(s) and feasible successor(s) are kept in the routing table.
  2. traffic-share min across-interfaces:
    1. Variance=1 (default):
      1. same as (1.1)
    2. Variance=2+:
      1. Traffic will be sent to successor(s) only (equal cost load balancing).
      2. Feasible successors are kept in the routing table.

Monday, 15 October 2012

Init bit in EIGRP Update Packet

Suppose you have Routers A and B, running along fine, for many hours. Router A reloads, but comes back up before Router B's hold timer has expired. When Router B sees A's hellos, it will assume that A just missed a couple, and everything is fine. But everything isn't fine--A just lost all of its routing information! How can A signal this state, and as B to re-synchronize?

A can send an empty update, with the init bit set. This causes Router B to place A in the "pending" state, and wipe out all the information it's learned from A (unless, of course, graceful restart is configured/etc).

https://supportforums.cisco.com/thread/50827