Core Knowledge Question of the Day: 12 July 2009

What are the three tables that EIGRP uses?

Highlight for answer: EIGRP neighbor table, EIGRP topology table, and the IP routing table.

Core Knowledge Question of the Day: 30 May 2009

Which protocol enables EIGRP routers to determine whether a path advertised by a neighbor is looped or loop-free, and allows a router running EIGRP to find alternate paths without waiting on updates from other routers?

Highlight for answer: Diffusing update algorithm (DUAL)

Core Knowledge Question of the Day: 29 April 2009

By default, any single EIGRP process may use up to what percentage of the configured bandwidth on any link during periods of network convergence?

Highlight for answer: 50

Secrets Of The EIGRP Offset-List Command

The following post is loooooong and of no interest to 99.9999999999% of the world.  I was going over EIGRP commands and had a problem with an EIGRP offset-list not altering the EIGRP metric the way that it should have.  In the process of playing with this command I think that I’ve found the method that this command uses to alter the EIGRP metric of a route.

I did warn you that this was only interesting to a handful of geeks.

Here’s the network topology.  Really basic:

r1————r2

r1 and r2 are connected by a single serial link (s0/0 on both devices).  Both routers running EIGRP on all interfaces.  There are 3 loopbacks being advertised on each device.

r1#sh ip ei int
IP-EIGRP interfaces for process 100

Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/0 1 0/0        27       0/15          91           0
Lo0                0        0/0         0       0/10           0           0
Lo1                0        0/0         0       0/10           0           0
Lo2                0        0/0         0       0/10           0           0

r1#sh ip ei nei
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
(sec)         (ms)       Cnt Num
0   10.1.12.2 Se0/0 13 00:01:47   27   200  0  3

r1#sh ip route ei
D    222.222.222.0/24 [90/2297856] via 10.1.12.2, 00:01:55, Serial0/0
2.0.0.0/24 is subnetted, 1 subnets
D       2.2.2.0 [90/2297856] via 10.1.12.2, 00:01:55, Serial0/0
22.0.0.0/24 is subnetted, 1 subnets
D       22.22.22.0 [90/2297856] via 10.1.12.2, 00:01:55, Serial0/0

r2#sh ip ei int
IP-EIGRP interfaces for process 100

Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/0 1 0/0        34       0/15         147           0
Lo0                0        0/0         0       0/10           0           0
Lo1                0        0/0         0       0/10           0           0
Lo2                0        0/0         0       0/10           0           0

r2#sh ip ei nei
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
(sec)         (ms)       Cnt Num
0   10.1.12.1 Se0/0 13 00:02:15   34   204  0  3

r2#sh ip route ei
1.0.0.0/24 is subnetted, 1 subnets
D       1.1.1.0 [90/2297856] via 10.1.12.1, 00:02:19, Serial0/0
111.0.0.0/24 is subnetted, 1 subnets
D       111.111.111.0 [90/2297856] via 10.1.12.1, 00:02:19, Serial0/0
11.0.0.0/24 is subnetted, 1 subnets
D       11.11.11.0 [90/2297856] via 10.1.12.1, 00:02:19, Serial0/0

Okay to start with let’s see the routing information for net 1.1.1.0/24 on r2:

r2#sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 2297856, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:03:17 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:03:17 ago, via Serial0/0
Route metric is 2297856, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

On r2 let’s add 100 to the EIGRP metrics of all EIGRP routes advertised in s0/0 from r1:
[NOTE: access-list 0 selects all networks]

r2(config)#router ei 100
r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 00:15:01.055: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 2297956, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:08 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:08 ago, via Serial0/0
Route metric is 2297956, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Interesting…we’ve added 100 to the EIGRP metric as expected.  The ‘total delay’ has also increased by 3 microseconds (not expected).  It seems that the EIGRP offset-list alters the EIGRP variable in order to change the overall EIGRP metric.  EIGRP uses this easy to remember :-) equation to calculate its metric:

If k5 equals 0, the composite EIGRP metric is computed according to the following formula:
metric = [k1 * bandwidth + (k2 * bandwidth)/(256 – load) + k3 * delay]

If k5 does not equal zero, an additional operation is performed:
metric = metric * [k5/(reliability + k4)]

This led me to wonder what would happen if we took delay out of the EIGRP equation.  We can do that by setting the EIGRP K-Value for delay to 0 and just leaving bandwidth K-Value (we’ll need to do this on both routers):

r1(config)#  router ei 100
r1(config-router)#  metric weights 0 1 0 0 0 0

r2(config)#router ei 100
r2(config-router)#metric weights 0 1 0 0 0 0
r2(config-router)#no offset-list 0 in 100 s0/0

r2(config-router)#do sh ip proto | i EIGRP metric weight
EIGRP metric weight K1=1, K2=0, K3=0, K4=0, K5=0

Let’s see our metric before applying the offset-list:

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 1657856, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:32 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:32 ago, via Serial0/0
Route metric is 1657856, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Okay, let’s reapply the offset-list:

r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 03:04:44.711: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 1657856, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:10 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:10 ago, via Serial0/0
Route metric is 1657856, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

BOOYAH!  The offset-list is supposed to increase the EIGRP metric by 100.  We can see that the metric did NOT change (still 1657856), BUT the total delay increased by 3 microseconds.  It looks like we’ve discovered the mechanism used by the EIGRP offset-list to change the EIGRP metric.  We’ve also discovered that setting the delay K-Value to zero “breaks” the offset-list function.

One last experiment.  Let’s see if the offset-list is intelligent enough to handle a delay K-Value of more than 1:

r1(config-router)#metric weights 0 1 0 4 0 0

r2(config-router)#metric weights 0 1 0 4 0 0
r2(config-router)#no offset-list 0 in 100 s0/0

r2(config-router)#do sh ip proto | i EIGRP metric weight
EIGRP metric weight K1=1, K2=0, K3=4, K4=0, K5=0

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 4217856, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:01:09 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:01:09 ago, via Serial0/0
Route metric is 4217856, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 03:11:56.439: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 4218256, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:07 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:07 ago, via Serial0/0
Route metric is 4218256, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Weird.  I would have thought that this would have worked as we have our default K-Values but have just increased the weight of delay 4 times.  We can see that the delay was once again increased by 3 microseconds, but the overall metric was unaffected.  Weird.

Thank you to reader Rich for pointing out that 4217856 and 4218256 are NOT the same value.  :-)  The EIGRP metric increased by 400 instead of the 100 that we specified in the offset-list.  That’s because the K-Value for delay is set to 4 times the default.

Hmmm…one more experiment.  Let’s set the delay K-Value back to 1 but make it the only variable used for the EIGRP metric:

r1(config-router)#metric weights 0 0 0 1 0 0

r2(config-router)#metric weights 0 0 0 1 0 0
r2(config-router)#no offset-list 0 in 100 s0/0

r2(config-router)#do sh ip proto | i EIGRP metric weight
EIGRP metric weight K1=0, K2=0, K3=1, K4=0, K5=0

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 640000, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:33 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:33 ago, via Serial0/0
Route metric is 640000, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Let’s reapply the offset-list and see what happens:

r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 03:22:54.319: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 640100, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:06 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:06 ago, via Serial0/0
Route metric is 640100, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

It worked.  So we don’t need to have the bandwidth K-Value “turned on” for the offset-list to work.

Last experiment…I promise.  Let’s set the delay K-Value to 4 and set the other K-Values to 0:

r1(config-router)#metric weights 0 0 0 4 0 0

r2(config-router)#metric weights 0 0 0 4 0 0
r2(config-router)#no offset-list 0 in 100 s0/0

r2(config-router)#do sh ip proto | i EIGRP metric weight
EIGRP metric weight K1=0, K2=0, K3=4, K4=0, K5=0

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 2560000, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:14 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:14 ago, via Serial0/0
Route metric is 2560000, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Reapply the offset-list:

r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 03:33:52.279: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 2560400, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:06 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:06 ago, via Serial0/0
Route metric is 2560400, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Ah hah!  The metric changed by 400 instead of 100 (as we had configured it to be offset).  I think that this is pretty good evidence that the EIGRP offset-list only alters the EIGRP delay variable and is only accurate when that K-Value is set to 1.

I don’t think that this will affect you in real life (who’s changing K-Values and using offset-lists with EIGRP?) but it could possibly come up in a lab.  I could forsee a task that has you change the K-Values and then another task that has you altering EIGRP metrics (probably for some evil unequal-cost load-balancing task).  At least now you’ll know why your perfectly executed offset-list solution has failed.  :-)

EIGRP Offset-Lists and Show IP Protocols

It’s funny how you may have done a task many times and not noticed an IOS feature.  I applied an offset-list to some EIGRP routes and stumbled across some output I had never noticed before (to be fair I usually use offset-lists with RIP and not EIGRP):

No EIGRP offset-list(s) applied:

Rack17SW1#sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is “eigrp 10″
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 10
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    0.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    156.17.27.2           90      00:24:46
    156.17.67.6           90      00:24:46
  Distance: internal 90 external 170

With the offset-lists applied (different paths based on whether the 3rd octet is even or odd):

router eigrp 10
 timers active-time 5
 offset-list ODD in 666666666 Vlan18
 offset-list EVEN in 666666666 Vlan58
 network 0.0.0.0
 no auto-summary
!
ip access-list standard EVEN
 permit 0.0.0.0 255.255.254.255
ip access-list standard ODD
 permit 0.0.1.0 255.255.254.255

Notice the difference?  :-)

Rack17SW2#sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is “eigrp 10″
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Incoming routes in Vlan18 will have 666666666 added to metric if on list ODD
  Incoming routes in Vlan58 will have 666666666 added to metric if on list EVEN
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 10
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    0.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    156.17.18.1           90      00:17:55
    156.17.58.5           90      00:17:55
  Distance: internal 90 external 170

Disabling EIGRP Unequal-Cost Load-Balancing

This may be old news to you guys but I had never seen the “traffic-share min across-interfaces” command before.  I was messing about with EIGRP unequal cost load-sharing the other day and came across it.

r1(config-router)#traffic-share ?
  balanced  Share inversely proportional to metric
  min       All traffic shared among min metric paths <-what’s this?

r1(config-router)#traffic-share min ?
  across-interfaces  Use different interfaces for equal-cost paths
r1(config-router)#traffic-share min across-interfaces

Weird.  It turns off unequal-cost load balancing by not allowing traffic over the Feasable Successor route(s) regardless of the variance command:

r1(config-router)#var 4
*Mar  2 00:05:02.000: %FIB-4-UNEQUAL: Range of unequal path weightings too large for prefix 150.1.6.0/24. Some available paths may not be used.

r1(config-router)#do sh ip route 164.1.26.0 255.255.255.0
Routing entry for 164.1.26.0/24
  Known via “eigrp 100″, distance 90, metric 3026432, type internal
  Redistributing via eigrp 100
  Last update from 164.1.12.2 on Serial0/0, 00:00:03 ago
  Routing Descriptor Blocks:
  * 164.1.13.3, from 164.1.13.3, 00:00:03 ago, via Serial0/1
      Route metric is 3026432, traffic share count is 1
      Total delay is 40100 microseconds, minimum bandwidth is 1280 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
    164.1.12.2, from 164.1.12.2, 00:00:03 ago, via Serial0/0
      Route metric is 10514432, traffic share count is 0
      Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

r1(config-router)#var 40
r1(config-router)#do sh ip route 164.1.26.0 255.255.255.0
Routing entry for 164.1.26.0/24
  Known via “eigrp 100″, distance 90, metric 3026432, type internal
  Redistributing via eigrp 100
  Last update from 164.1.12.2 on Serial0/0, 00:00:02 ago
  Routing Descriptor Blocks:
  * 164.1.13.3, from 164.1.13.3, 00:00:02 ago, via Serial0/1
      Route metric is 3026432, traffic share count is 1
      Total delay is 40100 microseconds, minimum bandwidth is 1280 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
    164.1.12.2, from 164.1.12.2, 00:00:02 ago, via Serial0/0
      Route metric is 10514432, traffic share count is 0
      Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Here’s the explanation:

Similarly, 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.

router eigrp 1
 network x.x.x.x
 variance 3
 traffic-share min across-interfaces

In this situation, EIGRP sends packets only through E-C-A, which is the best path to the destination network. This is identical to the forwarding behavior 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. 

It turns out that this command is available for all routing protocols.

r1(config)#router os 100
r1(config-router)#traffic-share min ?
  across-interfaces  Use different interfaces for equal-cost paths
r1(config)#router rip
r1(config-router)#traffic-share min ?
  across-interfaces  Use different interfaces for equal-cost paths

Lab Tip: Clear Your EIGRP Process

I spent a good chunk of my weekend going over EIGRP metric manipulation and how it affects EIGRP unequal-cost load-balancing.  More than a few times I ran into weird output like routes dropping, metric values not changing, and even this doozy:

r1#sh ip ei top 164.1.26.0 255.255.255.0
IP-EIGRP (AS 100): Topology entry for 164.1.26.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2693120
  Routing Descriptor Blocks:
  164.1.13.3 (Serial0/1), from 164.1.13.3, Send flag is 0x0
      Composite metric is (3026432/2514432), Route is Internal
      Vector metric:
        Minimum bandwidth is 1280 Kbit
        Total delay is 40100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
  164.1.12.2 (Serial0/0), from 164.1.12.2, Send flag is 0x0
      Composite metric is (10514432/28160), Route is Internal
      Vector metric:
        Minimum bandwidth is 256 Kbit
        Total delay is 20100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1

The AD of the successor is not equal to the FD????

By clearing the EIGRP process, these discrepancies go away.  You can do this the soft way:

r1#clear ip eigrp 100 neighbors soft
*Mar  2 05:22:13.522: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 164.1.12.2 (Serial0/0) is resync: manually cleared

Or the rough way:

r1#clear ip eigrp 100 neighbors
*Mar  2 05:22:48.708: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 164.1.12.2 (Serial0/0) is down: manually cleared
*Mar  2 05:22:49.782: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 164.1.12.2 (Serial0/0) is up: new adjacency

I like it rough.  :-)

In the case of EIGRP it really doesn’t matter as the protocol reconverges so quickly.

Internetwork Expert Volume II: Lab 8 – Section 3

Section 3 – Interior Gateway Routing – 16 Points

3.1 OSPF

Simple OSPF task.  The only odd bit is that you’ll be configuring OSPF over the PPPoFR network.  It makes sense that the OSPF network type is point-to-point.  :-)

r3(config-router)#do sh ip os int | i proto|Type
Multilink1 is up, line protocol is up
  Process ID 100, Router ID 150.1.3.3, Network Type POINT_TO_POINT, Cost: 1

r2#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.3.3         0   FULL/  -        00:00:38    174.1.23.3      Multilink1

“Authenticate the OSPF adjacency between r2 and r6 using OSPF type 1 authentication.”

Crap.  I think that type 1 is just clear-text (type 0 = null and type 7 = md5).  It’s weird that the task does not mention a password.  I used the old standby of “CISCO”

r6(config-router)#int FastEthernet0/1.26
r6(config-subif)#ip ospf authentication
r6(config-subif)#ip ospf authentication-key CISCO

r2(config-subif)#do sh ip os int Gi0/0.26 | i proto|authe
GigabitEthernet0/0.26 is up, line protocol is up
  Simple password authentication enabled 

3.2 OSPF

Configure area 38 so that “external LSAs” are not advertised in.

We know that we’re done to stub or totally stubby at this point.

“Ensure that devices in OSPF area 38 still have specific forwarding information about prefixes originated in other OSPF areas.”

So we need to allow IA routes (LSA 3).  That sounds like a stub area to me.

3.3 OSPF

Create area 67 and then summarize 150.1.6.6 and 150.1.7.7 with no overlapping address space:

7 0000011|1
6 0000011|0

150.1.6.0/23 or 150.1.6.0 255.255.254.0

Summary will move from area to area so use…..area range.  :-)

r6(config)#router os 100
r6(config-router)#area 67 range 150.1.6.0 255.255.254.0

r3#sh ip route 150.1.6.6
Routing entry for 150.1.6.0/23
  Known via “ospf 100″, distance 110, metric 3, type inter area
  Last update from 174.1.23.2 on Multilink1, 00:00:36 ago
  Routing Descriptor Blocks:
  * 174.1.23.2, from 150.1.6.6, 00:00:36 ago, via Multilink1
      Route metric is 3, traffic share count is 1

r3#sh ip route 150.1.7.7
Routing entry for 150.1.6.0/23
  Known via “ospf 100″, distance 110, metric 3, type inter area
  Last update from 174.1.23.2 on Multilink1, 00:00:50 ago
  Routing Descriptor Blocks:
  * 174.1.23.2, from 150.1.6.6, 00:00:50 ago, via Multilink1
      Route metric is 3, traffic share count is 1

3.4 EIGRP

Basic EIGRP task.  The only confusing bit is that the task asks you to advertise the lo0 interface of all of the EIGRP devices into EIGRP.  r3 is already advertising its lo0 interface into OSPF.  They must have meant all of the EIGRP devices except r3 (the solution guide bears this out).

Remember to disable split-horizon on the Frame Relay hub (r1):

r1(config-router)#int s0/0
r1(config-if)#no ip split-horizon eigrp 1024

3.5 RIP

Easy RIP task with authentication.

3.6 IGP Redistribution

Redistribute between RIP and EIGRP on r5 and then between OSPF and EIGRP where needed.

Remember that OSPF area 38 is a stub area so it’s not going to let in any external routes.  That means our OSPF<->EIGRP redistribution needs to happen on r3.

I ran into one issue.  I had a route to 174.1.31.0/24 on r1 (connected) as well as r2-3(OSPF).  But r4 and r5 did not have the route.

The problem is that r3 gets that route via OSPF and then advertises it to r1.  R1 does not install the route from r3 because it has that network as connected.  The route does not get passed on to the EIGRP routers behind r1.

I need to either redistribute that connected interface into EIGRP on r1 or find some way to have r1 prefer the route to r3 over the connected route.

r1(config)#route-map CONN->EIGRP
r1(config-route-map)#match int Fa0/0.13

r1(config-route-map)#router ei 1024
r1(config-router)#redist conn met 1 1 1 1 1 route-map CONN->EIGRP

r4#sh ip route 174.1.31.1
Routing entry for 174.1.31.0/24
  Known via “eigrp 1024″, distance 170, metric 2560512256, type external
  Redistributing via eigrp 1024
  Last update from 174.1.145.1 on Serial0/0, 00:00:30 ago
  Routing Descriptor Blocks:
  * 174.1.145.1, from 174.1.145.1, 00:00:30 ago, via Serial0/0
      Route metric is 2560512256, traffic share count is 1
      Total delay is 20010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1

r4#trace 174.1.31.1

Type escape sequence to abort.
Tracing the route to 174.1.31.1

  1 174.1.145.1 4 msec *  4 msec

I ended up with full reachability by only redistributing RIP<->EIGRP on r5, OSPF<->EIGRP on r3, and Connected (fa0/0.13) -> EIGRP on r1.

IE went a different route.  Then redistributed OSPF->EIGRP on r1, OSPF<->EIGRP on r3, as well as RIP<->EIGRP on r5.

3.7 Load Distribution

Configure the network so that traffic from r4 to r5 is distributed in a 4:1 ratio between the Ethernet connection and the Frame Relay connection.

I messed with this for tooooooooo long.  I tried messing with the metric weight and I was still mindfucked.  I’ll just eat the 3 points and move on.

Update:

I have to try this tomorrow:

Becoming a CCIE: EIGRP Unequal path load balancing

Internetwork Expert Volume II: Lab 5 – Section 3

Interior Gateway Routing – 20 Points

3.1 OSPF

You need to configure OSPF over the partial-mesh Frame Relay cloud, but you cannot change the OSPF network type on r3:

r2(config-router)#do sh ip os int s0/0/0.1 | i Type
  Process ID 100, Router ID 150.1.2.2, Network Type POINT_TO_POINT, Cost: 64

r3(config-router)#do sh ip os int s0/0:0 | i Type
  Process ID 100, Router ID 150.1.3.3, Network Type NON_BROADCAST, Cost: 65

r4(config-router)#do sh ip os int s0/0 | i Type
  Process ID 100, Router ID 150.1.4.4, Network Type NON_BROADCAST, Cost: 65

r5(config-router)#do sh ip os int s0/0 | i Type
  Process ID 100, Router ID 150.1.5.5, Network Type NON_BROADCAST, Cost: 65

So all that really means is that you’ll need to use the OSPF non-broadcast network type.  You’ll also need to configure neighbor statements.  Since r3 is the only device with direct connections to all of the other routers, you’ll want to make it the DR.

r3(config-router)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.2.2         0   FULL/DROTHER    00:01:46    162.1.0.2       Serial0/0:0
150.1.5.5         0   FULL/DROTHER    00:01:51    162.1.0.5       Serial0/0:0
150.1.4.4         0   FULL/DROTHER    00:01:51    162.1.0.4       Serial0/0:0

The only point that I wasn’t clear on was whether or not to establish a neighbor relationship between r4 and r5.  I did not configure them as peers, but I would have clarified this with the proctor.  If you were to peer these routers then you would need to make one of them the DR so you would need to remove the ‘ip ospf priority 0′ on one of the routers.  You would also need to configure a neighbor statement on the DR.

The IE solution did not peer these routers.

3.2 OSPF

Configure OSPF area 27 on sw1 and then ensure that the only OSPF route it will see is a default route generated by r2.  This sounds like a totally stubby area:

Before:
sw1#sh ip route os
     162.1.0.0/24 is subnetted, 5 subnets
O IA    162.1.55.0 [110/66] via 162.1.27.2, 00:00:15, Vlan27
O IA    162.1.0.0 [110/65] via 162.1.27.2, 00:00:15, Vlan27
O IA    162.1.5.0 [110/66] via 162.1.27.2, 00:00:15, Vlan27
     150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
O IA    150.1.5.5/32 [110/66] via 162.1.27.2, 00:00:15, Vlan27
O IA    150.1.4.4/32 [110/66] via 162.1.27.2, 00:00:15, Vlan27
O IA    150.1.3.3/32 [110/66] via 162.1.27.2, 00:00:15, Vlan27
O IA    150.1.2.2/32 [110/2] via 162.1.27.2, 00:00:15, Vlan27

After:
r2(config)#router os 100
r2(config-router)#area 27 stub no-summary

sw1(config)#router os 100
sw1(config-router)#area 27 stub

sw1#sh ip route os
O*IA 0.0.0.0/0 [110/2] via 162.1.27.2, 00:00:41, Vlan27

3.3 EIGRP

“Enable EIGRP on all interfaces of sw2, but do not use redistribution or more than one network statement to accomplish this.”

sw2(config)#ip routi
sw2(config)#router ei 200
sw2(config-router)#net 0.0.0.0

sw2(config-router)#do sh ip ei int
IP-EIGRP interfaces for process 200

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Vl8                0        0/0         0       0/10           0           0
Vl88               0        0/0         0       0/10           0           0
Fa0/15             1        0/0         1       0/10          50           0
Po32               0        0/0         0       0/10           0           0
Lo0                0        0/0         0       0/10           0           0

3.4 EIGRP

Configure EIGRP to use bandwidth, delay, and load to compute the EIGRP metric.  Bandwidth should be three times more significant than either delay or load.

metric weights (EIGRP)

Command Defaults
tos: 0
k1: 1
k2: 0
k3: 1
k4: 0
k5: 0

You need to be careful with these k-values.  You can use the EIGRP metric equation to decipher which k-value refers to with metric variable:

If k5 equals 0, the composite EIGRP metric is computed according to the following formula:

metric = [k1 * bandwidth + (k2 * bandwidth)/(256 – load) + k3 * delay]

If k5 does not equal zero, an additional operation is performed:

metric = metric * [k5/(reliability + k4)]

k1 = bandwidth
k2 = load
k3 = delay

sw2(config-router)#metric weights 0 3 1 1 0 0

r3(config-router)#do sh ip proto | i EIGRP metric
  EIGRP metric weight K1=3, K2=1, K3=1, K4=0, K5=0

3.5 Default Routing

Configure r3 to adverise a default route to the rest of the OSPF network.

“In order to help prevent traffic black holses ensure that r3 drops traffic for all destinations it does not have a longer match for.”

default-information originate (OSPF)

The software still must have a default route for itself before it generates one, except when you have specified the always keyword.

(Optional) Always advertises the default route regardless of whether the software has a default route.

The IE solution guide has a nice write up about the benifits and pitfalls of the ‘always’ keyword.

3.6 Routing Redundancy

Configure r5 to use the PTP serial interface (no advertised into any IGP) if the Frame Relay connection is lost.  You are allowed to use static routes to accomplish this.

Sounds like a floating static route to me (I wish I would have recognized this on a recent Mock Lab…oh well).

r5(config)#ip route 0.0.0.0 0.0.0.0 162.1.45.4 111

r4(config)#do sh ip route | i via 162.1.0.5
O       162.1.55.0/24 [110/66] via 162.1.0.5, 00:11:12, Serial0/0
O       162.1.5.0/24 [110/66] via 162.1.0.5, 00:11:12, Serial0/0
O       150.1.5.5/32 [110/66] via 162.1.0.5, 00:11:12, Serial0/0

r4(config)#ip route 162.1.55.0 255.255.255.0 162.1.45.5 111
r4(config)#ip route 162.1.5.0 255.255.255.0 162.1.45.5 111
r4(config)#ip route 162.1.5.5 255.255.255.255 162.1.45.5 111

r4(config)#router os 100
r4(config-router)#redist static subnets

Let’s test this by shutting down r5’s connection to the Frame cloud:
r5(config)#int s0/0
r5(config-if)#shut

r5#sh ip route | b Gate
Gateway of last resort is 162.1.45.4 to network 0.0.0.0 

     162.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
C       162.1.45.4/32 is directly connected, Serial0/1
C       162.1.45.0/24 is directly connected, Serial0/1
C       162.1.55.0/24 is directly connected, FastEthernet0/1
C       162.1.5.0/24 is directly connected, FastEthernet0/0
     150.1.0.0/24 is subnetted, 1 subnets
C       150.1.5.0 is directly connected, Loopback0
S*   0.0.0.0/0 [111/0] via 162.1.45.4 

I did run into a problem with connectivity between r3 and r5:

r3#p 162.1.55.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 162.1.55.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms

r3#p 162.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 162.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/12 ms

r3#p 162.1.45.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 162.1.45.5, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

r3#p 150.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.5.5, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

r3#sh ip route 162.1.45.5
% Subnet not in table

Makes sense since it’s not being advertised via an IGP (we’ll take care of this during the redistribution task).

r3#sh ip route 150.1.5.5
Routing entry for 150.1.0.0/16
  Known via “eigrp 200″, distance 90, metric 207460, type internal
  Redistributing via eigrp 200
  Last update from 162.1.38.8 on FastEthernet0/0, 00:53:52 ago
  Routing Descriptor Blocks:
  * 162.1.38.8, from 162.1.38.8, 00:53:52 ago, via FastEthernet0/0
      Route metric is 207460, traffic share count is 1
      Total delay is 5100 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Ummmm…..I think I missed a “no auto-summary” somewhere.  :-)

sw2(config-router)#do sh run | b router ei
router eigrp 200
 network 0.0.0.0
 metric weights 0 3 1 1 0 0
 auto-summary

sw2(config-router)#router ei 200
sw2(config-router)#no au

I’ve been doing that a lot lately.  :-(

r3#sh ip route 150.1.5.5
% Subnet not in table

That’s odd, I thought that I had a floating static route to the loopback on r4:

r4#sh run | i ip route
ip route 162.1.5.0 255.255.255.0 162.1.45.5 111
ip route 162.1.5.5 255.255.255.255 162.1.45.5 111
ip route 162.1.55.0 255.255.255.0 162.1.45.5 111

Damn these fat fingers!!!!

r4(config)#no ip route 162.1.5.5 255.255.255.255 162.1.45.5 111
r4(config)#ip route 150.1.5.5 255.255.255.255 162.1.45.5 111

r3#sh ip route | i 150.1.5.
O E2    150.1.5.5/32 [110/20] via 162.1.0.4, 00:00:33, Serial0/0:0

r3#p 150.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms

Much better.

3.7 RIPv2

Easy RIP task.  One slight twist:

“As an additional security precaution configure r1 and r6 so that no unautorized devices can receive RIP updates sent out on VLAN 162.”

neighbor (RIP)

The IE solution guide has r6 advertising VLAN 6 into RIP although it is not mentioned in the task (although it does look like it should be advertised into RIP based on the IGP drawing).

3.8 IGP Redistribution

“Redistribute in the minumum places necessary to gain full reachability thoughout the network.”
“Routers in the OSPF domain should have the miniumum amount of routes neeeded to reach the RIP routes learned from bb3.”
“Do not overlap any address space to accomplish this.”

If you hadn’t figured out that they were asking for a summary route that last requirement kind of makes it obvious.

r4#sh ip route rip
     31.0.0.0/16 is subnetted, 4 subnets
R       31.3.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
R       31.2.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
R       31.1.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
R       31.0.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
     30.0.0.0/16 is subnetted, 4 subnets
R       30.2.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
R       30.3.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
R       30.0.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0
R       30.1.0.0 [120/1] via 204.12.1.254, 00:00:15, FastEthernet0/0

We can try to do this with a single summary but we’ll be overlapping address space, so we need two /14 summaries:

r4(config)#router os 100
r4(config-router)#summary-address 30.0.0.0 255.252.0.0
r4(config-router)#summary-address 31.0.0.0 255.252.0.0

r4#sh ip os sum

OSPF Process 100, Summary-address

30.0.0.0/255.252.0.0 Metric 16777215, Type 0, Tag 0
31.0.0.0/255.252.0.0 Metric 16777215, Type 0, Tag 0

The redistribution task was fairly easy.  There are no mutiple points of mutual redistribution between two protocols.  The only ‘gotcha’ is to remember to advertise the s0/1 interface into OSPF on r4.  This will ensure that we have reachability to 162.1.45.5 if the s0/0 interface goes down on r5 (task 3.6)

With r5’s s0/0 shut down:
r3#p 162.1.45.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 162.1.45.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/12 ms

The IE solution guide has some strangeness on r3:

Task 3.8 on solution guide Why only VLAN162 in

Question Of The Day: 25 April, 2008

Topic: EIGRP

r1 and r2 are directly connected via their respective fa0/0 interfaces:

r1:
interface FastEthernet0/0
  ip address 10.1.12.1
  ip hold-time eigrp 100 30
  ip hello-interval eigrp 100 5
!
router eigrp 100
  no auto-summary
  network 10.1.12.1 0.0.0.0

r2:
interface FastEthernet0/0
  ip address 10.1.12.2
  ip hold-time eigrp 100 60
  ip hello-interval eigrp 100 10
!
router eigrp 100
  no auto-summary
  network 10.1.12.2 0.0.0.0

Will r1 and r2 for an EIGRP neighbor relationship over the Ethernet link between them?

Click Here For The Answer

---

Yesterday’s Question

Question Of The Day: 24 April, 2008 

Topic: Route-Maps

The engineer in charge of r1 is tasked with routing packets to r2 (10.1.1.2) if they meet any of the following conditions:

1) Any packets coming in r1’s fa0/0 interface
2) Any packets with the tag 1234
3) Any D EX routes (r1 is only running EIGRP)

The engineer asks you to peer review his solution:

route-map LOOPBACK_AND_VLAN6 permit 10
 match interface FastEthernet0/0
 match tag 1234
 match route-type external
 set ip next-hop 10.1.1.2

Will this route map meet the requirements?

Answer: No.

In a route-map clause with multiple match statements, ALL match statements must be fullfilled. 

Route-Maps for IP Routing Protocol Redistribution Configuration

A match or set command in each clause can be missed or repeated several times, if one of these conditions exist:

If several match commands are present in a clause, all must succeed for a given route in order for that route to match the clause (in other words, the logical AND algorithm is applied for multiple match commands).

In our case only routes with a next-hop out fa0/0 AND a route tag of of 1234 AND a route-type of external will have their next-hop set to 10.1.1.2.  The task requires that ANY of those conditions must be met.

Steve makes a nice catch:

“Is it wrong because the ‘match interface FastEthernet0/0 line will match packets routed _out_ Fa0/0 not in?”

He’s right.  I boned up the first requirement of the question:

match interface (IP)

“To distribute any routes that have their next hop out one of the interfaces specified, use the match interface command in route-map configuration mode.”

We can write the route-map to meet the requirements by putting each requirement in its own separate clause:

route-map LOOPBACK_AND_VLAN6 permit 10
 match interface FastEthernet0/0
 set ip next-hop 10.1.1.2
!
route-map LOOPBACK_AND_VLAN6 permit 20
 match tag 1234
 set ip next-hop 10.1.1.2
!
route-map LOOPBACK_AND_VLAN6 permit 30
 match route-type external
 set ip next-hop 10.1.1.2
!
route-map LOOPBACK_AND_VLAN6 permit 1000

Each clause of the route-map will be evaluated until a match is made.  The last clause is included to override the implicit deny.  That way any packets that do not meet any of the clauses will be routed normally.