Cisco Labbing notes

Static Routes
-specify only the next-hop value; route is valid as long as a route exists for the nexthop value.
-Specify only the local outgoing interface; route is valid as long as the interface is in the UP/UP state.
-Specify both next-hop value and local outgoing interface.
When the third option is selected, the local outgoing interface behaves like a condition for the next-hop value and should be read like: this static route is valid only if the configured next-hop value is reachable over the configured interface, which means as long as the interface is in the UP/UP state and has nothing to do with IP/ARP/NHRP functionality with the next-hop.

When a router receives identical routes (prefix and prefix-length) through multiple routing protocols (static or dynamic), the decision regarding which one gets installed in the routing table is based on the lowest administrative distance; lower AD values have higher preference.

Recursive Routing Error
A recursive routing error is when a lookup for prefix X points at prefix Y for the next-hop, and a lookup for prefix Y points at prefix X for the next-hop. For tunnel interfaces, this occurs when the tunnel destination is dynamically learned through the tunnel interface itself.
In general, there are several solutions to the problem, depending on the IPv4 addressing scheme, routing protocol being used, and network design:

• Do not advertise in the routing protocol the same networks over both the physical/Ethernet path and the tunneling/GRE path.
• Do not advertise in the routing protocol used over the tunneling/GRE path the tunnel endpoints.
• Use route filtering techniques to filter tunnel endpoints IPv4 addresses from being learned over the GRE tunnel.
• Do not use same routing protocol over both the physical and tunneling paths; this is recommended but it requires correct routing protocol configuration.

GRE Tunnel
By default, the state of a point-to-point GRE interface is determined by routing availability for the tunnel destination. Therefore, as long as the router has a route for the tunnel destination, the tunnel interface state will be UP. This, however, does not account for possible transit problems or devices filtering GRE which is IP protocol number 47. To fix the problem, GRE keepalives can be enabled on point-to-point GRE tunnels. GRE keepalives are implemented in such a way that it can be enabled on one side of the tunnel only, which means only that side can track end-to-end GRE connectivity between the tunnel endpoints and update the GRE interface status accordingly.
The state of multipoint GRE tunnel interfaces, such as those used in DMVPN scenarios, cannot be monitored through GRE keepalives, because there is no single destination for the tunnel. The mGRE tunnel interface is always in the UP state.

ODR
On-Demand Routing (ODR) uses Cisco Discovery Protocol (CDP) to advertise connected IPv4 routes of a stub router to the hub. The hub router then advertises a default IPv4 route back to the spokes via CDP. For ODR to be functional, there should be no dynamic routing protocol configured on spokes.

Route Filtering (RIP)
When extended access-lists are used as distribute-list for IGP filtering, the functionality is different than when used for route redistribution or in BGP. With BGP and redistribution, the source field in the ACL represents the network address, and the destination field represents the subnet mask. In IGP distribute-list application, the source field in the ACL matches the update source of the route, and the destination field represents the network address.

The distance command can be used to change the administrative distance globally for the routing process, globally for the routing process per route type (external vs.internal), on a per-prefix basis, or on a per-neighbor per-prefix basis. The two fields after the distance value are the source of the route (RIP speaker) and a wildcard mask to match the source. The value needed for the source is seen in the above output in the from 155.1.37.3 field.
!
access-list 2 permit 150.1.3.3
!
router rip
distance 255 155.1.37.3 0.0.0.0 2
!
----------------------

EIGRP Auto-Summary
With EIGRP auto-summary enabled, VLSM is supported, but only for subnets that are within the same major network boundary(e.g. 192.168.10.0/24 and 192.168.20.0/24 but not 192.168.10.0/25 and 192.168.10.128/25). As network advertisements pass between major network boundaries, they are automatically summarized to their classful mask. The result of this behavior is that EIGRP cannot support discontiguous major networks. Although all of the routers are advertising the classful summary of their Loopback subnet 150.1.0.0/16 to all of their neighbors, each router also installs a local EIGRP summary route to Null0. The end result is that they cannot learn about each other's summaries to 150.1.0.0/16, and reachability is not obtained between these networks.

Summarization
When a summary is configured in EIGRP, all subnets that make up the summary are suppressed from being advertised out the link. From a design perspective, this feature can be used to both reduce the size of the routing table and limit the scope of EIGRP query messages.

The EIGRP leak-map feature of the summary-address allows the advertisement of specific subnets encompassed by the interface-level summary, similar to the unsuppress-map feature of BGP aggregation. Routes matched in the leak-map routemap will be advertised in addition to the summary.

When summaries are created in EIGRP, OSPF, and BGP, the router automatically installs a route to Null0 to match the summary. This is used to prevent the router from forwarding traffic for destinations inside the summary that it does not have a longer match for. However, in certain designs this can be an undesirable behavior. To resolve this, EIGRP sets its interface-level summaries to have an administrative distance of 5 by default. This means that any other route with a distance of 1–4 will take precedence over the summary.

Redistribution
Unlike BGP, filtering with route-maps in IGP is usually limited to redistribution filtering only. However, EIGRP supports route-map filtering as a distribute-list with matches on metric and tag values.
EIGRP uses the router-id field in external routes as a loop prevention mechanism.

EIGRP Composite Metric 
Use "metric weight 0 K1 K2 K3 K4 K5" command. K1 bandwidth and K3 Delay are set to 1; the rest 0 by default.

EIGRP Timers
Unlike OSPF, EIGRP hello and hold-time intervals do not need to match to form adjacencies. Just like OSPF, the locally configured Hello interval defines the local rate interval for sending EIGRP hello packets, but the value is not transmitted in EIGRP Hello packets. Unlike OSPF, the locally configured Hold-Time interval defines for how long the remote router will wait for a EIGRP packet before resetting the adjacency, so the value is transmitted in EIGRP Hello packets.

The passive-interface command in EIGRP, like in RIPv2, stops the sending of updates out an interface. Unlike RIPv2, however, passive-interface in EIGRP will prevent forming of an adjacency on the interface because it stops sending EIGRP Hello packets as well, and hence the learning of any updates on the link.