What are the three tables that EIGRP uses?
Highlight for answer: EIGRP neighbor table, EIGRP topology table, and the IP routing table.
What are the three tables that EIGRP uses?
Highlight for answer: EIGRP neighbor table, EIGRP topology table, and the IP routing table.
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)
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
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. 🙂
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
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
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
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.
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:
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.
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.”
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:
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?
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:
“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.