CCIE Pursuit Blog

December 30, 2008

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.  🙂

April 28, 2008

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

April 12, 2008

Internetwork Expert Volume III: Lab 5 – Section 4

Interior Gateway Routing – 25 Points

4.1 EIGRP

“Do not send multicast EIGRP updates within VLAN 14”

neighbor (EIGRP)

Remember that you need to configure this on both routers (unlike OSPF):

r1
router eigrp 10
 network 128.1.14.1 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.1.1
 neighbor 128.1.14.4 FastEthernet0/0.2

r4
router eigrp 10
 network 128.1.14.4 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.4.4
 neighbor 128.1.14.1 FastEthernet0/0

4.2 OSPF

Configure OSPF area 0.0.0.0.  This is just the dotted decimal equivalent of area 0.

r1(config-router)#do sh run | sec router os
router ospf 100
 router-id 150.1.1.1
 log-adjacency-changes
 network 128.1.136.1 0.0.0.0 area 0.0.0.0

r1(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0.1      100   0.0.0.0        128.1.136.1/24     1     WAIT  0/0

4.3 OSPF

“Without enabling OSPF on r3’s interface fa0/0.2 or r6’s interface fa0/0.2, ensure that they will still receive OSPF routers from each other in the event that they lose their connectivity with r1.”

Basically, we need to make sure that r3 and r6 can communicate over their redundant LAN connection if the primary one fails.

I’m thinking that we can tunnel over that second LAN.  The only problem is that you’d need to an a new subnet to do this.  I peeked the solution guide and that exactly what they did, so I guess that it’s alright.

r6(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0.1      100   0.0.0.0         128.1.136.6/24     1     DROTH 2/2
Tu0          100   0.0.0.0         128.1.63.6/24      11111 P2P   1/1

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.1.1         1   FULL/DR         00:00:31    128.1.136.1     FastEthernet0/0.1
150.1.3.3         1   FULL/BDR        00:00:32    128.1.136.3     FastEthernet0/0.1
150.1.3.3         0   FULL/  –        00:00:34    128.1.63.3      Tunnel0

r6(config)#int fa0/0.1
r6(config-subif)#shut
r6(config-subif)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.3.3         0   FULL/  –        00:00:34    128.1.63.3      Tunnel0

4.4 OSPF

Configure OSPF on the PPPoFR network.

The current OPSF network type is point-to-point, which makes sense considering we’re running PPP.  🙂

r5(config-router)#do sh ip os int | i proto|Type
Virtual-Access2 is up, line protocol is up
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1
Virtual-Template1 is down, line protocol is down
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1
Virtual-Access1 is up, line protocol is up
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1

I’m going to need to change the network type because this is a hub-and-spoke network.  Let’s use point-to-multipoint:

r2(config)#int virtual-template 1
r2(config-if)#ip os net non-broadcast

After all is said and done:

r2#sh ip route os
     128.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    128.1.136.0/24 [110/3] via 128.1.125.5, 00:00:58, Virtual-Access1
O IA    128.1.63.0/24 [110/11114] via 128.1.125.5, 00:00:58, Virtual-Access1
O       128.1.125.1/32 [110/2] via 128.1.125.5, 00:00:58, Virtual-Access1

4.5 OSPF

Configure an OSPF stub area.  You’re also going to need a virtual-link as this new stub area is not connected to area 0 (or area 0.0.0.0 in this case 🙂 ).

r2(config-router)#area 125 virtual-link 150.1.1.1

r2(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
VL0          100   0               128.1.125.2/24     2     P2P   1/1
Gi0/0        100   12              128.1.27.2/24      1     BDR   1/1
Vi1          100   125             128.1.125.2/24     1     P2MP  1/1
Vt1          100   125             128.1.125.2/24     1     DOWN  0/0

sw1#sh ip route os
     128.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    128.1.136.0/24 [110/4] via 128.1.27.2, 00:00:40, Vlan72
O IA    128.1.63.0/24 [110/11115] via 128.1.27.2, 00:00:40, Vlan72
O IA    128.1.125.5/32 [110/2] via 128.1.27.2, 00:01:08, Vlan72
O IA    128.1.125.1/32 [110/3] via 128.1.27.2, 00:01:08, Vlan72
O IA    128.1.125.2/32 [110/1] via 128.1.27.2, 00:01:08, Vlan72
O*IA 0.0.0.0/0 [110/2] via 128.1.27.2, 00:01:08, Vlan72

Why all of the virtual-links in the IE solution guide?:

Task 4.5

4.6 OSPF

You’re asked to configure area 51 (hehe) between sw1 and bb2.  The problem is that this new area is non connected to area 0 and you cannot use a virtual-link because area 12 is a stub area.

Another tunnel?  Yup.

Steps:
1) Create tunnel through area 12.
2) Enable OSPF on the tunnel interfaces.  Place them in area 0 (0.0.0.0).

I had to ‘ip os mtu-ignore’ on tu0 on r2.

4.7 OSPF Loopback Advertisements

Advertise a bunch of loopbacks into a couple of non-existant areas.  If everything is configured correctly you should see all of the loopbacks on sw1:

sw1(config-router)#do sh ip route os | i 150.1.
     150.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    150.1.6.6/32 [110/11115] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.5.5/32 [110/11113] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.3.3/32 [110/11115] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.2.2/32 [110/11112] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.1.1/32 [110/11114] via 128.1.72.2, 00:00:09, Tunnel0

4.8 RIPv2

A straight-forward, easy task.  Thankfully!  🙂

4.9 Default Routing

Configure r4 to generate a default router to sw2 but not to r5.  Don’t use a distribute-list.

We can add a route-map to the ‘default-information-originate’ under the RIP process:

r4(config-router)#default-information originate ?
  route-map  Route-map reference
  <cr>

default-information originate (RIP)

So how do I write a route-map to only advertise to sw2?

r4(config-router)#do sh ip proto | sec Default version
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/1       2     2
    Dialer0               2     2

I want to send the default out fa0/1 and not dialer0 interface.

r4(config-route-map)#set ?
  interface         Output interface

route-map RIP_DEFAULT permit 10
 set interface FastEthernet0/1
!
router rip
 default-information originate route-map RIP_DEFAULT

sw2#sh ip route rip | i 0.0.0.0
R*   0.0.0.0/0
[120/1] via 128.1.48.4, 00:00:06, Vlan48

r5#sh ip route rip | i 0.0.0.0
r5# <-no default route on r5

4.10 Route Filtering

“Configure sw2 so that it will use the default route advertised by r4 to reach the 128.1.14.0/24 network.”
“Use an offset-list on sw2 to accomplish this task.”

This is just a wordy way of telling you to bitbucket the existing route to 128.1.14.0:

Before:
sw2#sh ip route 128.1.14.0
Routing entry for 128.1.14.0/24
  Known via “rip”, distance 120, metric 1
  Redistributing via rip
  Last update from 128.1.48.4 on Vlan48, 00:00:21 ago
  Routing Descriptor Blocks:
  * 128.1.48.4, from 128.1.48.4, 00:00:21 ago, via Vlan48
      Route metric is 1, traffic share count is 1

After:
access-list 71 permit 128.1.14.0 0.0.0.255
!
router rip
  offset-list 71 in 16 vlan48

sw2#sh ip route 128.1.14.0
% Subnet not in table
sw2#p 128.1.14.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.1.14.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

4.11 IGP Redistribution

Perform mutual redistribution on three different devices.  As with most of the Volume III labs, you may as well do the next task (the redistribution ‘gotcha’) at the same time.

4.12 Redistribution Loop Prevention

“Ensure that the RIP routes redistributed into EIGRP on r4 do not get passed back into RIP from OSPF on r5.”
“Use route tagging to accomplish this task.”

Sweet.  Route tagging is my preferred method.

So I’m going to tag RIP routes on r4 and then filter those same routes with r5:

r4#sh run | sec route-map RIP->EIGRP
 redistribute rip metric 1 1 1 1 1 route-map RIP->EIGRP
route-map RIP->EIGRP permit 10
 set tag 4120

r5#sh run | sec route-map RIP->OSPF
 redistribute ospf 100 metric 1 route-map RIP->OSPF
route-map RIP->OSPF deny 10
 match tag 4120
route-map RIP->OSPF permit 20

Everything was working fine except for 128.1.14.4 (f0/0 on r1).  I finally had to filter this route from passing to OSPF on r1 and everything was fine.

r1#sh run | sec 128_|EIGRP->OSPF
 redistribute eigrp 10 subnets route-map EIGRP->OSPF
ip prefix-list 128_1_14_0 seq 5 permit 128.1.14.0/24
route-map EIGRP->OSPF deny 10
 match ip address prefix-list 128_1_14_0
route-map EIGRP->OSPF permit 20

This didn’t break the requirements of the task, but I still bothered that I couldn’t figure out why this address was unreachable.

The IE solution guide is a mess for these tasks:

Task 4.13

The task asks you to use route tags to accomplish this task but the IE solution shows r5 changing the AD for OSPF external routes???

r5:
router ospf 1
 distance ospf external 121

 

March 9, 2008

Internetwork Expert Volume III: Lab 1 – Section 4

Interior Gateway Routing – 24 Points

4.1 OSPF over NBMA

Nothing new here.  Simple hub-and-spoke OSPF network.  You cannot change the default network type (NBMA on the physical interfaces) so just set the spokes to OSPF priority 0 and configure neighbor statements on the hub.

4.2 OSPF

Very simple OSPF task.  The only issue I ran across was an MTU mismatch between r2 and sw2: 

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

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.10.5.5        1   FULL/DR         00:01:34    140.10.245.5    Serial0/0
150.10.8.8        1   DOWN/DROTHER       –        140.10.28.8     FastEthernet0/0
*Jun 11 12:01:07.591: %OSPF-5-ADJCHG: Process 100, Nbr 150.10.8.8 on FastEthernet0/0 from DOWN to DOWN, Neighbor Down: Ignore timer expired

sw2(config-router)#do sh system mtu

System MTU size is 1504 bytes
System Jumbo MTU size is 1504 bytes
Routing MTU size is 1504 bytes

r2(config-router)#int fa0/0
r2(config-if)#ip os mtu-ignore

*Jun 11 12:01:57.753: %OSPF-5-ADJCHG: Process 100, Nbr 150.10.8.8 on FastEtherne
t0/0 from LOADING to FULL, Loading Done

r2(config-if)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.10.5.5        1   FULL/DR         00:01:54    140.10.245.5    Serial0/0
150.10.8.8        1   FULL/DR         00:00:39    140.10.28.8     FastEthernet0/0

You can also change the system MTU back to 1500 bytes on sw2, but that requires a reload.

4.3 OSPF Stub Area

Easy OSPF stub network task.  There is no ambiguity over what type of OSPF stub to configure.

area stub

Before stub:

sw1(config-router)#do sh ip route os
     140.10.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    140.10.0.128/25 [110/68] via 140.10.57.5, 00:00:13, FastEthernet0/21
O IA    140.10.245.0/24 [110/65] via 140.10.57.5, 00:00:13, FastEthernet0/21
O IA    140.10.0.0/25 [110/67] via 140.10.57.5, 00:00:13, FastEthernet0/21
O IA    140.10.28.0/24 [110/66] via 140.10.57.5, 00:00:13, FastEthernet0/21
O IA    140.10.100.0/24 [110/11] via 140.10.57.5, 00:00:13, FastEthernet0/21

After stub:

sw1#sh ip route os
     140.10.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    140.10.0.128/25 [110/68] via 140.10.57.5, 00:00:04, FastEthernet0/21
O IA    140.10.245.0/24 [110/65] via 140.10.57.5, 00:00:04, FastEthernet0/21
O IA    140.10.0.0/25 [110/67] via 140.10.57.5, 00:00:04, FastEthernet0/21
O IA    140.10.28.0/24 [110/66] via 140.10.57.5, 00:00:04, FastEthernet0/21
O IA    140.10.100.0/24 [110/11] via 140.10.57.5, 00:00:04, FastEthernet0/21
O*IA 0.0.0.0/0 [110/2] via 140.10.57.5, 00:00:04, FastEthernet0/21

4.4 OSPF

Another easy task.  You need to advertise some loopbacks, but the network mask should be /24 not /32.  You’ll need to change the OSPF network type on the loopbacks to point-to-point to accomplish this.  You should see all the loop nets on r5:

r5#sh ip route os | i 150.
     150.10.0.0/24 is subnetted, 9 subnets
O IA    150.10.8.0 [110/66] via 140.10.245.2, 00:01:02, Serial0/0
O IA    150.10.9.0 [110/67] via 140.10.245.2, 00:00:34, Serial0/0
O IA    150.10.10.0 [110/68] via 140.10.245.2, 00:00:18, Serial0/0
O       150.10.4.0 [110/65] via 140.10.245.4, 00:02:31, Serial0/0
O       150.10.6.0 [110/11] via 140.10.100.6, 00:02:57, Ethernet0/0
O       150.10.7.0 [110/11] via 140.10.57.7, 00:01:55, Ethernet0/1
O IA    150.10.2.0 [110/65] via 140.10.245.2, 00:01:22, Serial0/0
O       150.10.3.0 [110/11] via 140.10.100.3, 00:02:57, Ethernet0/0

r5#sh ip route 150.10.10.10
Routing entry for 150.10.10.0/24

4.5 RIP

Very easy RIP configuration.  Just remember to use passive interfaces on devices that have multiple interfaces in the same classful network: 

r4#sh ip int br | e ass
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            140.1.14.4      YES NVRAM  up                    up
Serial0/0                  140.1.245.4     YES NVRAM  up                    up
Serial0/1                  140.1.45.4      YES NVRAM  up                    up
Loopback0                  150.1.4.4       YES NVRAM  up                    up

r4#sh run | sec router rip
router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface Serial0/1

 network 140.1.0.0
 no auto-summary

r4#sh ip proto | sec rip
    rip, includes subnets in redistribution
Routing Protocol is “rip”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 18 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: ospf 100, rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    Serial0/1             2     2

  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    140.1.0.0
  Passive Interface(s):
    Serial0/0
    FastEthernet0/1
    Loopback0
    VoIP-Null0

  Routing Information Sources:
    Gateway         Distance      Last Update
    140.1.14.1           120      00:00:14
    Gateway         Distance      Last Update
    140.1.45.5           120      00:00:14
  Distance: (default is 120)  

4.6 RIP

You’ll need to use an offset-list to make the metric (hop count) of 150.1.1.0 on r4 equal 10.  Remember this as it will come back in the redistribution scenario.

4.7 Redistribution

I wish all redistribution were this easy.  You simply need to set the metric-type to type-1 in your route-map and redistribute some connected networks into OSPF.

4.8 Advanced Redistribution

You need to do mutual redistribution between RIP and OSPF on three routers.  As with most of the Volume III labs, you can complete this task with the knowledge that any redistribution issues will most likely be the focus of the next task.

4.9 Advanced Redistribution

“Ensure that reachability to r1’s loopback 0 interface is maintained.”

Before redistribution:

r5(config-route-map)#do sh ip route rip | i 150
     150.1.0.0/24 is subnetted, 10 subnets
      150.1.1.0 [120/11] via 140.1.45.4, 00:00:19, Serial0/1

r4(config-route-map)#do sh ip route rip | i 150.
     150.1.0.0/24 is subnetted, 10 subnets
R       150.1.1.0 [120/10] via 140.1.14.1, 00:00:21, Ethernet0/0

r1’s lo0 interface is advertised to r4 via RIP with a metric of 10 (we changed the metric in task 4.6).  r4 advertises that route to r5 via the point-to-point serial connection.  r5 adds the route to its routing table with a metric of 11. 

After redistribution:

r4#sh ip route rip  <-no RIP routes on r4

r4#

r4#sh ip route 150.1.1.0
Routing entry for 150.1.1.0/24
  Known via “ospf 100“, distance 110, metric 20
  Tag 5120, type extern 2, forward metric 64 
  Redistributing via rip
  Advertised by rip metric 1 route-map OSPF->RIP
  Last update from 140.1.245.5 on Serial0/0, 00:00:18 ago
  Routing Descriptor Blocks:
  * 140.1.245.5, from 150.1.5.5, 00:00:18 ago, via Serial0/0
      Route metric is 20, traffic share count is 1
      Route tag 5120 <-5120 = RIP route redistributed on r5

r5#sh ip route rip | sec 150.1.1.0
     150.1.0.0/24 is subnetted, 10 subnets
R       150.1.1.0 [120/1] via 140.1.45.4, 00:00:04, Serial0/1

r5#sh ip route 150.1.1.0
Routing entry for 150.10.1.0/24
  Known via “rip”, distance 120, metric 1
  Tag 4110 <-5120 = RIP route redistributed on r5
  Redistributing via ospf 100, rip
  Advertised by ospf 100 subnets route-map RIP->OSPF
  Last update from 140.1.45.4 on Serial0/1, 00:00:11 ago
  Routing Descriptor Blocks:
  * 140.1.45.4, from 140.1.45.4, 00:00:11 ago, via Serial0/1
      Route metric is 1, traffic share count is 1
      Route tag 4110

Once we do mutual redistribution on r4 and r5, we end up with a routing loop for the 150.1.1.0/24 network:

sw2#trace 150.1.1.1

Type escape sequence to abort.
Tracing the route to 150.1.1.1

  1 140.1.28.2 9 msec 0 msec 0 msec
  2 140.1.245.525 msec 33 msec 26 msec
  3 140.1.45.450 msec 50 msec 51 msec
  4 140.1.245.541 msec 51 msec 42 msec
  5 140.1.45.4 67 msec 59 msec 59 msec
  6 140.1.245.5 58 msec 59 msec 59 msec
  7 140.1.45.4 84 msec 75 msec 75 msec
  8 140.1.245.5 76 msec 75 msec 76 msec
  9 140.1.45.4 92 msec 92 msec 11 msec
 1 140.1.245.5 84 msec 92 msec 84 msec
 11 140.1.45.4 19 msec 19 msec 19 msec
 12 140.1.245.5 19 msec 11 msec 19 msec
 13 140.1.45.4 118 msec 134 msec 117 msec
 14 140.1.245.5 117 msec 118 msec 117 msec
 15 140.1.45.4 143 msec 134 msec 142 msec
 16 140.1.245.5 135 msec 134 msec 134 msec
 17 140.1.45.4 151 msec 159 msec 151 msec
 18 140.1.245.5 151 msec 151 msec 143 msec
 19 140.1.45.4 176 msec 168 msec 168 msec
 20 140.1.245.5 167 msec 160 msec 168 msec
 21 140.1.45.4 184 msec 185 msec 184 msec
 22 140.1.245.5 176 msec 177 msec 184 msec
 23 140.1.45.4 201 msec 202 msec 201 msec
 24 140.1.245.5 193 msec 193 msec 193 msec
 25 140.1.45.4 218 msec 21 msec 218 msec
 26 140.1.245.5 21 msec 209 msec 21 msec
 27 140.1.45.4 227 msec 234 msec 227 msec
 28 140.1.245.5 226 msec 227 msec 218 msec
 29 140.1.45.4 243 msec 252 msec 243 msec
 30 140.1.245.5 235 msec 243 msec 235 msec

So initially we have:

r4 – R [120/10] from r1 via fa0/0
r5 – R [120/11] from r4 via s0/1

r4 and r5 will each redistribute their RIP routes for 150.1.1.0/24 into OSPF.  That means that r4 and r5 will hear about the 150.1.1.0/24 route from each other via OSPF.  Since OSPF has a lower metric, those routes will be installed:

r4 – R [110/20] from r5 via s0/0
r5 – R [110/20] from r4 via s0/0

This gets even uglier because the RIP route on r4 will is replaced by the OSPF route.  Now the RIP route is no longer advertised to r5 via RIP from r4 nor is it redistributed into OSPF on r4 or r5.  So the route should disappear only to reappear again once the original RIP route is restored to r4’s routing table…which will start the whole process over again.  So we should have a “blinking route”, right?

Not really.  To add to this mindfuck, we need to consider that OSPF is being redistributed into RIP.  I did this with a seed metric of 1.  So the OSPF route to 150.1.1.0/24 advertised to r4 and then redistributed into RIP has a better (lower) metric than 10, so it will be installed instead of the original RIP route with a metric of 10.  Does your head hurt yet?

Here’s how it breaks down:

1) r4 gets RIP route from r1 [120/10] and advertises it to r5 [120/11] via RIP.
2) r4 and r5 redistribute the route into OSPF.  Each installs this route (pointing to each other) in their routing tables based on a lower AD (110 vs 120).
3) These OSPF routes are redistributed into RIP as well [120/1] (note that the metric is better than our original RIP routes) but are not installed on r4 or r5 because the OSPF routes have a lower AD.
4) The original RIP route is removed from r4’s routing table.  This means that neither r4 nor r5 can advertise it into OSPF so the 150.1.1.0/24 route should drop from OSPF.
5) The original RIP route on r4 [120/10] reappears and the whole process begins again…OR due to the slow RIP route removal process, the OSPF route from r5 gets redistributed into RIP on r4 and is installed because of the lower metric (1 vs 10).  Either way, we end up with either a “blinking loop” or a “stable loop.

To stop this we need to make sure that the 150.1.1.0/24 network is not redistributed back into RIP on r5.  This means that we’ll route over the Frame cloud to reach 150.1.1.1 on r5 instead of the serial link, but we won’t get a loop.

I filtered r1 lo0 from getting redistributed into from OSPF back into RIP on r5:

router ospf 100
 redistribute ospf 100 metric 1 route-map OSPF->RIP
!
access-list 69 deny   150.1.1.0
access-list 69 permit any
!
route-map OSPF->RIP permit 10
 match ip address 69
 set tag 5110

sw2#p 150.1.1.1

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

sw2#trace 150.1.1.1

Type escape sequence to abort.
Tracing the route to 150.1.1.1

  1 140.1.28.2 0 msec 0 msec 8 msec
  2 140.1.245.525 msec 25 msec 34 msec
  3 140.1.245.450 msec 50 msec 59 msec
  4 140.1.14.150 msec *  59 msec

Whew!!!

February 20, 2008

Internetwork Expert Volume II: Lab 12 – Section 4

Section 4 – Interior Gateway Routing – 8 Points

“Note: Do not redistribute between IGPs”

Sweet!!!!  Well, at least I thought so at first.  This short IGP section with no redistribution only meant that I was about to get my teeth kicked in on the BGP section.  🙂

4.1  OSPF

“To minimize WAN utilization OSPF traffic should only be sent over the Frame Relay segment during initial adjacency establishment and when changes occur in the OSPF topology.”

Huh?  Does OSPF traffic include hellos?  If it doesn’t, then we’re good by default…except for the 30 minute paranoid update.  😦

If they include hellos, then we need to configure the the point-to-point FR connection as a demand circuit.

ip ospf demand-circuit

“ip ospf demand-circuit” only needs to be configured on one side of the link.

r4(config-if)#int s0/0.54
r4(config-subif)#ip os demand

r4#sh ip os int s0/0.54
Serial0/0.54 is up, line protocol is up
  Internet Address 129.1.54.4/24, Area 0
  Process ID 100, Router ID 150.1.4.4, Network Type POINT_TO_POINT, Cost: 65
  Configured as demand circuit.
  Run as demand circuit.

  DoNotAge LSA allowed.
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:01
  Supports Link-local Signaling (LLS)
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 2
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 150.1.5.5  (Hello suppressed)
  Suppress hello for 1 neighbor(s)

4.2 OSPF

Interesting task:

Configure sw4 to match exactly the output below and nothing more:

sw4#sh ip os data | i Net Link States \(Area 34\)
                Net Link States (Area 34)

Currently I show:

sw4#sh ip os data | i Net Link States \(Area 34\)
                Net Link States (Area 34)
                Summary Net Link States (Area 34)

So I need to get rid of Summary Net Link States (LSA 3).  How to do this?

Stub networks?  No:

OSPF Stubs:

Type Keyword LSAs Default Injected?
stub area x stub 1,2,3,4 Yes
totally stubby area x stub no-summary 1,2,default of 3 Yes
not-so-stubby area x nssa 1,2,3,4,7 NO
not-so-totally-stubby area x nssa no-summary 1,2,default of 3,7 Yes

The answer was easy — change the OSPF network type on po34 from Broadcast to Point-to-Point:

sw4#sh ip os int po34 | i Type
  Process ID 100, Router ID 150.1.10.10, Network Type BROADCAST, Cost: 1

sw4(config)#int po34
sw4(config-if)#ip os net point-to-point

sw3(config-if)#int po34
sw3(config-if)#ip os net point-to-point
sw4
#sh ip os data | i Net Link States \(Area 34\)
                Summary Net Link States (Area 34)

Task 4.2

4.3 EIGRP

This was a pretty basic EIGRP configuration with one exception.  r1, r2, and r4 form a Frame Relay hub-and-spoke network.  r1 and r2 (spokes) are running EIGRP, but EIGRP is not enabled on r4 (hub).  Consequently, r1 and r2 are not peering though the Frame Relay cloud.

r2#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
Lo0                0        0/0         0       0/1            0           0
Se0/0/0           0        0/0         0       0/1            0           0
Se0/1/0            1        0/0         4       0/15          50           0

r2#sh ip ei nei
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   129.1.23.3              Se0/1/0           13 00:09:18    4   200  0  11

Can I disable EIGRP split-horizon on r4 even though it’s not running EIGRP?

r4(config)#int Serial0/0.124
r4(config-subif)#no ip split-horizon eigrp ?
  <1-65535>  Autonomous system number

r4(config-subif)#no ip split-horizon eigrp 200

It takes the command, but that’s not the fix:

r2#clear ip ei neighbors
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   129.1.23.3              Se0/1/0           12 00:00:02    2   200  0  18

Okay….next try a neighbor command:

neighbor (EIGRP)

r2(config)#router ei 200
r2(config-router)#neigh 129.1.124.1 Serial0/0/0

r1(config)#router ei 200
r1(config-router)#neigh 129.1.124.2 s0/0

Sweet, sweet IOS music:

*Mar  1 21:17:56.758: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 129.1.124.2 (Serial0/0) is up: new adjacency

r2#sh ip ei nei
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   129.1.124.1           Se0/0/0          140 00:00:39   14   200  0  18
0   129.1.23.3              Se0/1/0           12 00:03:24    1   200  0  18

Alas, all of this effort was for naught.  I didn’t read the task close enough.  Instead I configured EIGRP based on the IGP diagram.  That diagram shows the spokes’ Frame Relay interfaces in the EIGRP domain, BUT the task does not require that you configure them.  😦

This posting discusses an anomaly in the solution guide (two EIGRP routes on sw1 showing as D EX in the solution guide):

Task 4.3

January 27, 2008

Internetwork Expert Volume III: Lab 4 – Section 4

Interior Gateway Routing – 27 Points

4.1 Bridging

“Disable ip routing on r6”

r6(config)#no ip routing

“Bridge IP between the Frame Relay and Ethernet segments on r6”

That explains why fa0/0 does not have an IP address configured. 🙂

After this task, I can finally ping bb1:

r6#p 54.1.10.254

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

4.2 Bridging

This task confused the crap out of me.  My bridging skills are pretty poor.

“Configure the IP address of 54.1.10.6/24 on r6.”

Ummmm….that’s already configured as the IP address of the Frame connection to bb1.  I guess that we’re going to use the same IP address for fa0/0 as well.

“r6 should have reachability to any address of the 54.1.10.0/24 subnet.”
“Don’t use IRB for this task.”

No IRB.  CRB?  Actually, the IE solution doesn’t use IRB or CRB.  The last two subtasks are basically red herrings.  I will need to review bridging.

r6#sh bridge 1 group

Bridge Group 1 is running the IEEE compatible Spanning Tree protocol

   Port 4 (FastEthernet0/0) of bridge group 1 is forwarding
   Port 11 (Serial0/0.1 Frame Relay) of bridge group 1 is forwarding

r6#sh ip int br | i 54.1.10.6
FastEthernet0/0            54.1.10.6       YES manual up                    up
Serial0/0.1                54.1.10.6       YES manual up                    up

r6#p 54.1.10.254

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

r6#p 54.1.10.100

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

I can’t ping r4 but I can ping bb1.  This poster has the opposite problem:

Task 4.2 can not ping 54.1.10.254

r6#sh cdp neigh
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
                  S – Switch, H – Host, I – IGMP, r – Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
BB1              Ser 0/0.1          147       R T S I     2821      Ser 0/0/0:0.401
sw2              Fas 0/0            174         S I       WS-C3560- Fas 0/6
r6#

sw2#sh run int fa0/6
interface FastEthernet0/6 <-that’s a minimal configuration 🙂
end

How did I miss this?????  Because the port on r6 was initially shut down so I didn’t see it with “show cdp neighbor” on sw2.  Arrgh!!!  I need vlan 46 assigned to this port.

sw2(config)#int fa0/6
sw2(config-if)#swit acc vl 46

r6#p 54.1.10.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 54.1.10.100, timeout is 2 seconds:
!!!!!

I guess that I can take solace in the fact that I was able to find my mistake.  I just barely missed going down a deep rabbit hole chasing bridging options.

4.3 RIPv2

I initially thought that there was an error in the IE lab because although r6 was shown as running RIP on the protocol diagram, there was no mention of r6 in the task.  That’s because r6 is bridging the 54.1.10.0/24 network.  I turned off ip routing in task 4.1 so I wouldn’t be able to configure RIP on r6:

r6(config)#router rip
IP routing not enabled

This means that we should be able to see the routes from bb1(54.1.10.254) on r4:

r4#sh ip route rip | i 54.1.10.254
R    212.18.1.0/24 [120/1] via 54.1.10.254, 00:00:12, FastEthernet0/0
R    212.18.0.0/24 [120/1] via 54.1.10.254, 00:00:12, FastEthernet0/0
R    212.18.3.0/24 [120/1] via 54.1.10.254, 00:00:12, FastEthernet0/0
R    212.18.2.0/24 [120/1] via 54.1.10.254, 00:00:12, FastEthernet0/0

4.4 Network Redundancy

backup interface

Hmmmm….this is the reason for the point-to-point subinterface on r4 back in task 3.2

r4#sh ip int br | i Serial
Serial0/0                  unassigned      YES NVRAM  up                    up
Serial0/0.1                unassigned      YES unset  up                    up
Serial0/1                  152.1.54.4      YES NVRAM  standby mode          down

r4#sh backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial0/0.1         Serial0/1             normal operation

4.5 EIGRP

Basic.

4.6  OSPF

“Use the OSPF network type that was specifically designed to handle issues with routers on the same logical IP subnet not having direct communication with each other.”

Remember that we have a multipoint subinterface on the hub (r3) and point-to-point subinterfaces on the hubs (r1 and r2).  The task calls for the point-to-multipoint OSPF network type.

r3#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.2.2         0   FULL/  –        00:01:49    152.1.123.2     Serial0/0:0.1
150.1.1.1         0   FULL/  –        00:01:54    152.1.123.1     Serial0/0:0.1

r3#sh ip route os
     152.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
O       152.1.123.2/32 [110/65] via 152.1.123.2, 00:00:07, Serial0/0:0.1
O       152.1.123.1/32 [110/65] via 152.1.123.1, 00:00:07, Serial0/0:0.1

4.7 OSPF

Basic

4.8 OSPF

In this task you need to advertise the loopbacks on r1 and r2 into area 0.  But r1 and r2 are not in area 0.  Time for a couple of virtual circuits.

4.9 OSPF Loopback Advertisement

“Advertise the Loopback0 networks of r3 and sw1 into OSPF.”
“These networks should appear in each other routing tables as intra-area routes.”

Since I’m not told which area to advertise the loopbacks into, can’t I just make this simple by advertising both loopbacks into area 37?  Answer: YES!

sw1#sh ip route | i 150.1.3.
O       150.1.3.3/32 [110/2] via 152.1.37.3, 00:00:37, Vlan37

r3#sh ip route | i 150.1.7.
O       150.1.7.7/32 [110/2] via 152.1.37.7, 00:00:00, FastEthernet0/0

4.10 IGP Redistribution

Four points of mutual redistribution.  Ugh.  The first two points are no worry (discontiguous RIP).  The other two are dangerous though.  I’ll work on those in task 4.11

4.11 Redistribution Loop Prevention

“Ensure that EIGRP extenal routes that are redistributed into OSPF on r1 and r2 do not get redistributed back into EIGRP.”
“Use AD to accomplish this.”

Here is a (simplified) view of the the two network redistribution points on r1 and r2:
                         ————(D)r1(O)———–
r4(R<->D)—r5(D)                                     (O)r3—(O<->R)sw1
                         ————(D)r2(O)———–
If we do mutual redistribution between EIGRP and OSPF on r1 and r2 we’re going to have problems with D EX routes (AD of 170) being reflected back into the EIGRP domain.  We’re given the method for preventing this.

I missed an issue on sw1 though:

Task 4.11 Redist Loop Prevention

You need to change the RIP distance or SW1 sees the routes learnt from BB3 as OSPF external routes which it uses over the correct RIP routes. if you check the routing table on SW1, the next hop for all the BB3 subnets is R3. This is resolved by changing the AD [router rip – distance 109].

January 20, 2008

Internetwork Expert Volume II: Lab 3 – Section 4

Interior Gateway Routing – 21 Points

4.1 OSPF

“Ensure that r2 (spoke) uses r5(hub) as the next hop to reach r4(spoke), and vice versa.”

OSPF Commands

This is a tailor-made case for the OSPF network type point-to-multipoint. 

I did have a strange error pop up during this configuration:

r5(config-router)#int s0/0.245
r5(config-subif)#ip os net point-to-mu
OSPF: Cost or database-filter option is required for point-to-multipoint broadcast network
OSPF: Neighbor 136.1.245.2 command options invalid – neighbor not configured
OSPF: Cost or database-filter option is required for point-to-multipoint broadcast network
OSPF: Neighbor 136.1.245.4 command options invalid – neighbor not configured
*Mar  1 01:23:14.170: %OSPF-5-ADJCHG: Process 100, Nbr 0.0.0.0 on Serial0/0.245 from ATTEMPT to DOWN, Neighbor Down: Interface down or detached
*Mar  1 01:23:14.170: %OSPF-5-ADJCHG: Process 100, Nbr 0.0.0.0 on Serial0/0.245 from ATTEMPT to DOWN, Neighbor Down: Interface down or detached
*Mar  1 01:23:14.238: %OSPF-5-ADJCHG: Process 100, Nbr 150.1.2.2 on Serial0/0.245 from LOADING to FULL, Loading Done

r5(config-subif)#do sh run int s0/0.245
interface Serial0/0.245 multipoint
 description ->r2, r4 FR HnS
 ip address 136.1.245.5 255.255.255.0
 ip ospf network point-to-multipoint
 frame-relay map ip 136.1.245.2 502 broadcast
 frame-relay map ip 136.1.245.4 504 broadcast
end

There is an excellent breakdown on the point-to-multipoint network type in the IE solution guide.

4.2 OSPF

Read the task carefully:

“Do not use the ip ospf network type ON R5 to accomplish this.”

This doesn’t say anything about r1.

r5#sh ip os int Serial0/0.15 | i Type
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 64

Let’s change r1’s OSPF network type to point-to-point as well:

r1(config)#int s0/0
r1(config-if)#ip os net point-to-point

r1#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.5.5         0   FULL/  –        00:00:38    136.1.15.5      Serial0/0

r1#sh ip route os
     136.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
O       136.1.245.4/32 [110/129] via 136.1.15.5, 00:00:04, Serial0/0
O       136.1.245.5/32 [110/65] via 136.1.15.5, 00:00:04, Serial0/0
O       136.1.245.2/32 [110/129] via 136.1.15.5, 00:00:04, Serial0/0
O IA    136.1.4.0/24 [110/130] via 136.1.15.5, 00:00:04, Serial0/0
O IA    136.1.44.0/24 [110/130] via 136.1.15.5, 00:00:04, Serial0/0

4.3  OSPF

Easy task.  Advertise loopbacks into OSPF with /24 mask.  Just change the OSPF network type from LOOPBACK to POINT-TO-POINT on the loopback 0 interfaces.

4.4 OSPF

Configure the PTP connection from r4 to r5 in area 45 and use it only as a backup link when the Frame Relay link drops.

“Do not user the ‘backup interface’ command to accomplish this.”

I was stumped on this one initially.  I shut the Frame interface on r4 and the OSPF routes changed to the PTP link.  What I initially overlooked was that when that r4 Frame link drops, areas 4 and 44(on r4) will not have a connection to area 0.  I’ll need a virtual-link.

“Virtual-links can be used to repair broken connections to area 0, connect discontiguous area to area 0, and connect discontiguous area0s.”

The method to “trigger” the PTP connection: just give it a higher metric than the Frame Relay link.  When the Frame link drops, then traffic will route over the PTP.

ip ospf cost

area virtual-link

4.5 OSPF

“You are concerned about false routing information being injected into OSPF area 0.  In order to verify the legitimacy of routing information, configure all area 0 adjacencies to be authenticated with a secure hash value of the password CISCO.”

area authentication

Good to know:

Note:To remove the specified area from the software configuration, use the no area area-id command (with no other keywords). That is, the no area area-id command removes all area options, such as area authentication, area default-cost, area nssa, area range, area stub, and area virtual-link.

r1(config-router)#area 0 authentication ?
  message-digest  Use message-digest authentication
r1(config-router)#area 0 authentication message-digest ?
  <cr>

r1(config)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          100   0               150.1.1.1/24       1     P2P   0/0
Se0/0        100   0               136.1.15.1/24      65    P2P   1/1

r1(config)#int s0/0
r1(config-if)#ip os authentication-key CISCO

I did miss the “Pitfall”:

“A virtual-link is an area 0 adjacency.  If authentication is required for all OSPF area adjacencies, then it must also be configured on all virtual-links.”

I also used “ip os authentication-key CISCO” under the interfaces instead of ‘ip ospf message-digest-key md5 CISCO’.

ip ospf message-digest-key md5

4.6 OSPF

Change OSPF metrics to accommodate 10Gbps connections.

auto-cost

The OSPF metric is calculated as the ref-bw value divided by the bandwidth, with mbps equal to 108 by default, and bandwidth determined by the bandwidth (interface) command. The calculation gives FDDI a metric of 1.

If you have multiple links with high bandwidth (such as FDDI or ATM), you might want to use a larger number to differentiate the cost on those links.

The value set by the ip ospf cost command overrides the cost resulting from the auto-cost command. <-nice to know as per task 4.4

So, a bit of math:

10^8 = 100,000,000

I need to make the OSPF cost for 10Gbps (10,000,000,000) = 2

So:

x/10,000,000,000 = 2
x = 2 * 10,000,000,000
x = 20,000,000,000

r5(config-router)#auto-cost reference-bandwidth ?
  <1-4294967>  The reference bandwidth in terms of Mbits per second

Divide my answer by 1,000,000 (Mbit) = 20,000

r5(config-router)#auto-cost reference-bandwidth 20000
% OSPF: Reference bandwidth is changed.
        Please ensure reference bandwidth is consistent across all routers.

I don’t have a 10Gbps interface on my router…yet 🙂  But the task does show that a T1 should have a cost of 12953.  That I can check:

r5(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Vl1          100   0               136.1.45.5/24      65534 P2P   1/1
Lo0          100   0               150.1.5.5/24       1     P2P   0/0
Se0/0.15     100   0               136.1.15.5/24      12953 P2P   1/1 
Se0/0.245    100   0               136.1.245.5/24     12953 P2MP  2/2
Se0/1        100   45              136.1.45.5/24      65534 P2P   1/1

You can see that s0/1’s hard set cost (65534) is not affected.

You need to apply this command to ALL routers running OSPF in your network.

One interesting bit:

r1:
r1#sh int s0/0 | i BW
  MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
r1#sh ip os int s0/0 | i Cost
  Process ID 100, Router ID 150.1.1.1, Network Type POINT_TO_POINT, Cost: 13020

r5:
r5#sh int s0/0.15 | i BW
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
r5#sh ip os int s0/0.15 | i Cost
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 12953

This is another “Ask the proctor” issue.  You can easily change this:

r1(config)#int s0/0
r1(config-if)#bandwidth 1544
r1(config-if)#do sh int s0/0 | i BW
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
r1(config-if)#do sh ip os int s0/0 | i Cost
  Process ID 100, Router ID 150.1.1.1, Network Type POINT_TO_POINT, Cost: 12953

4.7  EIGRP

“Do not send EIGRP hello packets out any other interfaces.”
“Do not use the ‘passive interface’ command under the EIGRP process”

“under the EIGRP process”…is there a way to do this under the interface itself?

EIGRP Commands

I couldn’t find anything like that.  What about the neighbor command?

That won’t work either.

I completely overthought this one.  😦

Just add a network mask to your EIGRP network statement:

router eigrp 100
 net 150.1.6.6 0.0.0.0

Why can’t I see r6’s loopback (150.1.6.6) on r2 or r3 or r1?

Did I forget a “no auto” statement? No. 
Something to do with router on a stick? No.
Ummmm….I forgot to advertise VLAN 16 and VLAN 36 on r6. (I caught this before consulting the solutions guide)

Nicely played.  I am learning to verify routes as I go.  🙂

4.8  RIPv2

“…use the strongest authentication on any RIP updates…”
“Do not enable RIP on any other interfaces.”

Configuring Routing Information Protocol

Enabling RIP Authentication

ip rip authentication mode
ip rip authentication mode {text | md5}

Usage Guidelines
RIP Version 1 does not support authentication. <- we use RIPv2 in the lab

passive-interface
passive-interface
 Disables sending routing updates on an interface. 

IE solution shows r5 and sw1 with “passive-interface default”, but not r6???  Why?

Answer: r6 has no overlapping classful interfaces:

r6#sh ip int br | e ass
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/0                  54.1.3.6        YES NVRAM  up                    up
FastEthernet0/1            204.12.1.6      YES NVRAM  up                    up
BVI1                       136.1.136.6     YES manual up                    up
Loopback0                  150.1.6.6       YES NVRAM  up                    up

r5 and sw1 do:

r5#sh ip int br | e ass
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.10.1.5      YES NVRAM  up                    up
Serial0/0.15               136.1.15.5      YES NVRAM  up                    up
Serial0/0.245              136.1.245.5     YES NVRAM  up                    up
FastEthernet0/1            136.1.57.5      YES NVRAM  up                    up
Serial0/1                  136.1.45.5      YES NVRAM  up                    up
Loopback0                  150.1.5.5       YES NVRAM  up                    up

sw1:
sw1#sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan7                  136.1.7.7       YES NVRAM  down                  down
Vlan57                 136.1.57.7      YES NVRAM  up                    up
Loopback0              150.1.7.7       YES NVRAM  up                    up

Why is vlan7 down?

sw1#sh run int vlan7
interface Vlan7
 ip address 136.1.7.7 255.255.255.0
end

sw1#sh vlan id 7
VLAN id 7 not found in current VLAN database

That’s the reason.  🙂

Initial Configuration for switching …. IE Lab 3

I’ll go ahead and add vlan 7:

23:39:05: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan7, changed state to up

VLAN7 is not included in IE’s solution either.  They configured “no passive-interface vlan57”, but make no mention of vlan7.  Even though the task requires:

“Enable RIP on VLAN7…”

Task 4.8 – passive interface VLAN7 on SW1 

4.9  IGP Redistribution

ICK!!!

“Redistribute where necessary to obtain full IP reachabiltity to all advertised networks.”
“r5 should route through r1 to get to the prefixes learned from bb1”
“r5 should route through r2 to get to the prefixes learned from bb3”

Looking at my diagram, I have 4 possible point of redistribution:

r1 – OSPF 100 (110)  |  EIGRP 100 (90)
r2 – OSPF 100 (110)  |  EIGRP 100 (90)
r5 – OSPF 100 (110)  |  RIP (120)
r6 – EIGRP 100 (90)  |  RIP (120)

My AD matra: “Lower to higher is good.  Higher to lower is bad.”

Tasks 2 and 3 mean that I need to redistribute RIP into EIGRP on r6 and then redistribute EIGRP into OSPF on r1 and r2.  I’ll set up route maps to filter what routes are redistributed at those points.

I’m really proud of myself.  I finished this task by myself.  I met the requirements for each task, but I used a slightly different method than IE.

Differences:
1) I did not redistribute OSPF into EIGRP on both r1 and r2.  Only on r1.  There was no requirement to do it on both routers and it cut the chance of loops down.
2) I tagged the routes on r6 based on the incoming interface (fa0/1 for BB3 and s0/0 for BB1).  I redistributed all of the routes except the routes tagged from BB1 through r1 into OSPF.  I redistributed the BB1 routes into OSPF through r2 (thinking about this now, I could have probably gotten by just tagging the BB1 routes).

This task took me FOREVER, but I did complete it successfully.

I will say that the IE solution manual is VERY light on explaining their route redistribution answer.

January 17, 2008

Internetwork Expert Volume III: Lab 2 – Section 4

Interior Gateway Routing – 27 Points

4.1 RIPv2

The IE solution confused me at first.  Why did they configure “neighbor (RIP)” statements on both routers?  The answer came when I noticed that they had not configured “no passive-interface” for the serial links.  A subtask read:

“Use the passive-interface default” command on both r1 and r2.”

I didn’t read that to mean that you could not use “no passive-interface” on any interfaces. 

Here’s why you need to the neighbor command:

Without neighbor:

r1(config-router)#do sh run | sec router rip
router rip
 version 2
 redistribute connected metric 1 route-map CONN->RIP
 passive-interface default
 network 161.1.0.0
 no auto-summary

r2(config-router)#do sh run | sec router rip
router rip
 version 2
 redistribute connected metric 1 route-map CONN->RIP
 passive-interface default
 network 161.1.0.0
 no auto-summary

r1(config-router)#do sh ip route rip

r1(config-router)#

All of the interfaces are passive.  In RIP, a passive-interface means that you cannot send any routing updates on that interface.  In this case, we’re not sending any RIP routing updates because all of the interfaces are passive.  The easy way (the way I did it) is to simply take the interfaces between r1 and r2 out of passive.  If this is prohibited, then use the RIP neighbor statement.

neighbor (RIP)

With neighbor:

r1#sh run | sec router rip
router rip
 version 2
 redistribute connected metric 1 route-map CONN->RIP
 passive-interface default
 network 161.1.0.0
 neighbor 161.1.12.1
 no auto-summary

r2#sh run | sec router rip
router rip
 version 2
 redistribute connected metric 1 route-map CONN->RIP
 passive-interface default
 network 161.1.0.0
 neighbor 161.1.12.1
 no auto-summary

r1#sh ip route rip
     161.1.0.0/24 is subnetted, 3 subnets
R       161.1.23.0 [120/1] via 161.1.12.2, 00:00:02, Serial0/0/0
     150.1.0.0/24 is subnetted, 2 subnets
R       150.1.2.0 [120/1] via 161.1.12.2, 00:00:02, Serial0/0/0

4.2 OSPF

Simple redistribution of loopbacks using route-maps.

4.3 OSPF

“Do not change the default OSPF network type of non-broadcast.”

r3#sh ip os int s0/0/0 | i Type|Hello
  Process ID 100, Router ID 150.1.3.3, Network Type NON_BROADCAST, Cost: 64
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    Hello due in 00:00:26

r4#sh ip os int Serial0/0/0.403 |  i Type|Hello
  Process ID 100, Router ID 150.1.4.4, Network Type POINT_TO_POINT, Cost: 64
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:09

This is another “interpretation” question.  The task says nothing about changing the default OPSF type of Point-To-Point on r4.  🙂  Make sure that you configure a neighbor statement on r4 as well so your updates are unicast.

Don’t go down the rabbit hole of changing the OSPF hello intervals.  You’ll get an adjacency but no LSAs (because non-broadcast needs a DR and ptp does not).

r4(config)#router os 100
r4(config-router)#net 150.1.4.4 0.0.0.0 ar ea 0  <- to check routes on r3

r3(config)#int s0/0/0
r3(config-if)#ip os hello 10
r3(config-if)#^Z

r3#sh ip os neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.4.4         1   FULL/BDR        00:00:39    161.1.34.4      Serial0/0/0

r3#sh ip route os

r3#

4.4 OSPF

Easy task.  I ran into an MTU issue.  Good practice for the lab: 

r5#sh ip os neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.4.4         0   FULL/  –        00:00:36    161.1.45.4      Serial0/0/0
150.1.8.8         1   DOWN/DROTHER       –        161.1.5.9       FastEthernet0/0

*Jan 16 20:55:12.254: %OSPF-5-ADJCHG: Process 100, Nbr 150.1.8.8 on FastEthernet0/0 from DOWN to DOWN, Neighbor Down: Ignore timer expired

r5#sh int fa0/0 | i MTU
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

sw2#sh system mtu
System MTU size is 1500 bytes
System Jumbo MTU size is 1504 bytes
Routing MTU size is 1500 bytes

r5(config-router)#int fa0/0
r5(config-if)#ip ospf ?

  mtu-ignore           Ignores the MTU in DBD packets

r5(config-if)#ip ospf mtu-ignore

r5#sh ip os neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.4.4         0   FULL/  –        00:00:32    161.1.45.4      Serial0/0/0
150.1.8.8         1   FULL/DR         00:00:35    161.1.5.9       FastEthernet0/0

4.5 OSPF

Advertise in loopbacks but do not associate with an area.   Use redistribution of connected interfaces with a route-map. 

Speed Tip: You can use the same commands on each device- just cut and paste (I did change the tag on each device though):

route-map CONN->OSPF permit 10
 description Task 4.5
 match interface Loopback0
 set tag 31
!
router ospf 100
redistribute connected subnets route-map CONN->OSPF

4.6 OSPF

Easy task with summaries.  Task gives you the actual summaries to advertise, so no binary!!  🙂

You will need when and why to use area range versus summary-address.

area range

summary-address (OSPF)

4.7 OSPF Redistribution

Advertise vlan 43 on r4.  Do not use network statement.

We’re already redistributing connected, so let’s just add int fa0/0 to that existing route-map:

r4(config-router)#do sh run | sec route-map CONN->OSPF
route-map CONN->OSPF permit 10
 description Task 4.5
 match interface Loopback0
 set tag 41
r4(config-router)#route-map CONN->OSPF permit 10
r4(config-route-map)#match int fa0/0
r4(config-route-map)#do sh run | sec route-map CONN->OSPF
route-map CONN->OSPF permit 10
 description Task 4.5
 match interface Loopback0 FastEthernet0/0
 set tag 41

4.8 EIGRP

Very basic EIGRP configuration. 

4.9 EIGRP Redistribution

You’re asked to redistribute in some loopbacks.  This task will affect your IGP redistribution.

Speed Tip: Reuse commands to save time (I do alter the tags on each device):

redist conn route-map CONN->EIGRP met 1 1 1 1 1
route-map CONN->EIGRP permit 10
 description task 4.9
 match interface Loopback0
 set tag 61

4.10 IGP Redistribution

The BEAST!!!!  Actually in this lab they tell you what to do, so redistribution is not that difficult.

“Perform mutual redistribution between RIP and OSPF on r2”
“Perform mutual redistribution between OSPF and EIGRP on r4 and r5”

r2
RIP 120 -> OSPF 110
OSPF 110 -> RIP 120

I don’t see any issues on this redistribution because it’s isolated.  We don’t have any RIP routes in the routing table:

r2#sh ip route rip

r2#

The only thing we need to note is that we are already redisting lo0 into RIP:

r2#sh run | sec router rip
router rip
 version 2
 redistribute connected metric 1 route-map CONN->RIP
 passive-interface default
 network 161.1.0.0
 neighbor 161.1.12.1
 no auto-summary

route-map CONN->RIP permit 10
 description Task 4.2 lo0 to rip Tag 21
 match interface Loopback0
 set tag 11

r4 and r5

Our worry here are EIGRP routes redist on one router and then redist back into EIGRP on the other router.

r6’s loopback for instance

r5 learns it via EIGRP (90) from sw2
r5 redistributes it into OSPF (110)
r4 learns it from OSPF (110) and from EIGRP (90)

No problems….right?

Actually….we redistributed that interface into EIGRP in the last task so:

r5(config)#do sh ip route 150.1.6.6
Routing entry for 150.1.6.0/24
  Known via “eigrp 10”, distance 170, metric 2560007936
  Tag 61, type external
  Redistributing via eigrp 10
  Last update from 161.1.58.8 on FastEthernet0/1, 01:23:20 ago
  Routing Descriptor Blocks:
  * 161.1.58.8, from 161.1.58.8, 01:23:20 ago, via FastEthernet0/1
      Route metric is 2560007936, traffic share count is 1
      Total delay is 310 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 3
      Route tag 61

r5 learns it via EIGRP (170) from sw2
r5 redists it into OSPF (110)
r4 learns it from OSPF (110) and from EIGRP (170)

r4 is going to send traffic for 150.1.6.6 to r5 via frame (ospf)
r5 will send traffic for 150.1.6.6 to r4

Crap!  We need to make sure that the OSPF AD for those routes is greater than 170.  Which is precisely what we’ll do in the next task.

4.11 Redistribution Loop Prevention

This task was a bit of a bummer because it points out exactly what the problems with mutual redistribution are and how to fix them.

distance

January 1, 2008

Internetwork Expert Volume III: Lab 3 – Section 4 Part 2

4 Interior Gateway Routing

4.13 IGP Redistribution

The dreaded IGP redistribution task.  In this lab task 4.13 explicitly tells you where and how to perform redistribution.  Task 4.14 then asks you to prevent loops:

“Do not allow the RIP routes redistributed into OSPF on r4 to be passed back into RIP on r5.”
“Use route tagging to accomplish this.”

I have the following points of redistribution:

r3: RIP 120      -> OSPF 110
    OSPF 110     -> RIP 120

r4: RIP 120      -> OSPF 110

r5: RIP 120      -> EIGRP 90
    OSPF 110     -> RIP 120
    OSPF 110     -> EIGRP 90
    EIGRP 90/170 -> OSPF 110

r5 looks ugly.  I’ll do that one last.

r3 has mutual redistribution, but this should not be a problem because it’s on the same router.  There are no routes currently being redistributed on these routers so I shouldn’t break anything.  When I redistribute RIP into OSPF, this will introduce the BB2 routes into OSPF.  I am also using IE’s recommended tagging structure (router + protocol AD):

r3(config)#router os 100
r3(config-router)#redist rip sub tag 3120

I can see the BB2 routes on r1 now:

r1#sh ip ospf data external adv-router 150.1.3.3 | i Link State|Mask|Tag
                Type-5 AS External Link States
  Link State ID: 190.1.3.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 192.10.1.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 205.90.31.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 220.20.3.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 222.22.2.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120

I can safely redistribute the OSPF routes into RIP on r3.  The only concern is the BB2 routes reflecting back into RIP with a better AD (110 versus 120).  But the router will not install these routes.  [Basically because the RIP route would be replaced by OSPF route which would mean that the RIP route would not have been redistributed in the first place – “The Single Router Redistribution Paradox”  🙂 ]

Before redistribution:
r3#sh ip route | i 220.20.3.0
R    220.20.3.0/24 [120/7] via 192.10.1.254, 00:00:14, FastEthernet0/0 <-bb2 route

r3(config)#route-map OSPF->RIP_SET_TAG permit 10
r3(config-route-map)#set tag 3110
r3(config-router)#redist ospf 100 route-map OSPF->RIP_SET_TAG metric 2

After redistribution, the route is unchanged (as I expected):
r3#sh ip route | i 220.20.3.0
R    220.20.3.0/24 [120/7] via 192.10.1.254, 00:00:14, FastEthernet0/0

On to r4.  We have to redistribute RIP (120) into OSPF (110).  This should not be an issue as it is one-way redistribution (it may become an issue later when we redistribute OSPF into RIP on r5).  This will put the bb3 routes into OSPF.  BUT we do have a possible issue because we are currently redistributing Loop0 into OSPF via connected with a route-map:

route-map LOOP0->OSPF permit 10
 match interface Loopback0
!
router ospf 100
 router-id 150.1.4.4
 log-adjacency-changes
 redistribute connected subnets tag 41 route-map LOOP0->OSPF
 network 190.1.34.4 0.0.0.0 area 34

So we know that redistribution uses a two step algorithm:

1) Take all of the RIP routes in the routing table and advertise them in OSPF.
2) Take all connected interfaces running RIP and advertise them into OSPF (implicit route-map)

In this case we will break the second step with our LOOP0->OSPF map.  We need to include the interfaces running RIP in that route-map.

  Default version control: send version 2, receive version 2
    Interface                    Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    FastEthernet0/1       2     2
    Serial0/1                      2     2

So I need to add interfaces fa0/0, fa0/1, and s0/1 to my route-map.

The IE answer key is a little puzzling at first glance.  They show the following for r4:

router ospf 1
 redistribute rip subnets
!
route-map CONNECTED->OSPF permit 20
!
router rip
 redistribute ospf 1 metric 1  <-WTF???

The route-map CONNECTED->OSPF is what they used for task 4.7 (to get Lo0 into OSPF) so basically they are now adding a “permit all” line at the end of that route-map, so that we are redistributing ALL connected interfaces into OSPF.  Here is what they are effectively doing:

route-map CONNECTED->OSPF permit 10
 match interface loopback0
route-map CONNECTED->OSPF permit 20
!
router ospf 1
 redistribute rip subnets
 redistribute connected subnets route-map CONNECTED->OSPF

That makes sense.  I don’t know why they are redistributing the OSPF routes into RIP though?  The task requires one-way redistribution only.  Here’s my solution (I removed the old route-map and “redistribute connected” configurations):

route-map CONNECTED->OSPF permit 10
 description TASK 4.8 Lo0 into OSPF
 match interface Loopback0
 set tag 41
route-map CONNECTED->OSPF permit 20
 description TASK 4.13 RIP->OSPF redist connected
 match interface FastEthernet0/0 FastEthernet0/1 Serial0/1
 set tag 4120
!
router ospf 100
 router-id 150.1.4.4
 log-adjacency-changes
 redistribute connected subnets route-map CONNECTED->OSPF
 redistribute rip subnets tag 4120
 network 190.1.34.4 0.0.0.0 area 34

Here are the redistributed RIP routes on r1:

r1#sh ip os data | i Tag|4120
Link ID         ADV Router      Age         Seq#       Checksum Tag
10.4.4.0        150.1.4.4       653         0x80000001 0x004482 4120
10.5.5.5        150.1.4.4       653         0x80000001 0x00FAC4 4120
30.0.0.0        150.1.4.4       112         0x80000001 0x009B1F 4120
30.1.0.0        150.1.4.4       112         0x80000001 0x008F2A 4120
30.2.0.0        150.1.4.4       112         0x80000001 0x008335 4120
30.3.0.0        150.1.4.4       112         0x80000001 0x007740 4120
31.0.0.0        150.1.4.4       112         0x80000001 0x008E2B 4120
31.1.0.0        150.1.4.4       112         0x80000001 0x008236 4120
31.2.0.0        150.1.4.4       112         0x80000001 0x007641 4120
31.3.0.0        150.1.4.4       112         0x80000001 0x006A4C 4120
190.1.4.0       150.1.4.4       653         0x80000001 0x003BD9 4120
204.12.1.0      150.1.4.4       653         0x80000002 0x001FDE 4120

This accomplishes the same thing, but with the benefit of unique tags on the routes.

Okay…no more putting it off…on to r5:

r5: RIP 120      -> EIGRP 90
    OSPF 110     -> RIP 120
    OSPF 110     -> EIGRP 90
    EIGRP 90/170 -> OSPF 110

So…mutual redistribution between OSPF and EIGRP as well as one-way redistribution between OSPF and RIP as well as RIP and EIGRP.  Did I already say “yuck”? 🙂

“lower to higher = good”  so OSPF into RIP should be fine.  Let’s start with that one.

Current RIP configuration:
router rip
 version 2
 no validate-update-source
 passive-interface default
 no passive-interface Serial0/1
 network 10.0.0.0
 network 150.1.0.0
 no auto-summary

Before we do this, we need to look at what’s happening with the BB3 routes.  They are being advertised from BB3 to r4 via RIP.  R4 then advertises them to r5 via RIP.

We have redistributed the RIP routes into OSPF on r4 so now they routes flow from BB3 to r4 via RIP.  They then get redistributed into OSPF.  r5 sees the routes from r4 via RIP and from r3 via OSPF.  Since OSPF has the lower AD, the OSPF routes are installed:

Before redistribution on r4:

r5#sh ip route 30.0.0.0
Routing entry for 30.0.0.0/16, 4 known subnets
  Redistributing via rip, ospf 100

R       30.2.0.0 [120/15] via 10.4.4.4, 00:00:00
R       30.3.0.0 [120/15] via 10.4.4.4, 00:00:00
R       30.0.0.0 [120/15] via 10.4.4.4, 00:00:00
R       30.1.0.0 [120/15] via 10.4.4.4, 00:00:00

After redistributing RIP->OSPF on r4:

r5#sh ip route 30.0.0.0
Routing entry for 30.0.0.0/16, 4 known subnets
  Redistributing via rip, ospf 100

O E2    30.2.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1
O E2    30.3.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1
O E2    30.0.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1
O E2    30.1.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1

So if we redistribute OSPF into RIP on r5 are we introducing a routing loop for the bb3 routes?  I don’t think so.  We’re really not doing much at all.  r4 and r5 both know all of the OSPF routes because they are running OSPF already.  Even the RIP routes learned from bb2 via r3 are already known by r5 and r3 via OSPF (RIP was redistributed into OSPF on r3 already).  I can’t see any problems with this redistribution.

route-map OSPF->RIP permit 10
 description Tag OSPF routes with 5110
 set tag 5110
!
router rip
 version 2
 no validate-update-source
 redistribute ospf 100 metric 2 route-map OSPF->RIP
 passive-interface default
 no passive-interface Serial0/1
 network 10.0.0.0
 network 150.1.0.0
 no auto-summary

Alright.  Let’s do the other one-way redistribution on r5: RIP 120 into EIGRP 90.

At first this looks like an issue because we’re going from a higher AD protocol (RIP 120) to a lower AD protocol (EIGRP 90), but we need to remember that EIGRP will give external routes an AD of 170 so we don’t need to worry about these routes coming back into RIP.

One other thing…there are no RIP routes in the r5 routing table  🙂

r5#sh ip route rip

r5#

So the only thing that we will be redistributing into EIGRP are the interfaces running RIP (only int s0/1):

Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    Serial0/1             2     2

route-map RIP->EIGRP permit 10
 description Tag RIP routes with 5120
 set tag 5120
!
router eigrp 10
 redistribute rip metric 1 1 1 1 1 route-map RIP->EIGRP

Before redistribution:

r2#sh ip route ei | sec D EX
r2#

After redistribution:

r2#sh ip route ei | sec D EX
D EX    10.5.5.0/24
           [170/2560002816] via 190.1.0.5, 00:04:24, GigabitEthernet0/0
D EX    10.4.4.4/32
           [170/2560002816] via 190.1.0.5, 00:04:24, GigabitEthernet0/0
     150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
D EX    150.1.5.0/24
           [170/2560002816] via 190.1.0.5, 00:04:24, GigabitEthernet0/0

We can’t ping 10.4.4.4 though:

r2#p 10.4.4.4

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

That’s because there is no path back on r4:

r4#sh ip route 190.1.0.2
% Subnet not in table

Finally…the mutual redistribution on r5:

    OSPF 110     -> EIGRP 90
    EIGRP 90/170 -> OSPF 110

We should be covered here too because the OSPF routes redistributed into EIGRP will appear as D EX routes with an AD of 170.

I would filter any D EX routes from being redistributed back into OSPF

Before mutual redistribution:

r1#sh ip route | i E2
       E1 – OSPF external type 1, E2 – OSPF external type 2
O E2 222.22.2.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 204.12.1.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 220.20.3.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    190.1.4.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    190.1.3.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    10.4.4.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    10.5.5.5/32 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 192.10.1.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.3.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.2.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.1.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.0.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    150.1.5.0 [110/20] via 190.1.135.5, 00:56:24, Serial0/0.1
O E2    150.1.4.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 205.90.31.0/24 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.2.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.3.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.0.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.1.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1

r2#sh ip route | sec D EX
D EX    10.5.5.0/24
           [170/2560002816] via 190.1.0.5, 00:18:48, GigabitEthernet0/0
D EX    10.4.4.4/32
           [170/2560002816] via 190.1.0.5, 00:18:48, GigabitEthernet0/0
     150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
D EX    150.1.5.0/24
           [170/2560002816] via 190.1.0.5, 00:18:48, GigabitEthernet0/0

We don’t have any D EX routes on r5:

r5#sh ip route ei | i D EX
r5#

We’re not redistributing connected under either protocol, so we should be good to go:

router eigrp 10
 redistribute rip metric 1 1 1 1 1 route-map RIP->EIGRP
 network 190.1.0.5 0.0.0.0
 network 190.1.5.5 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.5.5
!
router ospf 100
 router-id 150.1.5.5
 log-adjacency-changes
 redistribute rip subnets tag 5120 route-map LOOP0->RIP-OSPF
 network 190.1.135.5 0.0.0.0 area 135
 neighbor 190.1.135.3
 neighbor 190.1.135.1

r1#sh ip os data | i Tag|590|5170
Link ID         ADV Router      Age         Seq#       Checksum Tag
54.1.1.0        150.1.5.5       42          0x80000001 0x001F57 590
150.1.2.0       150.1.5.5       42          0x80000001 0x002AEB 590
150.1.6.0       150.1.5.5       42          0x80000001 0x00FD14 590
150.1.8.0       150.1.5.5       42          0x80000001 0x00E728 590
190.1.0.0       150.1.5.5       42          0x80000001 0x003BB3 590
190.1.5.0       150.1.5.5       42          0x80000001 0x0004E5 590
200.0.0.0       150.1.5.5       42          0x80000001 0x00C421 590
200.0.1.0       150.1.5.5       42          0x80000001 0x00B92B 590
200.0.2.0       150.1.5.5       42          0x80000001 0x00AE35 590
200.0.3.0       150.1.5.5       42          0x80000001 0x00A33F 590

Sweet.  I’m seeing EIGRP routes, but no D EX routes redistributed into OSPF.

Now the final step.  OSPF into EIGRP.  We should be fine because the OSPF routes will become D EX routes and not reflect back into OSPF.

So now we have a ton of D EX routes on r2:

r2#sh ip route | i D EX
D EX 222.22.2.0/24
D EX 204.12.1.0/24
D EX 220.20.3.0/24
D EX    190.1.135.0
D EX    190.1.34.0
D EX    190.1.17.0
D EX    190.1.4.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    190.1.3.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    10.5.5.0/24
D EX    10.4.4.0/24
D EX    10.4.4.4/32
D EX 192.10.1.0/24
D EX    31.3.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    31.2.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    31.1.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    31.0.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    150.1.7.0/24
D EX    150.1.5.0/24
D EX    150.1.4.0/24
D EX    150.1.3.0/24
D EX    150.1.1.0/24
D EX 205.90.31.0/24
D EX    30.2.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    30.3.0.0 [170/2560002816] via 190.1.0.5, 00:00:20, GigabitEthernet0/0
D EX    30.0.0.0 [170/2560002816] via 190.1.0.5, 00:00:20, GigabitEthernet0/0
D EX    30.1.0.0 [170/2560002816] via 190.1.0.5, 00:00:20, GigabitEthernet0/0

But still none on R5:

r5#sh ip route | i D EX
r5#

We can ping 10.4.4.4 from the EIGRP domain now:

r2#p 10.4.4.4

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

We can make one more sanity check.  Let’s create a new loopback on r2 and redistribute it into EIGRP.  This will create an external route that should show up in the OSPF domain.  We can then verify that our 5170 tags are working.

r2(config)#int lo1
r2(config-if)#ip add 2.2.2.2 255.255.255.0
r2(config-if)#route-map LOOP1->EIGRP perm 10
r2(config-route-map)#match int lo1
r2(config-route-map)#router eig 10
r2(config-router)#redist conn route-map LOOP1->EIGRP met 1 1 1 1 1

It shows up on r5:

r5#sh ip route | i D EX
D EX    2.2.2.0 [170/2560002816] via 190.1.0.2, 00:00:15, FastEthernet0/0

It should now appear on r1 as an E2 OSPF route with a tag of 5170:

r1#sh ip route 2.2.2.0
Routing entry for 2.2.2.0/24
  Known via “ospf 100”, distance 110, metric 20
  Tag 5170, type extern 2, forward metric 65
  Last update from 190.1.135.5 on Serial0/0.1, 00:01:46 ago
  Routing Descriptor Blocks:
  * 190.1.135.5, from 150.1.5.5, 00:01:46 ago, via Serial0/0.1
      Route metric is 20, traffic share count is 1
      Route tag 5170

Sweet!!!  My tagging system works.  Let’s remove that configuration and then work on task 4.14

4.14 Redistribution Loop Prevention

“Do not allow the RIP routes redistributed into OSPF on r4 to be passed back into RIP on r5.”
“Use route tagging to accomplish this.”

The RIP routes redistributed into OSPF on r4 should be tagged with 4120 (and lo0 will be tagged 41).  Let’s see if they show up on r5:

r5#sh ip os data | i Tag|41
Link ID         ADV Router      Age         Seq#       Checksum Tag
10.4.4.0        150.1.4.4       971         0x80000005 0x003C86 4120
10.5.5.5        150.1.4.4       971         0x80000005 0x00F2C8 4120
30.0.0.0        150.1.4.4       692         0x80000001 0x009B1F 4120
30.1.0.0        150.1.4.4       691         0x80000001 0x008F2A 4120
30.2.0.0        150.1.4.4       691         0x80000001 0x008335 4120
30.3.0.0        150.1.4.4       691         0x80000001 0x007740 4120
31.0.0.0        150.1.4.4       691         0x80000001 0x008E2B 4120
31.1.0.0        150.1.4.4       691         0x80000001 0x008236 4120
31.2.0.0        150.1.4.4       691         0x80000001 0x007641 4120
31.3.0.0        150.1.4.4       691         0x80000001 0x006A4C 4120
150.1.4.0       150.1.4.4       971         0x80000005 0x005FD8 41
190.1.4.0       150.1.4.4       971         0x80000005 0x0033DD 4120
204.12.1.0      150.1.4.4       971         0x80000006 0x0017E2 4120

Here’s my OSPF->RIP redistribution on r5:

router rip
 redistribute ospf 100 metric 2 route-map OSPF->RIP
!
route-map OSPF->RIP permit 10
 description Tag OSPF routes with 5110
 set tag 5110

So basically, we just need to create a deny statement for routes tagged 4120 or 41:

route-map OSPF->RIP deny 10
 description Filter OSPF routes tagged 4120 or 41
 match tag 4120 41
route-map OSPF->RIP permit 20
 description Tag OSPF routes with 5110
 set tag 5110

Whew!!!  These two tasks took me awhile, but I feel like I had a very good understanding of what was going on.  I’m still painfully slow, but I the basics of route redistribution are finally baking into my brain.  🙂

Internetwork Expert Volume III: Lab 3 – Section 4 Part 1

4 Interior Gateway Routing

4.1 RIPv2

Very simple task.  Luckily they didn’t ask for a minimal configuration:

My answer:
router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 no passive-interface Serial0/1
 network 10.0.0.0
 network 190.1.0.0
 network 204.12.1.0
 no auto-summary

IE’s answer:
router rip
 version 2
 passive-interface Serial0/0 <-much simpler  🙂
 network 10.0.0.0
 network 190.1.0.0
 network 204.12.1.0
 no auto-summary

4.2 RIPv3

“Allow r4 and r5 to send/receive RIP updates between each other across the Serial connection by disabling the validation of RIP updates.”

Remember that the r4 and r5 s1/0 are in different IP subnets.  The wording of the task gives you a huge clue.

validate-update-source

r4(config)#router rip
r4(config-router)#no validate-update-source

Now you’ll see r4’s RIP advertised networks on r5:

r5#clear ip route *
r5#sh ip route rip
R    204.12.1.0/24 [120/1] via 10.4.4.4, 00:00:03
     190.1.0.0/24 is subnetted, 5 subnets
R       190.1.34.0 [120/1] via 10.4.4.4, 00:00:03
R       190.1.4.0 [120/1] via 10.4.4.4, 00:00:03

4.3 RIPv2 Metric Manipulation

“Configure an inbound offset-list on r4so the RIP routes learned from BB3 appear in r5’s routering table with a hop count of 15.”  

This task illustrates one of the differences between the Volume II and Volume III labs: you are more likely to see tasks in the Volume III labs that explicitly tell what feature to use in order to accomplish a task.

offset-list (RIP)

I decided to just offset ALL of the RIP routes coming in fa0/0 rather than configure an explicit ACL.  You can do this by using ACL 0 in your offset-list: 

r4(config-router)#offset-list 0 in 14 fa0/0

This tells the router to add 14 to the hop count of all  RIP routes inbound on interface fa0/0 (to BB3):

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

I was confused when I saw the IE answer:

offset-list 0 in 13 fa0/0

I have no idea why they used 13?

SHIT!!!! YES I DO.  A quick reread the question shows how I lost some easy points by not reading the question carefully:

“Configure an inbound offset-list on r4 so the RIP routes learned from BB3 appear in r5’s router table with a hop count of 15.”

My “solution” not only lost me some easy points, but it also effectively filtered all of the BB3 routes from r5 because they now have a hop-count of 16 on r5 so they are not installed:

r5#sh ip route rip
R    204.12.1.0/24 [120/1] via 10.4.4.4, 00:00:22
     190.1.0.0/24 is subnetted, 5 subnets
R       190.1.34.0 [120/1] via 10.4.4.4, 00:00:22
R       190.1.4.0 [120/1] via 10.4.4.4, 00:00:22

After a quick change:

r4(config)#router rip
r4(config-router)#offset-list 0 in 13 fa0/0  

r5#sh ip route rip
—output truncated—
R       31.3.0.0 [120/15] via 10.4.4.4, 00:00:09
R       31.2.0.0 [120/15] via 10.4.4.4, 00:00:09
R       31.1.0.0 [120/15] via 10.4.4.4, 00:00:09
R       31.0.0.0 [120/15] via 10.4.4.4, 00:00:09
     30.0.0.0/16 is subnetted, 4 subnets
R       30.2.0.0 [120/15] via 10.4.4.4, 00:00:09
R       30.3.0.0 [120/15] via 10.4.4.4, 00:00:09
R       30.0.0.0 [120/15] via 10.4.4.4, 00:00:09
R       30.1.0.0 [120/15] via 10.4.4.4, 00:00:09

4.4 OSPF

Easy OSPF task.  You need to peer r1, r3, and r5 across Frame Relay.  r5 must be the DR and you are not allowed to change the OSPF network type.  You’ll need your old friend, the ‘neighbor’ command to change your OSPF traffic to unicast to get around the default NON_BROADCAST network type.

neighbor (OSPF)

NOTE: Looking at the protocol topology, I don’t see an OSPF area 0. ????

4.5 OSPF

Here’s where that missing area 0 comes back to bite me in the ass.  You are asked to configure two more non-zero areas and then:

“Without regard to network redundancy, use the minimal number of virtual links needed to support this OSPF domain.”

I’m lost.  I thought that you needed to have an area 0.  I have 3 areas: 17, 34, and 135.

I guess that the minimum number of links is one.  We just need to connect r1 (area 17) to r3 (area 35) through area 135.  I am missing a fundamental understanding of OSPF concerning virtual-links and area 0.  I’ll need to hit the books. [It turns out that my understanding was correct, but my lab strategy was flawed…see next task.]

I also changed the OSPF network type on r3 and r4’s Frame Relay interfaces to broadcast to establish an adjacency.  IE used the neighbor command.  Both methods work.

4.6 OSPF Loopback Advertisement

LESSON LEARNED!!!  READ THE ENTIRE LAB.

Well, now I know where to find area 0.  I am tasked with advertising a loopback into area 0 in this task. This makes 4.5 make sense and it makes the virtual link come up.

4.7 OSPF Loopback Advertisement

Advertise another loopback in to OSPF and advertise it with a /24 mask.  Then:

“This subnet should not be associated with any particular area.”

There are two ways to accomplish this, but I only remember one.  🙂

Redistributing Loopback 0 into OSPF will accomplish this task.  I need to keep this in mind when it comes time to do IGP redistribution.

r4(config)#route-map LOOP->OSPF permit
r4(config-route-map)#match int lo0
r4(config-route-map)#router os 100
r4(config-router)#redist conn sub route-map LOOP->OSPF tag 41

r3#sh ip route os | i E
O E2    150.1.4.0/24 [110/20] via 190.1.34.4, 00:01:17, Serial0/1:0

4.8 OSPF Loopback Advertisement

This task switches up the previous task.  This time you need to advertise a loopback with a /24 but it needs to be associated with an area (area not specified) and you cannot use “ip ospf network point-to-point” for this task.

This can be accomplished with the “area range” command.

area range

r3(config-router)#area 3 range 150.1.3.0 255.255.255.0 advertise

r5#sh ip route os | i 150.1.3.0
O IA    150.1.3.0 [110/65] via 190.1.135.3, 00:00:51, Serial0/0.1

r5#sh ip route 150.1.3.3
Routing entry for 150.1.3.0/24
  Known via “ospf 100”, distance 110, metric 65, type inter area
  Last update from 190.1.135.3 on Serial0/0.1, 00:00:54 ago
  Routing Descriptor Blocks:
  * 190.1.135.3, from 150.1.3.3, 00:00:54 ago, via Serial0/0.1
      Route metric is 65, traffic share count is 1

4.9 OSPF Loopback Advertisement

Another variation on a theme: Advertise a loopback into OSPF.  It should appear in all other OSPF routers with a /24 mask.  It should not be associated with any area.  Don’t use ‘redistribute connected’ to do this.

I’m out of ideas.  Maybe a summary route?  Tried it – didn’t work.

The answer is pretty ingenious:

1) Advertise lo0 into RIP
2) Match lo0 in a route-map
2) Redistribute only the lo0 RIP network into OSPF using the route-map

r3#sh ip route 150.1.5.5
Routing entry for 150.1.5.0/24
  Known via “ospf 100“, distance 110, metric 20, type extern 2, forward metric 65
  Last update from 190.1.135.5 on Serial0/0:0.1, 00:00:09 ago
  Routing Descriptor Blocks:
  * 190.1.135.5, from 150.1.5.5, 00:00:09 ago, via Serial0/0:0.1
      Route metric is 20, traffic share count is 1

On the actual lab, I would have simply matched the loopback in a route-map and redistributed connected (with route-map) into OSPF.  I would have lost the points for this task, but OSPF would still have the route with a /24 mask and not associated with any area.

4.10 EIGRP

Easy EIGRP task.  IE solution guide is missing the sw3 configuration.

4.11 EIGRP

Easy EIGRP authentication task.  You need to establish a neighbor relationship with BB1.  The only thing missing is whether you need to use md5 or not (you do).  I honestly don’t think that non-md5 EIGRP authentication is an option anymore, but I will need to research that.

4.12 EIGRP Summarization

Advertise some routers’ loopbacks into EIGRP but have them appear to other routers with a /23 mask rather than a /24 mask.

You need to do route summarization.  Remember that in EIGRP that this is done under the interface that the route will go out:

r2(config-if)#ip summary-address ?
  eigrp  Enhanced Interior Gateway Routing Protocol (EIGRP)
  rip    Routing Information Protocol (RIP)

ip summary-address eigrp

/23 = 255.255.254.0

Need to be careful with sw3 (150.1.9.9)

00001001 with /23 mask will be 150.1.8.0/23

Should I leak the actual loopback IP?  Will this fuck up my router-id?

Interesting:  IOS will change your summary-address statement for you:

sw3(config)#int vlan 2569
sw3(config-if)#ip summary-address eigrp 10 150.1.9.0 255.255.254.0
sw3(config-if)#do sh run int vlan 2569
interface Vlan2569
 ip address 190.1.0.9 255.255.255.0
 ip summary-address eigrp 10 150.1.8.0 255.255.254.0 5

 r5#sh ip route 150.1.2.2 | i Routing entry|Known
Routing entry for 150.1.2.0/23
  Known via “eigrp 10”, distance 90, metric 156160, type internal

r5#sh ip route 150.1.6.6 | i Routing entry|Known
Routing entry for 150.1.6.0/23
  Known via “eigrp 10”, distance 90, metric 156160, type internal

r5#sh ip route 150.1.9.9 | i Routing entry|Known
Routing entry for 150.1.8.0/23  <-note the third octet
  Known via “eigrp 10”, distance 90, metric 156160, type internal

IE solution guide shows 150.1.8.0 255.255.255.

Blog at WordPress.com.