Category list

EIGRP Redistribution and Route Control

< Free Open Study >

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

Practical Scenario

Most IGRP networks have evolved into EIGRP networks, but some still remain . When working with IGRP networks, it is key to be able to control routing updates and propagate default information.

The following lab gives you practice in controlling routing updates, filtering, and default routing.

Lab Exercise

The Sea Shepherd Conservation Society (SSCS), or Sea Shepherd International, is a powerful group of environmentalists committed to defending a segment of the world's population that has no voice. The SSCS has an organized navy that goes by the code name Neptune. The navy has several ships that operate out of various ports across the globe and patrol ecological hot spots enforcing United Nations sanctions. The Neptune Navel Intelligence Network links the various departments of the navy to allow the SSCS quick access to important data. Your task is to configure an IGRP network by using the following parameters as design guidelines:

Configure an IP network, as depicted in Figure 10-6, using IGRP as the routing protocol and 65,001 as the Autonomous System ID.

Figure 10-6. Neptune Naval Intelligence Network
Configure a default network to 204.30.121.0/24 from the sea_shepherd router, and propagate it throughout the IGRP domain.
The ocean_warrior router has a private subnet of 172.16.128.0/24. Prevent only the mirage router from seeing this subnet.
Configure the ocean_warrior router to use all possible paths to the default network.
Optional: Configure IGRP so that broadcasts are less intensive on the LAN segment between the ocean_warrior, sirenian, and mirage routers.

Lab Objectives

Configure the Neptune Naval Intelligence Network as depicted in Figure 10-6. Configure IP as denoted in the diagram. The LAN topology type is not important in this lab.
Use HDLC as the data-link protocol on the WAN.
Configure a default network and propagate it throughout the IGRP domain.
Configure unequal-cost load balancing to the default network from the ocean_warrior router.
Filter subnet 172.16.128.0/24 of the ocean_warrior router from reaching the mirage router. You might need to configure multiple access lists to accomplish this.
Optional: Configure IGRP unicast updates on the LAN segment between the ocean_warrior, sirenian, and mirage routers.

Equipment Needed

Four Cisco routers. Three will be connected through V.35 back-to-back cables or in a similar manner.
Three LAN segments, provided through hubs or switches.
You might want to test the configuration by adding a workstation with the IP address of 204.30.121.31 on the subnet of the sea_shepherd router.

Physical Layout and Prestaging

Connect the hubs and serial cables to the routers, as shown in Figure 10-6.
Optional: Configure an IP workstation with the address of 204.30.121.3 to test the network.

< 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

Define the IGRP process




network 172.16.0.0

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 :

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)

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)

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 >

Flylib.com

Category list

Similar pages

EIGRP Redistribution and Route Control

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

Practical Scenario

Lab Exercise

Figure 10-6. Neptune Naval Intelligence Network

Lab Objectives

Equipment Needed

Physical Layout and Prestaging

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

Lab Walkthrough

Example 10-14 Initial IGRP Configuration for Neptune Naval Intelligence Network Routers

Example 10-15 Route Table of the sea_shepherd Router

Example 10-16 mirage Router Routing Table

Example 10-17 mirage Routing Table After the bandwidth Statements Are Added

Example 10-18 mirage Routing Table After the Default Network Is Set on sea_shepherd

Example 10-19 debug ip igrp transactions Command Output on the ocean_warrior Router

Example 10-20 show ip route Command Output on the ocean_warrior Router

Example 10-21 Configuration of the Distribution List on ocean_warrior

Example 10-22 Route Table of the mirage Router, After the Filter

Example 10-23 Final Router Configurations for Neptune Naval Intelligence Network Routers

Example 10-24 Verifying Unicast Updates

Similar products

Similar products