notes: Cisco 360 Troubleshooting: Ping

basic ping concepts

test reachability, round trip time, packet loss,

note: rtt includes target processing delay.

- icmp echo is type 8, and icmp echo reply is type 0.
"!" means that the reply was received before the timeout expired
". "means that the reply was not received before the timeout expired.
- default 2 second timeout is configurable.
- default packet size is 100 bytes including the ip header.

ping 172.16.105.1 size 1400


I. to check for serial line problems.

- use extended ping to check for framing and clocking problems

ping 172.16.105.1 data 0000 validate
- sends all zeros as the data portion and check for accurate return data.

ping 172.16.105.1 data FFFF validate
- each hexadecimal F is 1111.
- sends a data pattern of all ones and checks for accurate return data.

ping 172.16.105.1 data AAAA validate
- each hexadecimal A is the binary pattern 1010.
- pattern of alternating ones and zeros and checks for accurate return data.

ping 172.16.105.1 size 1500 repeat 999999999 timeout 0
- timeout of zero - wont wait for reply - also good way to test qos


II. Mark traffic using the TOS Byte

set as an 8-bit decimal or hexadecimal

-multiply ip precedence by 32 to get ToS value
- IP precedence is coded in the most significant 3 bits
- IP precedence 5 is ToS value 160 (10100000)

- multiply DSCP by 4 to get Tos Value
- DSCP is coded in the most significant 6 bits
- DSP 46 is ToS 184 (10111000)

to mark traffic at layer 3

to ping using ip precedence of 5

MCMRTR01#ping
Protocol [ip]:
Target IP address: 172.16.11.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.25.254.1
Type of service [0]: 160
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.11.1, timeout is 2 seconds:
Packet sent with a source address of 172.25.254.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 260/261/264 ms

for ef packets:

MCMRTR01#ping
Protocol [ip]:
Target IP address: 172.16.11.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.25.254.1
Type of service [0]: 184
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.11.1, timeout is 2 seconds:
Packet sent with a source address of 172.25.254.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 256/263/276 ms


III. Investigate MTU and fragmentation:

ping 172.16.105.1 size 1501 df-bit

default packet size 100 byes, including 20-byte ip header
try 1500 then 1501

use sweep option with df-bit set
- enter the starting value, ending value and increment between test in bytes


IV. Automate testing with TCL

- tcl or tool command languange is a built-in scripting language
- create a simple script in notepad to ping all of the addresses
-easily capture network ip addresses
show ip alias
press and hold the alt key and drag-select in securecrt
-paste the script into the shell on each router


MCMRTR01(tcl)#foreach address {
+>172.16.11.1
+>172.16.55.1
+>} {ping $address}

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.11.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 260/261/264 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.55.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 120/123/128 ms
MCMRTR01(tcl)#tclquit

notes: Cisco 360 Troubleshooting: IOS commands

advanced show commands option

- filter show commands using the pipe
begin, include, exclude, section
- use end-of-string character ($) to find trailing spaces.
- show running-config interfaces, class-map, policy-map
- filter output of the more command.
- begin (/), include (+), exclude (-)

use the logging buffer

- logging can overwhelm you and the console:

solution:

- no logging console, or terminal no monitor
- logging buffer 100000
- enables log filters such as: show log | include

notes: Troubleshooting RIP

1. Problem: RIP Routes Not in the Routing Table


The possible causes for this problem are as follows:

a. Missing or incorrect network statement
- show ip protocols
- debug ip rip
- show ip route

b. Layer 2 down. - One cause for routes not in the routing table is Layers 1 or 2 being down. If Layers 1 or 2 are down, it's not a RIP problem. The following is a list of the most common things to check if the interface or line protocol is down:
Unplugged cable
Loose cable
Bad cable
Bad transceiver
Bad port
Bad interface card
Layer 2 problem at telco, in case of a WAN link
Missing clock statement, in case of back-to-back serial connection

- show int
- debug ip rip - nothing is being sent if l2 is down.

c. Distribute list blocking the route
- check the acl in the distribute list if the network is allowed or not.

d. Access list blocking RIP source address - access lists may be applied on the interface
- debug ip rip - reveals its not receiving any routes

e. Access list blocking RIP broadcast/multicast - When using access lists on the interface inbound, always make sure that they are not blocking the RIP broadcast or UDP port 520, which is used by RIP-1 and RIP-2 (or the RIP multicast address, in cases of RIP-2).
- rip1 - access-list 100 permit ip host 131.108.1.1 host 255.255.255.255
- rip2 - access-list 100 permit ip host 131.108.1.1 host 224.0.0.9

f. Incompatible version type
- debug ip rip (illegal version)
- sho ip protocols

g. Mismatch authentication key (RIP-2)
- debug ip rip (invalid authentication)

h. Discontiguous network
- solution is to create a static route.
- enable version 2

i. Invalid source - it performs a source-validity check. If the source is not on the same subnet as the local interface, RIP ignores the update and does not install routes in the routing table coming from this source address.
- debupg ip rip (bad source)
- solution "no validate-update-source "

j. Layer 2 problem (switch, Frame Relay, other Layer 2 media)
- debug ip packet 100 detail
access-list 100 permit ip any host 255.255.255.255
access-list 100 permit ip any host 224.0.0.9
- ping 224.0.0.9 is failing
solution: fix the layer 2 problem.

k. Offset list with a large metric defined
- show ip route rip (check the metric on the local router and neigh
- show ip route x.x.x.x
- debug ip rip (inaccessible)
-
j. Routes that reached RIP hop-count limit
- show ip route rip (check the metric on the neighbor router)
- show ip route x.x.x.x
- debug ip rip (inaccessible) on the local router


2. Problem: RIP Is Not Installing All Possible Equal-Cost Paths—Cause: maximum-path Command Restricts RIP from Installing More Than One Path

- By default, Cisco routers support only four equal paths for the purpose of load balancing. The maximum-path command can be used for up to six equal-cost paths. If the command is not configured properly, it can cause a problem, as discussed in this section. When con-figured improperly, the maximum-path command allows only one path to the destination, even though more than one path exists. Configuring the command as maximum-path 1 should be done only when load balancing is not desired.
- debug ip rip

3. Troubleshooting RIP Routes Advertisement

Two of the most prevalent problems that can go wrong on the sender's end deal with RIP route advertisement:

a. Problem: The sender is not advertising RIP routes.

When the routing information differs from one router to the other, one of two possibilities could exist:

• Some routers are not advertising the RIP routes.

• Some routers are not receiving the RIP routes.

this section deals in sending RIP routes.

a.1 Missing or incorrect network statement
- since RIP v1 is a classful network ensure you have a proper network statement.

a.2 Outgoing interface that is down
- show int
- debug ip rip

a.3 distribute-list out blocking the routes
- check the acl used n the distribute-list if the network is allowed or not.

a.4 Advertised network interface that is down
- verify the layer 2 and 1.

a.5 Outgoing interface defined as passive
- show ip protocols.

a.6 Broken multicast capability (encapsulation failure in Frame Relay)
- in a NBMA FR setup. make sure that in the frame-relay map statement the "broadcast"
keyword is present.
- debug ip packet 100 detail ( encapsulation failed: for 255.255.255.255)
access-list 100 permit ip host 131.108.1.1 host 255.255.255.255

a.7 Misconfigured neighbor statement
- the neighbor statement must be configured properly.

a.8 Advertised subnet is VLSM
- RIP1 does not support VLSM solution is to change to version 2.

a.9 Split horizon enabled
3 main uses for disabling split horizon.
- hub and spoke frame relay setup.
- in which a router has an external route that has a next-hop address also known
through some interface where other RIP routers are sitting
- secondary ip address


b. Subnetted routes are missing. Cause: Autosummarization Feature Is Enabled
- In RIP-1, this is not a problem because RIP-1 is a classful protocol and the network should
be designed with this understanding. With RIP-2, however, Cisco routers can be configured
to stop the autosummarization process.

3. Troubleshooting Routes Summarization in RIP

a. Problem: RIP-2 Routing Table Is Huge— Cause: Autosummarization Is Off
- Disabling the autosummarization feature increases the size of the routing table. In some
situations, this feature must be turned off (for example, if discontiguous networks exist).

b. Problem: RIP-2 Routing Table Is Huge— Cause: ip summary-address Is Not Used
using manual summarization on the interface level.

4. Troubleshooting RIP Redistribution Problems
- The most common cause of this is a metric that is not defined during redistribution into
RIP.
- show ip route
- debug ip rip

5. Troubleshooting Routes Flapping Problem in RIP
- Route flapping refers to routes coming into and going out of the routing table. To check
whether the routes are indeed flapping, check the routing table and look at the age of the
routes. If the ages are constantly getting reset to 00:00:00, this means that the routes are
flapping. Several reasons exist for this condition. This section discusses one of the common
reasons—packet loss because the packet is dropping on the sender's or receiver's interface.

The example in this section considers Frame Relay because it is the most common medium
in which this problem occurs. The packet loss can be verified through the interface statistics
by looking at the number of packet drops and determining whether that number is
constantly incrementing.

Hub#show ip route rip
R 155.155.0.0/16 [120/1] via 131.108.1.1, 00:02:08, Serial0
R 166.166.0.0/16 [120/1] via 131.108.1.1, 00:02:08, Serial0

note that the updates was received last 2 minutes and 8 seconds ago. udpate should be received every 30 seconds. /timers are at a value lower than 30 seconds.

Hub#show interfaces serial 0

Broadcast queue 64/64, broadcasts sent/dropped 1769202/1849660, interface broadcasts 3579215

also the show interface reveals that broadcast packets are dropped. the frame relay broadcast queue must be tuned.
- In a non-Frame Relay situation, the input or output hold queue might need to be increased.

notes: OSPF Hello Protocol

The hello protocol serves several purposes:

- It is the means by which neighbors are discovered.
- It advertises several parameters on which two routers must agree before they can become neighbors.
- Hello packets also act as keepalives between neighbors.
- It ensures bidirectional communication between neighbors when a neighbor sees his own router ID in a received hello.
- It elects Designated Routers (DRs) and Backup Designated Routers (BDRs) on Broadcast and NBMA networks.

Hello-Interval

- OSPF-speaking routers periodically sends a hello packet out of each OSPF-enabled interface.
- Uses a default hello-interval of 10 seconds for broadcast and 30 seconds for non-broadcast networks.
- Configured on a per interface basis with "ip ospf hello-interval" below.

Note: - By changing the hello manually with "ip ospf hello-int", the dead-interval is adjusted accordingly to 4x the new hello value.

Router Dead-Interval

- Is the period of time to elapse, if a router does not receive a hello from a neighbor, before declaring that neighbor down.
- Cisco default is four times the hello-interval but can be changed with the command
"ip ospf dead-interval" below.

Each hello packet contains the following information:

- Router ID of the originating router. Identifies the router; highest IP chosen; loopback overrides all interfaces, however; can also be set with the router-id command; this ID is used to break ties for DR election.
- Area ID of the originating router interface. Area identifier (always 0 for backbone). All routers in the area must agree on this setting to form a stub area.
- Address mask of the originating interface.
- Authentication type and information of the originating interface. This password must match on routers configured for authentication.
- Hello-interval of the originating interface. Frequency at which hellos are sent and the amount of time that can elapse before router is declared dead; default is 10 seconds, and the default dead interval is 4 times that for an Ethernettype network; these defaults vary based on network type.
- Router dead-interval of the originating interface.
- Router priority. Priority value used for DR and BDR election.
- DR and BDR. IP addresses of the DR and BDR if known.
- Five flag bits signifying optional capabilities.
- Router IDs of the originating router's neighbors. List of the adjacent routers

Here are the details of the exchange process between two routers on a LAN (Router 1 and Router 2) and the OSPF adjacency states involved:
1. Router 1 begins in the down state because it is not exchanging OSPF information with any other router. It sends hello packets via multicast address 224.0.0.5 (all SPF).
2. Router 2 receives the OSPF hello and adds Router 1 in its list of neighbors. This is the beginning of the Init State.
3. Router 2 sends a unicast hello packet response to Router 1.
4. Router 1 receives the hello and notes that it is listed in the packet. It adds Router 2 to its list of neighbors. Router1 knows that it has bidirectional communication with Router 2. This is known as the two-way state.
5. In a LAN environment, the DR and BDR are elected.
6. In a LAN environment, the hello packets function as a keepalive mechanism every 10 seconds.

After the DR and BDR are established, the routers are in Exstart State, and they are ready to exchange database information. The exchange protocol functions as follows:

1. In the Exstart State, the DR and BDR establish an adjacency with each router in the network; a master-slave relationship is formed with the router ID indicating the master in the relationship.
2. The master and slave routers exchange DBD packets; this is the Exchange State. The LSAs in the DBD include sequence numbers used to indicate freshness.
3. When a DBD is received, the router acknowledges the receipt and compares the information with its current database. If more recent information is described in the DBD, the router sends an LSR to request the information, which is the Loading State. The router receiving the LSR responds with an LSU; this LSU is also acknowledged by the receiver.
4. The router adds the new information to its LSDB.
5. When the exchange completes, the routers are in Full State.

Router information is later maintained using the following process:
1. The router notices the change and multicasts an LSU to the OSPF DR and BDR multicast address of 224.0.0.6.
2. The DR acknowledges the LSU and floods to all using multicast 224.0.0.5. This process involves acknowledgments,too.
3. The DR also sends the LSU to any other networks to which it is attached.
4. Routers update their LSDB with the new information in the LSU.

Summaries are sent every 30 minutes to ensure synchronization, and link state entries have a Max Age of 60 minutes

To establish adjacency, the following values must match the values configured on the receiving interface

- Area ID.
- Authentication.
- Network mask (point-to-point links are the exception).
- Hello-interval and Dead-interval.
- MTU.
- Options.

Fast Hello Packets

- Provides a way to configure the sending of hello packets in intervals less than 1 second.
- This is achieved by using the "ip ospf dead-interval minimal" command. Setting the dead interval to 1 second.
- The hello-multiplier value is set to the number of hello packets you want sent during that 1 second.
- Example: #ip ospf dead-interval min hello-multiplier 5 - hellos are sent 5 times per/sec, thus at a interval of 200ms.

-----------
COMMANDS
-----------
- Shows information from the neighbor data structure
- Shows all OSPF speaking neighbors, their state, dead-timer, connected interface

sh ip ospf neighbor

- Displays OSPF-related interface information, DR, BDR, etc

sh ip ospf interface

- Shows brief summary of which interface is running which ospf areas

sh ip ospf interface brief

- Specifies how often hellos are sent (10 sec/broadcast and 30 sec/non-broadcast)
- How long to wait before declaring a neighbor dead (default = 4x hello-interval)
- Configures OSPF fast hello
- Disables the MTU check. Used when a switch uses a different system MTU
- The MTU size in a hello must be the same on between neighbors

interface ser0
ip ospf hello-interval {1-65535 sec}
ip ospf dead-interval {1-65535 sec | minimal}
ip ospf dead-interval min hello-multiplier {no}
ip ospf mtu-ignore

OSPF Packet Types

- Type 1, Hello: Builds adjacencies
- Type 2, Database Description (DBD): Checks for database synchronization between routers
- Type 3, Link-State Request (LSR): Requests link-state specifics from the router
- Type 4, Link-State Update (LSU): Sends requested link-state records
- Type 5, Link-State Acknowledgment (LSA): Acknowledges the other packet types

OSPF Adjacencies

- Occurs through the exchange of hello packets.
- After adjacency is established, link-state databases (LSDB) are synched.
- Two OSPF neighbors on a point-to-point link form full adjacency with each other.
- In LANs, all routers form an adjacency with the DR and BDR; updates need to be sent only to the DR, which updates all other routers; and all other routers on the LAN are called DROTHERS and maintain a partial neighbor relationship with each other.

After adjacencies have been established, LSAs are exchanged through a reliable mechanism. LSAs are flooded to ensure topological awareness. LSAs have a sequence number and a lifetime value. LSAs convey the cost of links used for the SPF calculation. The cost metric is based on interface bandwidth. The LSA aging timer is a 30-minute default.

Note:  Hello and update packets in OSPF has TTL of 1.

Tweaking OSPF Timers

- timers are based on network interface types.

- faster links hello packets are sent every 10 seconds.
- slower links hello packets are sent every 30 seconds.
- hold and dead timer is 4x hello interval.

Lab Scenario:  Changing timers:

thinking of multiple stuff:
 - hello
 - hold
- dead
- spf timers  (shortest path first calculation
   5 seconds after updates are recieved. (basic)
   10 seconds after consecutive updates are received. (consecutive)

command:

timers spf (basic) (consecutive)

ex. 20% less

router ospf 1

timers spf 4 8

 - adjusting hello interval will automatically adjust the dead timer which is 4x hello.
- you can just independently the dead interval
Note: when adjusting timer you should think to adjust other side as well. or router in the same domain.

to check the defaults:

show ip ospf interface

Ex.

interface e0/0

ip ospf hello-interval 10

ip ospf dead interval 5

note: adjacency may disapear.  So watch your command router will allow you to enter this figures. even if it doesn't make sense.


Fast Hellos

ip ospf dead-interval minimal hello-multiplier 5

- sets dead time to 1 second.
- multiplier is the number of hellos within 1 second.
- yiels 200 ms hellos in this case

notes: OSPF Overview & Peering

- Uses own transport protocol: 89
- Supports equal-cost load balancing for more efficient use. (The amount is not an OSPF limitation instead this set by the vendor depending on their hardware platform. For most IOS versions this is limited to either 6 or 8 paths).
- Supports the use of route tagging for the tracking of external routes.
- OSPF packets are exchanged only between neighbors on a network. They are never routed beyond the network on which they originated.
- OSPF multicast packets use a TTL of 1.

- OSPF sees secondary networks as stub networks and therefore will not send hellos on them. Consequently, no adjacencies can be established on secondary networks.

- Classless with variable: Length subnet mask (VLSM) support.
- Uses multicasts (224.0.0.5–all shortest path first [SPF] routers; 224.0.0.6: Designated Router [DR]/ Backup Designated Router [BDR]) for hellos and updates.
- Plain text and Message Digest Algorithm 5 (MD5) authentication available. Null authentication is the default.
- Dijkstra’s algorithm is used to produce a shortest-path tree for each destination. Link-state advertisements are used to build a database of the topology.

OSPF Peering

in order to form a neighbor relationship the following must be satisfied.

- timers must match
- mtu size must match
- area must match
- stub flag must match (e-bit)
- network must match ( except for point-to-point and virtual links)
note: changing hello will automatically adjust dead time.

Peering considerations (troubleshooting)

-  show ip ospf neigbhor
-  show ip ospf interface
- debug ip ospf adjacencies

if you notice Extart & peer keeps on dropping too many

DBD retransmission
- most likely mtu mistmatch.
- usually in router to switch connection
- switch higher mtu (for tagging)
3560 - "system mtu routing"
3550 - no option
router - "ip ospf mtu ignore"

notes: EIGRP BFD

Bidirectional Failure Detection

- its not a feature specific for EIGRP
- rapid detection of failures in forwarding path
- configured on interface and under process.
- only detects the failure, protocol responsible for reacting.
- one session for multiple protocols between peers.
I.E OSPF AND EIGRP only one session.

configuration

process level

router eigrp 100
bfd all-interfaces | bfd interface X/Y

interface level timers

bfd interfal

verification

show bfd neighbor detail

example:

int fa0/0
bfd interval 50 min 50 mult 3

router eigrp 100
bfd interface fa0/1

verification:

show bfd neighbor detail

notes: EIGRP Miscellany

- donot update hop reachability (hub/spoke)

interface
no ip next-hop-self- eigrp AS#

used in a ccie scenario: hub and spoke topology , you will add this in the hub

- Prefix limitations
-neighbor maximum-prefix (#prefix) [options]
- Redistribute maximum-prefix (#prefix) [options]
- options include timers and minutes for resets

useful commands

show ip eigrp neigbhors

show ip eigrp topology (table/RIB)

show ip route eigrp routing table entrisy

EIGRP is very verbose in case something isnt working on a peer.

network commands can take mask info

network 10.1.1.0 0.0.0.0.255

and/0r use passive-interface default



-discovery of BB router AS# via debug

- use acl to look at eigrp only
access-list 101 permit ip any host 224.0.0.10
- then "debug ip packet 101 dump" to view hex dump value of header field
- find hex "E000000A" for 224.0.0.10 and skip ahead five 32-bits words.
- the fifth 32-bit word is the AS value sent or received (wacth debug direction)

* ip : source: d: 224.0.0.10, rcvd 2

find E000000A (224.0.0.10) and count 5 32 bit sections and that is the AS number.

hex 0x00000064 is 100 in decimal, so AS 100 is your other side's AS number.

LAB: EIGRP Default Network and Default information originate

Default Network

Using the command, you can configure a default route for the EIGRP process so that it propagates to other EIGRP routers within the same AS. A router configured with the command considers the network listed in that command as the last-resort gateway. You should define the default route using a static route to ensure it is advertised.

ip default-network {network address}


Default-information:

To control the candidate default routing information for Enhanced Interior Gateway Routing Protocol (EIGRP) processes, use the default-information command in router configuration mode.

default-information {in | out} {access-list-number | access-list-name}

no default-information {in | out}

To suppress EIGRP candidate information in incoming or outbound updates, use the no default-information in command.
i.e to supress 0.0.0.0

no default-information in

notes: EIGRP Bandwith percentage

- EIGRP is designed to use no more than 50 percent of the available bandwidth of a link.
- This restriction means that EIGRP's pacing is tied to the configured bandwidth.

Example

> Suppose an interface is connected to a 512K serial link, but the bandwidth is configured at 128K.
> By default EIGRP would limit itself to 50 percent of the configured amount, in this case 64K.
> The command below adjusts the EIGRP bandwidth percent to 200% of 128K, which is 256K, half of the actual link bandwidth.

-----------
COMMANDS
-----------

- Assumes the physical clock is 512k
- Adjusts the EIGRP bandwidth percent to 200% of 128K
- Which is 256K, half of the actual link bandwidth 512k

interface Serial0
bandwidth 128
ip bandwidth-percent eigrp 1 200

notes: EIGRP Stub Routing

Often used in a hub-and-spoke topology. Only routes you specify are propagated from the stub router. The stub router responds to all queries with the message “inaccessible.” A router configured as a stub sends a special peer information packet to all neighboring routers to report its status as a stub router. Nonstub routers do not query stub routers. The stub routing feature does not prevent routes from being advertised to the stub router. You must configure the summarization or default route behavior.

- A router that has EIGRP stub neighbors will not send queries to those stubs, thereby eliminating the chance that a stub will cause stuck-in-active conditions, and routing instabilities in other parts of the network.
- Stub Routing can also be useful to prevent a router from being used as transit/backup by only sending local updates not containing remote learned routes.

-----------
COMMANDS
-----------

- With detail option: (CONNECTED SUMMARY) shows the configured STUB neighbors

show ip eigrp neighbors [detail]

- Configured on a stub router defining which routes to be sent
- DEFAULT: Only updates containing connected and summary routes will be sent
- Receive-Only]: The stub router will not send any route information in updates

eigrp stub [connected | redistributed | static | summary | receive-only]

stub (connected only)

router eigrp 100
eigrp stub connected

stub with leak-map

The leak-map feature of EIGRP stub, like the leak-map for EIGRP
summarization, allows the advertisement of routes that would normally be
suppressed.

ip prefix-list SW2_LOOPBACK seq 5 permit 150.1.8.0/24
!
route-map STUB_LEAK_MAP deny 10
match ip address prefix-list SW2_LOOPBACK
!
route-map STUB_LEAK_MAP permit 20
!
router eigrp 100
eigrp stub connected leak-map STUB_LEAK_MAP


notes: no validate update source and EIGRP Filtering

for Secondary IPs. - neighbor will not form to the secondary IPs.

router eigrp 100
no validate update source


Filtering:

1. offset-list - the offset-list feature in EIGRP is used to modify the metric on a perroute
basis or a per-interface basis.
- Increases the metric.

#offset-list [ACL] {in|out} {offset} {interface}

router eigrp 100
offset-list 1 in 2147483647 FastEthernet0/3
!
access-list 1 permit 150.1.3.0

2. distribute-list

- Filters all routes matching the ACL or prefix-list

distribute-list {ACL | prefix} {in|out}

std acl:

router eigrp 10
distribute-list 1 in Serial0/0
!
access-list 1 permit 0.0.0.0 255.255.254.255

extended acl:

access-list 100 deny ip host 155.1.0.1 host 150.1.2.0
access-list 100 deny ip host 155.1.0.2 host 150.1.2.0
access-list 100 deny ip host 155.1.0.4 host 150.1.2.0
access-list 100 permit ip any any
!
router eigrp 100
distribute-list 100 in Serial0/0


- Filters all routes to/from a neighbor

distribute-list gateway {prefix-list} {in|out} {interface}

router eigrp 100
distribute-list prefix STOP_RIP_SUBNETS out Serial0/1
!
ip prefix-list STOP_RIP_SUBNETS seq 5 deny 30.0.0.0/14 ge 16 le 16
ip prefix-list STOP_RIP_SUBNETS seq 10 deny 31.0.0.0/14 ge 16 le 16
ip prefix-list STOP_RIP_SUBNETS seq 15 permit 0.0.0.0/0 le 32

- Filters prefix from a specific source from entering the routing table

distribute-list prefix {prefix-routes} gateway {prefix-source} {in|out}

router eigrp 100
distribute-list prefix PERMIT_ALL gateway NOT_FROM_R4 in
!
ip prefix-list NOT_FROM_R4 seq 5 deny 155.1.146.4/32
ip prefix-list NOT_FROM_R4 seq 10 permit 0.0.0.0/0 le 32
!
ip prefix-list PERMIT_ALL seq 5 permit 0.0.0.0/0 le 32

- Changes the distance for both internal and external EIGRP routes

distance eigrp {ad-internal} {ad-external}

- Using Route-maps

router eigrp 100
distribute-list route-map FILTER_ON_TAGS in
!
route-map FILTER_ON_TAGS deny 10
match tag 4
!
route-map FILTER_ON_TAGS permit 20


3. Using Admin distance:

distance {AD} {address} {wildcard} {acl#|aclname}

- any source

access-list 4 permit 150.1.4.0
!
router eigrp 100
distance 255 0.0.0.0 255.255.255.255 4

- specific per neighbor

access-list 7 permit 150.1.7.0
!
router eigrp 100
distance 255 155.1.37.7 0.0.0.0 7

4. Using redistribution with route-maps

router eigrp 100
redistribute rip metric 100000 100 255 1 1500 route-map RIP_TO_EIGRP
!
ip prefix-list VLAN_43 seq 5 permit 204.12.1.0/24
!
route-map RIP_TO_EIGRP permit 10
match ip address prefix-list VLAN_43
set tag 4
!
route-map RIP_TO_EIGRP permit 20

notes: EIGRP Summarization

- EIGRP by default, auto-summarizes prefixes to classful boundary when passing major network boundary, but this can be disabled. If auto-summary is enabled, interfaces are summarized at class boundary.
- A route to Null0 for summary routes are created to prevent black-holes.
- Disabling automatic summarization can prevent ambiguous routing between similar network subnets. (It is always recommended)

Manual summarization for EIGRP is interface-specific.

- This provides the flexibility to be able to advertise different summary routes out different interfaces for the same process.
- Manual summarization is configured with the "ip summary-address eigrp" command
- By default this will automatically suppress the advertisement of the more specific networks and create a route to Null0
- To have more specific routes sent, use a leak-map.
- The summary routes advertised into EIGRP are not tagged as external routes, like OSPF.
- The floating summary route is created by applying a default route and an administrative distance at the interface level.

command:

- Disables auto-summary to the classful boundary when passing between major network boundaries (default = Enabled)

no auto-summary

- Will automatically suppress the advertisement of the more specific networks
- Specifies the summary, mask, and the process into which the summary is to be advertised
- [leak-map]:Route-map allows more specific routes + summary to be advertised

int E0
ip summary-address eigrp {ASN} {aggregate} [leak-map] [AD]

- Example of a floating summary route with a higher AD.

ip summary-address eigrp 100 0.0.0.0 0.0.0.0 250

notes: EIGRP Authentication

- EIGRP packets can ONLY be authenticated using an MD5 cryptographic checksum.
- Configured using key-chains.
- EIGRP, unlike RIP requires the same key-number on both sides.
- When configuring, the order of operation is important.
- When doing changes to the keychain, first remove the key-chain off the interface.

- The steps for configuring EIGRP authentication are:

1. Define a key chain with a name.
2. Define the key or keys on the key chain.
3. Enable authentication on an interface and specify the key chain to be used.
4. Optionally configure key management.


-----------
COMMANDS
-----------
verification:

- Shows the configured keys and which are currently valid

sh key chain {name}

- Shows received authentication packets.

debug eigrp packet hello

configuration:

1. define key chain.
Specifies the period a key is valid for
Specifies overlapping times for a key to be accepted

key chain {name}
key {key number}
key-string {string}
send-lifetime {from H:M:S MON DAY YEAR} {to H:M:S MON DAY YEAR}
accept-lifetime {from H:M:S MON DAY YEAR} {to H:M:S MON DAY YEAR}

2. interface config.
- Assigns the key-chain to the interface
- Specifies MD5

interface Serial0
ip authentication key-chain eigrp {ASN} {chain name}
ip authentication mode eigrp {ASN] md5

notes: EIGRP Passive Interface, Split Horizon

- The passive-interface command prevents EIGRP hellos from being sent on data links where they don't belong.
- Will prevent neighbor establishments and routes being advertised, as received hellos will be ignored.

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 stop the forming of an adjacency on the interface, and hence the learning of any updates on the link.

The passive-interface default command can be used to make all interfaces passive, and then interfaces can have the passive feature selectively disabled with the no passive-interface command.



command:

Disables the interface from sending hellos

passive-interface {int}

Split-Horizon

- Is always enabled with EIGRP.
- Remember to disable split-horizon with physical multi-point frame-relay interfaces.

command:

interface eth0
no ip split-horizon eigrp {ASN}

notes: EIGRP DUAL Finite state, SIA

- The lowest calculated metric to each destination will become the feasible distance (FD) of that destination.
- The feasibility condition (FC) is a condition that is met if a neighbor's advertised distance (AD) to a destination, is lower than the router's current FD to that same destination.
- If a neighbor's AD to a destination meets the FC, that neighbor becomes a feasible successor (FS) for that destination.
- Because feasible successors are always "downstream," a router will never choose a path that will lead back through itself, thus creating a loop.
- Such a path would have a distance larger than the FD.
- Every destination for which one or more feasible successors exist, will be recorded in a topology table.
- Each route after inserted, when no diffusing is taking place will be in a passive state.
- If there are two successors with the locally calculated metric equal to the FD, both routes are entered into the route table, and equal-cost load balancing will be performed.
- If a link to a successor fails(input event), or if the cost of the link increases beyond the FD (input event), the router will first look into its topology table for a feasible successor.
- If a FS is found, through local computation, it will become the successor. This occurs in the sub-second range. An update is sent to all neighbors and the route remains in the passive state.
- If a feasible successor cannot be found in the topology table, the router will begin a diffusing computation by querying neighbors for possible routes and the route will change to the active state.
- For each neighbor to whom a query is sent, the router will set a reply status flag (r) to keep track of all outstanding queries.
- The diffusing computation is complete when the router has received a reply to every query sent to every neighbor.
- If all expected replies are not received before the Active time expires, the route is declared stuck-in-active (SIA).
- At the completion of the diffusing computation, the originating router will set FD to infinity to ensure that any neighbor replying with a finite distance to the destination will meet the FC and become a feasible successor.
- Remember that queries cause the diffusing calculation to grow larger, whereas replies cause it to diminish/grow smaller.

SIA

A route is considered stuck-in-active if no response to the query has been received for a configured amount of time (default 3 minutes). After this time, the EIGRP drops all neighbors that it has not received replies from.

command:

active timer - to minimize the effect of SIA

eigrp 100
timers active time 180

notes: EIGRP Packets

- EIGRP uses multiple packet types, they are all identified by protocol number 88 in the IP header.

1. Hellos: Are used by the neighbor discovery and recovery process. Hellos are unicast or multicast and use unreliable delivery.
- Establish neighbor relationships.

2. ACKs: Are Hello packets with no data in them. ACKs are always unicast and use unreliable delivery.
- Acknowledge reliable packets.

3. Updates: Convey route information. Updates could be unicast/multicast and always use reliable delivery.
- Send routing updates.

4. Queries/Replies: Used by DUAL for computations. Queries can be unicast or multicast, but replies are always unicast.
- Ask neighbors about routing information.
- Respond to queries.

- Any reliable multicast packets sent, that was not acknowledged by the neighbor it was sent too, will be followed by a retransmitted unicast packet to that neighbor.
- If an acknowledgement was not received after 16 of these unicast retransmissions, the neighbor will be declared dead.
- Retransmission timeout (RTO) is the time between the subsequent unicasts.
- Smooth round-trip time (SRTT) is the time, between a packet sent to the neighbor and the receipt of an acknowledgment.

EIGRP Reliability

Packets that require acknowledgment are as follows:
- Update
- Query
- Reply

Packet that do not are as follows:
- Hello
- Ack

Neighbor reset after retry limit (16) is reached. Slow neighbors are sent unicast packets instead.

The address used for hello packets is 224.0.0.10; AS numbers must match. Hellos are sent every 5 seconds on broadcast links and point-to-point serial links, point-to-point subinterface links, and multipoint circuits greater than T1. They are sent every 60 seconds on other link types. The hold time defaults to 3 times the hello time. Neighborships form even if the values do not match.

notes: EIGRP Updates

- Updates are multicast to 224.0.0.10.
- Updates are non-periodic, partial and bounded(only to relevant neighbors)
- Can be sent as unicast at a process level with the "neighbor" command.
- But both sides must be configured to use unicast.
- BEWARE: If configured, EIGRP stops processing all multicast packets that come inbound on that interface. Also stops sending multicast packets on that interface.
- BEWARE: Upon configuring all sessions from that interface will be dropped.
- Using an ACL to filter EIGRP traffic between two neighbors are recommended.
- Packets sourced by a router are not passed through an outbound ACL by default.

-----------
COMMANDS
-----------
Defines a unicast session to a neighbor. Required on both sides

router eigrp {asn}
neighbor {ip} {interface}


ACL Applied inbound, as outbound would have no effect
- Denies any EIGRP traffic
- Permit all other traffic

ip access-list 100 deny eigrp any any
ip access-list 100 permit ip any any
!
int eth0
ip access-group 100 in


note: " show ip eigrp neighbor" - neighbor will not show.

show run
show ip protocols

CCIE SCENARIO: you should receive only and shouldnt sent out updates on the interface. passive interface is not an option.

ip access-list 100 deny eigrp any any
ip access-list 100 permit ip any any

distribute-list 100 outh eth0

notes: EIGRP Convergence Timers

- Never change the timers unless asked to.
- Hellos are sent using unicast every 60 sec, on access links with speeds of T1 or slower.
- Hellos are sent using multicast every 5 sec, on all other network links.
- The hold-time interval is 180 sec, on low-speed NBMA networks.
- The hold-time interval is 15 sec, on all other networks.

commands:

- Shows each neighbor in the neighbor table with each timer

show ip eigrp neighbors

- Changes the default hello interval

ip hello-interval eigrp {ASN} {seconds}

note: hello interval @ T1 = 5 seconds, >T1 = 60 seconds.


- Changes the default hold-time

ip hold-time eigrp {ASN} {seconds}

LAB: EIGRP Unequal Cost Load Balancing

Requirements:

- Configure unequal cost load balancing so that traffic from R6 going to VLAN 9 is load balanced between R1 and SW1.
- The traffic share should be configured in such a way that the link to SW1 is used five times as much as the link to R1.
- Verify this by configuring per-packet load balancing on R6.

pls take note that all routers are using delay only; "metric weights 0 0 0 1 0 0"


PATH R6>SW1>SW3

Rack1R6#sho int fa0/0.67 | include DLY
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

Rack1SW1#sho int vlan79 | include DLY
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

Rack1SW3#sho int vlan9 | inc DLY
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

Total delay of 120 microseconds

Metric = 256 * (120/10) = 3072

Rack1R6#sho ip eigrp topology 155.1.9.0 255.255.255.0
IP-EIGRP (AS 100): Topology entry for 155.1.9.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3072
Routing Descriptor Blocks:
155.1.67.7 (FastEthernet0/0.67), from 155.1.67.7, Send flag is 0x0
Composite metric is (3072/512), Route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 120 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2



PATH R6>R1>R3>SW1>SW3

Rack1R6#sho int fa0/0.146 | include DLY
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

Rack1R1#sho int s0/1 | inc DLY
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

Rack1R3#sho int fa0/0 | inc DLY
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

Rack1SW1#sho int vlan79 | include DLY
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

Rack1SW3#sho int vlan9 | inc DLY
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,


Total delay of 20,220 microseconds

Metric = 256 * (20,220/10) = 517632


so the successor route is via SW1.

note:
FEASIBILITY CONDITION:
IF THE ADVERTISED DISTANCE OF AN ALTERNATIVE ROUTE IS LOWER THAN THE FEASIBLE DISTANCE OF THE SUCCESSOR, THE ROUTE IS A LOOP FREE PATH AND CAN BE CONSIDEED FOR LOAD BALANCING.


ADVERTISED DISTANCE OF R1


Rack1R1#sho int s0/1 | inc DLY
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

Rack1R3#sho int fa0/0 | inc DLY
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

Rack1SW1#sho int vlan79 | include DLY
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

Rack1SW3#sho int vlan9 | inc DLY
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,


Total delay of 20,120 microseconds

Metric = 256 * (20,120/10) = 515072 - CANT BE CONSIDERED A FEASIBLE SUCCESSOR.


ADJUSTING THE DELAY ALONG PATH R6>R1>R3>SW1>SW3

R1- 10 usec
R3- 10 usec


Rack1R1(config)#interface Serial0/1
Rack1R1(config-if)#delay 1

Rack1R3(config)#interface FastEthernet0/0
Rack1R3(config-if)#delay 1




Rack1R6#sho int fa0/0.146 | include DLY
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

Rack1R1#sho int s0/1 | inc DLY
MTU 1500 bytes, BW 1544 Kbit, DLY 10 usec,

Rack1R3#sho int fa0/0 | inc DLY
MTU 1500 bytes, BW 100000 Kbit, DLY 10 usec,

Rack1SW1#sho int vlan79 | include DLY
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

Rack1SW3#sho int vlan9 | inc DLY
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,


Total delay of 140 microseconds

Metric = 256 * (140/10) = 3584 since this still higher than 3072 so the path is not the successor.

howerver the new metric Advertised by R1 = 256* 40/10 microseconds = 1024 this route is now a feasible successor.


Rack1R6#sho ip eigrp topology 155.1.9.0 255.255.255.0
IP-EIGRP (AS 100): Topology entry for 155.1.9.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3072
Routing Descriptor Blocks:
155.1.67.7 (FastEthernet0/0.67), from 155.1.67.7, Send flag is 0x0
Composite metric is (3072/512), Route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 120 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
155.1.146.1 (FastEthernet0/0.146), from 155.1.146.1, Send flag is 0x0
Composite metric is (3584/1024), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 140 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 4


VARIANCE COMMAND: the actual variance value is arbitrary as long as the FD, 3072, times the variance is greater than the total composite metric through R1.

Rack1R6(config)#router eigrp 100
Rack1R6(config-router)#variance 128


Rack1R6#show ip route 155.1.9.9
Routing entry for 155.1.9.0/24
Known via "eigrp 100", distance 90, metric 3072, type internal
Redistributing via eigrp 10, eigrp 100
Advertised by eigrp 10
Last update from 155.1.146.1 on FastEthernet0/0.146, 00:00:28 ago
Routing Descriptor Blocks:
155.1.146.1, from 155.1.146.1, 00:00:28 ago, via FastEthernet0/0.146
Route metric is 3584, traffic share count is 103
Total delay is 140 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 4
* 155.1.67.7, from 155.1.67.7, 00:00:28 ago, via FastEthernet0/0.67
Route metric is 3072, traffic share count is 120
Total delay is 120 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2

now the traffic share is 103:120. to achieve the desired 1:5

the values that can be used on R1, R3 and R6 for the delay can have a multiple valid options; as long 2 conditions are true;

1. advertised distance of R1 sends to R6 must be lower than R6's Feasible Distance.
2. entire composite result R6 calculates through R1 should be five times the feasible distance.

IN THIS CASE R1'S ADVERTISED IS 40 microseconds or 4 tens of microseconds.


3072 * 5 = (R6 to R1 DLY + 4) * 256


R6 to R1 SHOULD BE 56


Rack1R6(config)#int fa0/0.146
Rack1R6(config-subif)#delay 56


Rack1R6#show ip route 155.1.9.9
Routing entry for 155.1.9.0/24
Known via "eigrp 100", distance 90, metric 3072, type internal
Redistributing via eigrp 10, eigrp 100
Advertised by eigrp 10
Last update from 155.1.146.1 on FastEthernet0/0.146, 00:00:07 ago
Routing Descriptor Blocks:
155.1.146.1, from 155.1.146.1, 00:00:07 ago, via FastEthernet0/0.146
Route metric is 15360, traffic share count is 1
Total delay is 600 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 4
* 155.1.67.7, from 155.1.67.7, 00:00:07 ago, via FastEthernet0/0.67
Route metric is 3072, traffic share count is 5
Total delay is 120 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2


VERIFICATION:

Rack1R6(config)#interface FastEthernet0/0.67
Rack1R6(config-subif)#no ip route-cache
Rack1R6(config-subif)#ip load-sharing per-packet
Rack1R6(config-subif)#interface FastEthernet0/0.146
Rack1R6(config-subif)#no ip route-cache
Rack1R6(config-subif)#ip load-sharing per-packet
Rack1R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R1(config)#access-list 100 permit icmp any host 155.1.9.9 log
Rack1R1(config)#access-list 100 permit ip any any
Rack1R1(config)#interface FastEthernet0/0
Rack1R1(config-if)#ip access-group 100 in
Rack1SW1#config t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1SW1(config)#access-list 100 permit icmp any host 155.1.9.9 log
Rack1SW1(config)#access-list 100 permit ip any any
Rack1SW1(config)#interface Vlan67
Rack1SW1(config-if)#ip access-group 100 in

notes: EIGRP Variance and Load-sharing

The degree to which EIGRP performs load balancing is controlled with the variance command. You set the variance to a number from 1 to 128. The default is 1, which indicates equal-cost load balancing. The multiplier defines the range of metric values that are accepted for load balancing by the EIGRP process. For example, if you want load balancing to occur between two links, and one has a metric of 1000 and the other has a metric of 2000, you need to set the variance to 2 to cause load balancing between the two links. A route must be in the topology table by meeting
the initial feasibility test; otherwise, it won’t be used in load balancing regardless of the variance.

- The variance command is used to determine which routes are feasible for unequal-cost load sharing.
- Variance defines a multiplier by which a metric may differ, or vary, from the metric of the lowest-cost route.
- Any route whose metric exceeds the metric of the lowest-cost route, multiplied by the variance, will not be considered a feasible route.
- The default variance is one, meaning that the metrics of multiple routes must be equal, to load balance.
- Variance must be specified in whole numbers.
- Load sharing is per destination if the packet is fast switched or CEF switched using the default CEF configuration.
- Load sharing is per packet if process switching is used or if the CEF configuration was modified.
- CEF and fast switching can be turned off with "no ip cef" and "no ip route-cache", and then the router will perform unequal-cost, per packet load balancing.
- For a good load-sharing example refer to : http://blog.ru.co.za/2009/04/02/eigrp-metric-manipulation/
- Load-sharing by default is based inversely to the traffic-share rate among the multiple paths.
> So if wanting a traffic-share rate of 1:5, the first path would get five times more traffic than the second.
- This can be changed to use only the best metric path, even though both routes are in the table with traffic-share min across-interfaces

1. Disables CEF under the interface.

no ip cef

2. Disables fast-switching under the interface

no ip route-cache

Note:both above is necessary for per packet load-balancing via process switching)

3. Meaning a interface metric can be up to 5 times more than the current FD (def=1
Changes the default (4 paths) over which EIGRP can be set load balance.
Default: share inversely proportional to metric
Only use the best metric path, even though multiple in routing table

router eigrp 15
variance 5
maximum-paths 2
traffic-share balanced
traffic-share min across-interfaces

note: traffic-share min (not a default command)

Load Balancing

- note equal cost vs unequal cost

- traffic-share command
balanced vs. unbalanced (default)

- load-balancing
- ip load-sharing per-packet
- ip load-sharing per-destination (default)

interface FastEthernet0/0.67
no ip route-cache
ip load-sharing per-packet

unequal cost load balancing default is 4 most 6 nowadays 16
using variance -

i.e.
5 routes with the ff metric

1000
2000
3000
4000
5000

load balance 2 paths= solution variance of 2


3 paths: variance of 3


if the metrics are not multiple load balance between 3 paths.

1000
2000
2500
3000
variance 3 and maximum-path of 3 (combine multiple commands to achieve the requirements;)


load balance between 3 paths but not allowed using variance: for the ff metrics;
1000
2000
3000
4000
5000

- using offset list
- bandwidth and delay value - more pain

notes: EIGRP Metric, Timers and K-values

EIGRP uses a composite metric such as Interior Gateway Routing Protocol (IGRP), but it is modified with a multiplier of 256. Bandwidth and delay are the defaults enabled. EIGRP calls the metric feasible distance.

- EIGRP calculates all metrics from outgoing interfaces only.
- The composite metric is minimum bandwidth of an outgoing interface, cumulative delay, load, and reliability.
and smallest MTU along a path.

- Metrics:

1. BW - Expressed in units of kilobits per second.
- Static number used for metric calculation only, doesn’t reflect actual bandwidth.
- To calculate EIGRP bandwidth metric amount: 10 000 000/configured BW.
- Expressed in kilobytes; to adjust the bandwidth value assigned to an interface, use the bandwidth command.

2. DLY - Static figure, expressed in units of microseconds.
- To calculate EIGRP DLY metric amount : DLY/10.

3. REL - Dynamically measured.
- Is expressed as an eight-bit number, where 255=100% reliable link and 1= minimally reliable link.
- Expressed in microseconds; it can be adjusted using the delay command; when manipulating metrics, consider delay because bandwidth would affect other protocols, too.

4. LOAD - Dynamically measured.
- Is expressed as an eight-bit number, 1=minimally loaded link, and 255=100% loaded link.

5. MTU - Maximum transmission unit; the smallest recorded MTU in the path. Note that MTU is not used in metric calculation.

- Default K-Values: K1=1 K2=0 K3=1 K4=0 K5=0
- EIGRP Metric =

256*((K1*Bw) + (K2*Bw)/(256-Load) + (K3*Delay)*(K5/(Reliability + K4)))

- By default, EIGRP chooses a route based ONLY on bandwidth and delay. (Due the default k-values)

> Default metric = 256 x [10^7 / (min(BW)) + (sum(DLY)) / 10]

- EIGRP supports hop-count merely as a way to prevent routing loops.


-----------
COMMANDS
-----------

1. Changes the default hop-count limit of 100. Values 1-225

metric maximum-hops {number}

2. Changes the metric calculation of the K-values (K1=1 K2=0 K3=1 K4=0 K5=0)

metric weights tos k1 k2 k3 k4 k5

3. Changes the metric calculation to only use DLY

metric weights 0 0 0 1 0 0

4. Changes the metric calculation to only use BW

metric weights 0 1 0 0 0 0

5. Changes the bandwidth to 64 Kbit, and Specifies delay in tens of microseconds, changes the delay to 50 usec.

interface e0
bandwidth 64
delay 5

timers

1. hello

interface
ip hello-interval eigrp [as#] [time-seconds]


2. hold time

interface
ip hold-time eigrp as# [as#] [time-seconds]

3. nsf-hello timer

router eigrp 100
timers nsf route-hold [time-seconds]

4. active timer - SIA

router eigrp 100
timers active-time

notes: EIGRP Operation

Enhanced Interior Gateway Routing Protocol (EIGRP) is a hybrid routing protocol—combining features of both distance vector and link-state routing protocols.

- VLSM support.
- Hybrid IGP using DUAL (Diffusing Update Algorithm). - rapid convergence
- Uses own transport protocol: 88.
- Multicasts to destination 224.0.0.10 (ttl=0) using RTP, the receiving neighbor unicasts an acknowledgment.
- Unequal-cost load sharing up to 16 links.
- EIGRP does not form neighbors over secondary networks/IP's.
- Low CPU utilization—with typically only hellos and partial updates being sent on a link
- Incremental updates
- Scalability
- Ease of configuration
- Automatic route summarization, or manual route summarization
- MD5 route authentication


- Route entries are classified into one of three categories:

1. Interior routes: Is a path to a subnet of the network address of the data link on which the update is being broadcast.

>> Interior route is "local" to the major network to which the advertising and receiving router are commonly connected.

>> 192.168.2.192/26 is advertised to 192.168.2.64/26 within same AS as interior route because it falls within the same major network.

2. System routes: Is a path to a network address, which has been summarized by a network boundary router.

>> 192.168.3.0 is advertised to 192.168.2.0, within the same AS as a system route.

3. Exterior routes: Is a path to a default network, or a network in another autonomous system

>> 196.12.1.0 is advertised to 64.32.0.0 in a separate AS as a exterior route.


eigrp decision making process - uses composite metric

- internal routes are preferred first
- calculated metric used to select best

- External routes are last
- calculated metric used to select best

LAB: EIGRP Filtering with Route Maps

requirements:
- Configure R4 to redistribute the VLAN 43 subnet into EIGRP with the tag value of 4.
- Configure a route-map filter on R2 that matches this tag value and denies the route from being installed in the routing table.
- Configure a route-map filter on R3 that denies EIGRP routes with a metric in the range of 500,000 – 750,000 from entering the routing table.
- These filters should not impact any other networks advertised by R4 or learned by R2 and R3.

R2:

router eigrp 100
distribute-list route-map FILTER_ON_TAGS in
!
route-map FILTER_ON_TAGS deny 10
match tag 4
!
route-map FILTER_ON_TAGS permit 20

R3:

router eigrp 100
distribute-list route-map FILTER_ON_METRIC_RANGE in
!
route-map FILTER_ON_METRIC_RANGE deny 10
match metric 625000 +- 125000
!
route-map FILTER_ON_METRIC_RANGE permit 20

R4:

router eigrp 100
redistribute rip metric 100000 100 255 1 1500 route-map RIP_TO_EIGRP
!
ip prefix-list VLAN_43 seq 5 permit 204.12.1.0/24
!
route-map RIP_TO_EIGRP permit 10
match ip address prefix-list VLAN_43
set tag 4
!
route-map RIP_TO_EIGRP permit 20

Note:

Unlike BGP, filtering with route-maps in IGP is usually limited to redistribution filtering only. However EIGRP now supports route-map filtering as a distributelist with matches on metric and tag. Route tags are set at the time of redistribution, and can be used like BGP community values to group prefixes together without having to match on the actual route in a prefix-list or access-list. In this example we can see that R2 and R4 see the prefix 204.12.1.0/24 with a tag of 4 in the topology table. R2 installs this in the routing table until the distribute-list is applied which denies routes with that tag value.


Rack1R4#sho ip eigrp topology | include tag
P 204.12.1.0/24, 1 successors, FD is 2560, tag is 4

Rack1R2#sho ip eigrp topology | include tag
P 204.12.1.0/24, 1 successors, FD is 1026560, tag is 4
Rack1R2#show ip route 204.12.1.0
Routing entry for 204.12.1.0/24
Known via "eigrp 100", distance 170, metric 1049600
Tag 4, type external
Redistributing via eigrp 100
Last update from 155.1.0.5 on Serial0/0.1, 00:01:49 ago
Routing Descriptor Blocks:
* 155.1.0.5, from 155.1.0.5, 00:01:49 ago, via Serial0/0.1
Route metric is 1049600, traffic share count is 1
Total delay is 41000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
Route tag 4

Rack1R2#show ip route 204.12.1.0
Routing entry for 204.12.1.0/24
Known via "eigrp 100", distance 170, metric 1049600
Tag 4, type external
Redistributing via eigrp 100
Last update from 155.1.0.5 on Serial0/0.1, 00:12:32 ago
Routing Descriptor Blocks:
* 155.1.0.5, from 155.1.0.5, 00:12:32 ago, via Serial0/0.1
Route metric is 1049600, traffic share count is 1
Total delay is 41000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
Route tag 4

Rack1R2#show ip route 204.12.1.0
% Network not in table

routes that are not affected by the filter:
Rack1R2#show ip route eigrp
155.1.0.0/24 is subnetted, 13 subnets
D 155.1.146.0 [90/1026560] via 155.1.23.3, 00:29:45, Serial0/1
[90/1026560] via 155.1.0.5, 00:29:45, Serial0/0.1
D 155.1.8.0 [90/514816] via 155.1.0.5, 00:29:47, Serial0/0.1
D 155.1.9.0 [90/512768] via 155.1.23.3, 00:29:45, Serial0/1
D 155.1.13.0 [90/1024000] via 155.1.23.3, 00:29:47, Serial0/1
D 155.1.7.0 [90/512512] via 155.1.23.3, 00:29:45, Serial0/1
D 155.1.5.0 [90/514560] via 155.1.0.5, 00:29:47, Serial0/0.1
D 155.1.58.0 [90/514560] via 155.1.0.5, 00:29:47, Serial0/0.1
D 155.1.37.0 [90/512256] via 155.1.23.3, 00:29:45, Serial0/1
D 155.1.79.0 [90/512512] via 155.1.23.3, 00:29:45, Serial0/1
D 155.1.67.0 [90/1029120] via 155.1.23.3, 00:29:45, Serial0/1
[90/1029120] via 155.1.0.5, 00:29:45, Serial0/0.1
D 155.1.108.0 [90/517120] via 155.1.0.5, 00:29:47, Serial0/0.1
D*EX 200.0.0.0/24 [170/1666560] via 155.1.23.3, 00:29:45, Serial0/1
[170/1666560] via 155.1.0.5, 00:29:45, Serial0/0.1
54.0.0.0/24 is subnetted, 1 subnets
D EX 54.1.1.0 [170/1538560] via 155.1.23.3, 00:29:45, Serial0/1
[170/1538560] via 155.1.0.5, 00:29:45, Serial0/0.1
D EX 200.0.2.0/24 [170/1666560] via 155.1.23.3, 00:29:45, Serial0/1
[170/1666560] via 155.1.0.5, 00:29:45, Serial0/0.1
31.0.0.0/16 is subnetted, 4 subnets
D EX 31.3.0.0 [170/1049600] via 155.1.0.5, 00:17:10, Serial0/0.1
D EX 31.2.0.0 [170/1049600] via 155.1.0.5, 00:17:10, Serial0/0.1
D EX 31.1.0.0 [170/1049600] via 155.1.0.5, 00:17:10, Serial0/0.1
D EX 31.0.0.0 [170/1049600] via 155.1.0.5, 00:17:10, Serial0/0.1
150.1.0.0/24 is subnetted, 7 subnets
D 150.1.7.0 [90/1157120] via 155.1.23.3, 00:29:48, Serial0/1
[90/1157120] via 155.1.0.5, 00:29:48, Serial0/0.1
D 150.1.6.0 [90/1154560] via 155.1.23.3, 00:03:11, Serial0/1
D 150.1.5.0 [90/640000] via 155.1.0.5, 00:29:47, Serial0/0.1
D 150.1.3.0 [90/640000] via 155.1.23.3, 00:29:46, Serial0/1
D 150.1.1.0 [90/1152000] via 155.1.23.3, 00:03:12, Serial0/1
D 150.1.9.0 [90/640512] via 155.1.23.3, 00:29:46, Serial0/1
30.0.0.0/16 is subnetted, 4 subnets
D EX 30.2.0.0 [170/1049600] via 155.1.0.5, 00:17:10, Serial0/0.1
D EX 30.3.0.0 [170/1049600] via 155.1.0.5, 00:17:10, Serial0/0.1
D EX 30.0.0.0 [170/1049600] via 155.1.0.5, 00:17:10, Serial0/0.1
D EX 30.1.0.0 [170/1049600] via 155.1.0.5, 00:17:10, Serial0/0.1


before applying filter on R3
Rack1R3#show ip route eigrp
D EX 222.22.2.0/24 [170/514560] via 155.1.23.2, 00:02:50, Serial1/3
D EX 204.12.1.0/24 [170/1049600] via 155.1.0.5, 00:34:19, Serial1/0.1
155.1.0.0/24 is subnetted, 14 subnets
D 155.1.146.0 [90/514560] via 155.1.13.1, 00:46:54, Serial1/2
D 155.1.8.0 [90/514816] via 155.1.0.5, 00:46:56, Serial1/0.1
D 155.1.9.0 [90/768] via 155.1.37.7, 00:46:54, FastEthernet0/0
D 155.1.7.0 [90/512] via 155.1.37.7, 00:46:54, FastEthernet0/0
D 155.1.5.0 [90/514560] via 155.1.0.5, 00:46:56, Serial1/0.1
D 155.1.58.0 [90/514560] via 155.1.0.5, 00:46:56, Serial1/0.1
D 155.1.45.0 [90/1024000] via 155.1.0.5, 00:16:12, Serial1/0.1
D 155.1.79.0 [90/512] via 155.1.37.7, 00:46:54, FastEthernet0/0
D 155.1.67.0 [90/517120] via 155.1.13.1, 00:46:54, Serial1/2
D 155.1.108.0 [90/517120] via 155.1.0.5, 00:46:56, Serial1/0.1
D EX 220.20.3.0/24 [170/514560] via 155.1.23.2, 00:02:50, Serial1/3
D*EX 200.0.0.0/24 [170/1154560] via 155.1.13.1, 00:46:54, Serial1/2
54.0.0.0/24 is subnetted, 1 subnets
D EX 54.1.1.0 [170/1026560] via 155.1.13.1, 00:46:54, Serial1/2
D EX 200.0.2.0/24 [170/1154560] via 155.1.13.1, 00:46:54, Serial1/2
D EX 192.10.1.0/24 [170/514560] via 155.1.23.2, 00:02:54, Serial1/3
31.0.0.0/16 is subnetted, 4 subnets
D EX 31.3.0.0 [170/1049600] via 155.1.0.5, 00:34:19, Serial1/0.1
D EX 31.2.0.0 [170/1049600] via 155.1.0.5, 00:34:19, Serial1/0.1
D EX 31.1.0.0 [170/1049600] via 155.1.0.5, 00:34:19, Serial1/0.1
D EX 31.0.0.0 [170/1049600] via 155.1.0.5, 00:21:46, Serial1/0.1
150.1.0.0/24 is subnetted, 8 subnets
D 150.1.7.0 [90/645120] via 155.1.13.1, 00:46:56, Serial1/2
D 150.1.6.0 [90/642560] via 155.1.13.1, 00:16:06, Serial1/2
D 150.1.5.0 [90/640000] via 155.1.0.5, 00:46:56, Serial1/0.1
D 150.1.4.0 [90/1152000] via 155.1.0.5, 00:16:06, Serial1/0.1
D 150.1.2.0 [90/640000] via 155.1.23.2, 00:46:54, Serial1/3
D 150.1.1.0 [90/640000] via 155.1.13.1, 00:16:06, Serial1/2
D 150.1.9.0 [90/128512] via 155.1.37.7, 00:46:54, FastEthernet0/0
D EX 205.90.31.0/24 [170/514560] via 155.1.23.2, 00:02:50, Serial1/3
30.0.0.0/16 is subnetted, 4 subnets
D EX 30.2.0.0 [170/1049600] via 155.1.0.5, 00:21:46, Serial1/0.1
D EX 30.3.0.0 [170/1049600] via 155.1.0.5, 00:21:46, Serial1/0.1
D EX 30.0.0.0 [170/1049600] via 155.1.0.5, 00:21:46, Serial1/0.1
D EX 30.1.0.0 [170/1049600] via 155.1.0.5, 00:21:46, Serial1/0.1
D* 0.0.0.0/0 [90/1026560] via 155.1.0.5, 00:16:05, Serial1/0.1

after applying filter on R3


Rack1R3#show ip route eigrp
D EX 222.22.2.0/24 [170/1026560] via 155.1.0.5, 00:00:25, Serial1/0.1
D EX 204.12.1.0/24 [170/1049600] via 155.1.0.5, 00:36:53, Serial1/0.1
155.1.0.0/24 is subnetted, 14 subnets
D 155.1.146.0 [90/1026560] via 155.1.0.5, 00:00:25, Serial1/0.1
D 155.1.8.0 [90/1026816] via 155.1.23.2, 00:00:26, Serial1/3
[90/1026816] via 155.1.13.1, 00:00:26, Serial1/2
D 155.1.9.0 [90/768] via 155.1.37.7, 00:49:29, FastEthernet0/0
D 155.1.7.0 [90/512] via 155.1.37.7, 00:49:29, FastEthernet0/0
D 155.1.5.0 [90/1026560] via 155.1.23.2, 00:00:26, Serial1/3
[90/1026560] via 155.1.13.1, 00:00:26, Serial1/2
D 155.1.58.0 [90/1026560] via 155.1.23.2, 00:00:26, Serial1/3
[90/1026560] via 155.1.13.1, 00:00:26, Serial1/2
D 155.1.45.0 [90/1024000] via 155.1.0.5, 00:00:27, Serial1/0.1
D 155.1.79.0 [90/512] via 155.1.37.7, 00:49:29, FastEthernet0/0
D 155.1.67.0 [90/1029120] via 155.1.0.5, 00:00:25, Serial1/0.1
D 155.1.108.0 [90/1029120] via 155.1.23.2, 00:00:26, Serial1/3
[90/1029120] via 155.1.13.1, 00:00:26, Serial1/2
D EX 220.20.3.0/24 [170/1026560] via 155.1.0.5, 00:00:25, Serial1/0.1
D*EX 200.0.0.0/24 [170/1154560] via 155.1.13.1, 00:49:29, Serial1/2
54.0.0.0/24 is subnetted, 1 subnets
D EX 54.1.1.0 [170/1026560] via 155.1.13.1, 00:49:29, Serial1/2
D EX 200.0.2.0/24 [170/1154560] via 155.1.13.1, 00:49:29, Serial1/2
D EX 192.10.1.0/24 [170/1026560] via 155.1.0.5, 00:00:25, Serial1/0.1
31.0.0.0/16 is subnetted, 4 subnets
D EX 31.3.0.0 [170/1049600] via 155.1.0.5, 00:00:34, Serial1/0.1
D EX 31.2.0.0 [170/1049600] via 155.1.0.5, 00:00:34, Serial1/0.1
D EX 31.1.0.0 [170/1049600] via 155.1.0.5, 00:00:34, Serial1/0.1
D EX 31.0.0.0 [170/1049600] via 155.1.0.5, 00:00:34, Serial1/0.1
150.1.0.0/24 is subnetted, 7 subnets
D 150.1.7.0 [90/1157120] via 155.1.0.5, 00:00:33, Serial1/0.1
D 150.1.6.0 [90/1154560] via 155.1.0.5, 00:00:32, Serial1/0.1
D 150.1.5.0 [90/1152000] via 155.1.23.2, 00:00:33, Serial1/3
[90/1152000] via 155.1.13.1, 00:00:33, Serial1/2
D 150.1.4.0 [90/1152000] via 155.1.0.5, 00:18:47, Serial1/0.1
D 150.1.1.0 [90/1154560] via 155.1.0.5, 00:00:32, Serial1/0.1
D 150.1.9.0 [90/128512] via 155.1.37.7, 00:49:36, FastEthernet0/0
D EX 205.90.31.0/24 [170/1026560] via 155.1.0.5, 00:00:33, Serial1/0.1
30.0.0.0/16 is subnetted, 4 subnets
D EX 30.2.0.0 [170/1049600] via 155.1.0.5, 00:00:34, Serial1/0.1
D EX 30.3.0.0 [170/1049600] via 155.1.0.5, 00:00:34, Serial1/0.1
D EX 30.0.0.0 [170/1049600] via 155.1.0.5, 00:00:34, Serial1/0.1
D EX 30.1.0.0 [170/1049600] via 155.1.0.5, 00:00:34, Serial1/0.1
D* 0.0.0.0/0 [90/1026560] via 155.1.0.5, 00:18:47, Serial1/0.1