EIGRP Summarization

 <  Free Open Study  >  

Lab 21: Default Routing, Filtering, and Unequal -Cost Load Sharing in IGRP Networks ”Part II

Lab Walkthrough

Attach the two routers in a back-to-back manner to the sea_shepherd router. Use V.35 cables or CSU/DSUs with crossover cables to connect the routers. Create the three LANs by the use of switches or hubs/MAUs. The LAN segment 172.16.128.0/24 on ocean_warrior can be simulated with a loopback interface.

When the physical connections are complete, assign IP addresses to all LAN and WAN interfaces, as depicted in Figure 10-6. Be sure that you can ping the router's local LAN and WAN interface before moving on. Do not forget to use the clock rate command for the DCE side on the serial interfaces of the sea_shepherd router.

The basic IGRP configuration is similar on all the routers. Following the three-step process for IGRP configuration provided earlier in the chapter, begin by enabling IGRP on all the routers by using the router IGRP 65001 command. The second step is to define the networks to run IGRP on. The sea_shepherd router runs IGRP on major networks 204.30.121.0 and 172.16.0.0. The ocean_warrior router runs IGRP on networks 110.0.0.0 and 172.16.0.0. The mirage and sirenian routers need to run IGRP on only the 172.16.0.0 network. Example 10-14 shows the initial IGRP configuration on the routers.

Example 10-14 Initial IGRP Configuration for Neptune Naval Intelligence Network Routers
  hostname sea_shepherd   !    router igrp 65001 graphics/u2190.gif Define the IGRP process     network 172.16.0.0 graphics/u2190.gif Networks participating in routing    network 204.30.121.0  ______________________________________________________________  hostname ocean_warrior   !   router igrp 65001   network 110.0.0.0   network 172.16.0.0  ______________________________________________________________  hostname sirenian   !   router igrp 65001   network 172.16.0.0   !  ______________________________________________________________  hostname mirage   !   router igrp 65001   network 172.16.0.0   !  

At this point, full routing should exist between all the routers. Verify this with the show ip route command and by ping ing the various interfaces. The route table on the sea_shepherd router resembles Example 10-15.

Example 10-15 Route Table of the sea_shepherd Router
 sea_shepherd#  show ip route  <<<text omitted>>> Gateway of last resort is not set C    204.30.121.0/24 is directly connected, Ethernet0      172.16.0.0/24 is subnetted, 4 subnets I       172.16.128.0 [100/8676] via 172.16.2.5, 00:00:32, Serial0 I       172.16.10.0 [100/8576] via 172.16.2.5, 00:00:56, Serial0 C       172.16.1.0 is directly connected, Serial7 C       172.16.2.0 is directly connected, Serial0 sea_shepherd# 

If you observe the routing table on the mirage router, as in Example 10-16, you can see that two routes exist to the network 204.30.121.0/24. One route travels through ocean_warrior, 172.16.10.1, and one route travels through sirenian. Two routes exist because the default bandwidth has not been changed on the serial interfaces, so IGRP has inconsistent views of the metrics for the routes. To enforce consistent metrics, the bandwidth statement needs to be added to the serial interface on the WAN links. Without bandwidth statements, the sirenian and ocean_warrior routers view both of their links as the T1s. The sea_shepherd router in this example is a Cisco 2522, so the low-speed sync port measures yet a different default metric of 115 for the bandwidth. This reaffirms why you should check and configure the bandwidth statements for proper routing.

Example 10-16 mirage Router Routing Table
 mirage#  show ip route  <<<text omitted>>> Gateway of last resort is not set      172.16.0.0/24 is subnetted, 4 subnets I       172.16.128.0 [100/1200] via 172.16.10.1, 00:01:10, Ethernet0/1 C       172.16.10.0 is directly connected, Ethernet0/1 I       172.16.1.0 [100/8576] via 172.16.10.1, 00:00:41, Ethernet0/1 I       172.16.2.0 [100/8576] via 172.16.10.5, 00:00:44, Ethernet0/1  I    204.30.121.0/24 [100/8676] via 172.16.10.5, 00:00:44, Ethernet0/1   [100/8676] via 172.16.10.1, 00:00:41, Ethernet0/1  mirage# 

After adding bandwidth statements to the serial interfaces, the mirage router shows a preferred route to the 204.30.121.0/24 network through the sirenian router or 172.16.10.5. Example 10-17 lists the output of the show ip route command after the statements bandwidth 64 and bandwidth 1544 to the serial interfaces of the ocean_warrior and sirenian routers, respectively. The statements is also added to the sea_shepherd router.

Example 10-17 mirage Routing Table After the bandwidth Statements Are Added
 mirage#  show ip route  <<<text omitted>>> Gateway of last resort is not set      172.16.0.0/24 is subnetted, 4 subnets I       172.16.128.0 [100/1200] via 172.16.10.1, 00:01:10, Ethernet0/1 C       172.16.10.0 is directly connected, Ethernet0/1 I       172.16.1.0 [100/158350] via 172.16.10.1, 00:01:10, Ethernet0/1 I       172.16.2.0 [100/8576] via 172.16.10.5, 00:00:19, Ethernet0/1  I    204.30.121.0/24 [100/8676] via 172.16.10.5, 00:00:19, Ethernet0/1  mirage# 

The next step in the lab is to configure a default network on the sea_shepherd router. To achieve this, add the global command ip default-network 204.30.121.0 on the sea_shepherd router. Remember, for a router to use a default route, ip classless also must be enabled. Viewing the route table on the mirage router, the default network is now set with the *, and a gateway of last resort is also set to network 204.30.121.0. Example 10-18 lists the routing table of mirage after the default network is set on the sea_shepherd router.

Example 10-18 mirage Routing Table After the Default Network Is Set on sea_shepherd
 mirage#  show ip route  <<<text omitted>>> Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR  Gateway of last resort is 172.16.10.5 to network 204.30.121.0  172.16.0.0/24 is subnetted, 4 subnets I       172.16.128.0 [100/1200] via 172.16.10.1, 00:03:06, Ethernet0/1 C       172.16.10.0 is directly connected, Ethernet0/1 I       172.16.1.0 [100/158350] via 172.16.10.1, 00:01:18, Ethernet0/1 I       172.16.2.0 [100/8576] via 172.16.10.5, 00:00:27, Ethernet0/1 I    110.0.0.0/8 [100/1200] via 172.16.10.1, 00:01:18, Ethernet0/1  I*   204.30.121.0/24 [100/8676] via 172.16.10.5, 00:00:27, Ethernet0/1  mirage# 

Another task of this lab is to configure unequal-cost load balancing to the default network from the mirage router. Recalling the process from an earlier section, you need to set the bandwidth and then derive and configure the variance. You have already accomplished the first step by taking the extra time to tune the IGRP configuration with the bandwidth statements earlier in the lab. For the second step, you need to derive the variance. The variance formula is as follows :

graphics/10equ03.gif


Use debug ip igrp transactions to find the lowest -cost metric to 204.30.121.0/24. Example 10-19 shows the output of the command on the ocean_warrior router.

Example 10-19 debug ip igrp transactions Command Output on the ocean_warrior Router
 ocean_warrior#  debug ip igrp transactions  IGRP protocol debugging is on ocean_warrior# 04:35:06: IGRP: received update from 172.16.1.4 on Serial1 04:35:06:       subnet 172.16.10.0, metric 160350 (neighbor 8576) 04:35:06:       subnet 172.16.2.0, metric 160250 (neighbor 8476)  04:35:06:        exterior network 204.30.121.0, metric 158350 (neighbor 1100) graphics/u2190.gif High   metric  04:35:06: IGRP: received update from 172.16.10.9 on Ethernet4 04:35:06:       subnet 172.16.10.0, metric 1200 (neighbor 1100) 04:35:06:       subnet 172.16.2.0, metric 8676 (neighbor 8576)  04:35:06:       exterior network 204.30.121.0, metric 8776 (neighbor 8676) graphics/u2190.gif low   metric  

In this model, you have 1 + (158350/8776) = 20. After the variance is set, the router reports two paths to the destination network and load-shares over them. Example 10-20 shows the route table of the ocean_warrior router after the variance 20 command was added under the IGRP process.

Example 10-20 show ip route Command Output on the ocean_warrior Router
 ocean_warrior#  show ip route  <<<text omitted>>> Gateway of last resort is 172.16.1.4 to network 204.30.121.0      172.16.0.0/24 is subnetted, 4 subnets C       172.16.128.0 is directly connected, Ethernet3 C       172.16.10.0 is directly connected, Ethernet4 C       172.16.1.0 is directly connected, Serial1 I       172.16.2.0 [100/160250] via 172.16.1.4, 00:00:11, Serial1                    [100/8576] via 172.16.10.5, 00:00:34, Ethernet4  I*   204.30.121.0/24 [100/158350] via 172.16.1.4, 00:00:11, Serial1   [100/8676] via 172.16.10.5, 00:00:34, Ethernet4   Two paths to the default network!  ocean_warrior# 

Next, you need to filter the ocean_warrior subnet of 110.16.20.0/24 from the mirage router. You need to configure distribute lists on the ocean_warrior router and the sirenian router. Example 10-21 shows the configuration of the ocean_warrior distribute list. The distribute list on the sirenian router is identical except for the Ethernet port.

Example 10-21 Configuration of the Distribution List on ocean_warrior
 ocean_warrior(config)#  router igrp 65001  ocean_warrior(config-router)#  distribute-list 10 out e4  ocean_warrior(config-router)#  exit  ocean_warrior(config)#  access-list 10 deny 172.16.128.0 0.0.0.255  ocean_warrior(config)#  access-list 10 permit any  

When the 172.16.128.0/24 route is filtered out the Ethernet port on the ocean_warrior router, sirenian tries to route to this route through the sea_shepherd router. A static route can be added to sirenian to prevent this. Example 10-22 now lists the route table of the mirage router without the 172.16.128.0/24 subnet.

Example 10-22 Route Table of the mirage Router, After the Filter
 mirage#  show ip route  <<<text omitted>>> Gateway of last resort is 172.16.10.5 to network 204.30.121.0      172.16.0.0/24 is subnetted, 3 subnets C       172.16.10.0 is directly connected, Ethernet0/1 I       172.16.1.0 [100/158350] via 172.16.10.1, 00:00:08, Ethernet0/1 I       172.16.2.0 [100/8576] via 172.16.10.5, 00:00:27, Ethernet0/1 I*   204.30.121.0/24 [100/8676] via 172.16.10.5, 00:00:27, Ethernet0/1 mirage# 

Finally, the optional portion of the lab involves limiting broadcasts on the Ethernet segment between the routers. Broadcast can be limited by enabling unicast routing updates. The neighbor a.b.c.d statement, along with the passive interface command, causes only unicast routing updates to occur. The last example lists the final router configs , which includes the unicast configuration.

Example 10-23 Final Router Configurations for Neptune Naval Intelligence Network Routers
  hostname sea_shepherd   !   interface Ethernet0   ip address 204.30.121.30 255.255.255.0   !   interface Serial0   ip address 172.16.2.4 255.255.255.0   bandwidth 1544   no fair-queue   clockrate 2000000   !   interface Serial7   ip address 172.16.1.4 255.255.255.0   bandwidth 64   clockrate 64000   !   router igrp 65001   network 172.16.0.0   network 204.30.121.0   !   ip classless   ip default-network 204.30.121.0   !  ______________________________________________________________  hostname ocean_warrior   !   interface Ethernet3   ip address 172.16.128.1 255.255.255.0   media-type 10BaseT   !   interface Serial1   ip address 172.16.1.1 255.255.255.0   bandwidth 64   !   router igrp 65001   variance 20   passive-interface Ethernet4   network 110.0.0.0   network 172.16.0.0   neighbor 172.16.10.5   neighbor 172.16.10.9   distribute-list 10 out Ethernet4   !   ip classless   !   access-list 10 deny   172.16.128.0 0.0.0.255   access-list 10 permit any  ______________________________________________________________  hostname sirenian   !   interface Ethernet0   ip address 172.16.10.5 255.255.255.0   no ip directed-broadcast   !   interface Serial0   ip address 172.16.2.5 255.255.255.0   bandwidth 1544   no ip directed-broadcast   no ip mroute-cache   no fair-queue   !   router igrp 65001   passive-interface Ethernet0   network 172.16.0.0   neighbor 172.16.10.1   neighbor 172.16.10.9   distribute-list 10 out Ethernet0   !   ip classless   ip route 172.16.128.0 255.255.255.0 172.16.10.1  ______________________________________________________________  hostname mirage   !   interface Ethernet0/1   ip address 172.16.10.9 255.255.255.0   !   router igrp 65001   passive-interface Ethernet0/1   network 172.16.0.0   neighbor 172.16.10.5   neighbor 172.16.10.1   !   ip classless  

To verify unicast updates, perform a debug ip igrp transactions command on the sirenian or ocean_warrior routers. By performing this command on the sirenian router in Example 10-24, notice how the updates out the Ethernet 0 port are no longer sent to a broadcast address or 255.255.255.255, but instead are sent to a specific address as specified in the neighbor statement.

Example 10-24 Verifying Unicast Updates
 sirenian#  debug ip igrp transactions  IGRP protocol debugging is on sirenian#  01:01:40: IGRP: sending update to 255.255.255.255 via Serial0 (172.16.2.5)  01:01:40:       subnet 172.16.10.0, metric=1100 01:01:40:       subnet 172.16.1.0, metric=158350  01:01:41: IGRP: sending update to 172.16.10.9 via Ethernet0 (172.16.10.5)  01:01:41:       subnet 172.16.10.0, metric=1100 01:01:41:       subnet 172.16.1.0, metric=158350 01:01:41:       subnet 172.16.2.0, metric=8476 01:01:41:       exterior 204.30.121.0, metric=8576  01:01:41: IGRP: sending update to 172.16.10.1 via Ethernet0 (172.16.10.5)  01:01:41:       subnet 172.16.10.0, metric=1100 01:01:41:       subnet 172.16.2.0, metric=8476 01:01:41:       exterior 204.30.121.0, metric=8576 
 <  Free Open Study  >  


CCIE Practical Studies, Volume I
CCIE Practical Studies, Volume I
ISBN: 1587200023
EAN: 2147483647
Year: 2001
Pages: 283
Authors: Karl Solie

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net