Ccnp Route Lab Manual

CCNP ROUTE Challenge Lab Erick Borgard CCNP

Introduction: This challenge lab is meant to help prepare individuals for the CCNP route exam. Having the theory and knowledge of the concepts outlined in the ROUTE curriculum is necessary. Being able to implement the concepts is also very important. This challenge lab will focus on some of the concepts that a CCNP candidate will need to know to pass the exam. This lab does not cover every topic in the ROUTE curriculum. The CCNP candidate should be prepared to follow the exam topics outlined in the official Cisco CCNP blueprint and pursue additional sources for understanding of each technology.

Target Audience: The content in this lab is targeted to those individuals that have CCNA level knowledge and are presently studying for the CCNP ROUTE exam. All CCNA level understanding is assumed and will not be covered in detail in the exercise.

Required Items: •GNS3 or a home lab with 7 Cisco routers •IOS image (I used c3725-adventerprisek9-mz.124-15.T13.bin) •Computer than can support 7 routers in GNS3 •Initial configurations •Lab diagram If you use a different IOS image or router, you may need to build your own topology with the router you are presently using and adjust the interface names accordingly. I can not guarantee that this lab will produce the desired results if the 3725 IOS is not used.

Diagrams Physical diagrams are provided as well as the logical IGP diagram The professional level engineer will need to understand network diagrams and interpret them correctly to satisfy specific design requirements. There is a cost associated with keeping updated network diagrams when there are a lot of network changes occuring. This is especially important in enterprise organizations.

IP Addressing: Interface IP addresses will use the following structure. •10.1.x.x/24 Physical and frame relay sub-interfaces •177.1.x.x/24 Loopback interfaces For the physical interface IP addresses the first X represents the router segment and the last X will represent the router number. For example. If there is a connection between R1 and R7, the IP addressing structure would be 10.1.17.1 and 10.1.17.7.

TCL Scripting TCL scripting gives the engineer an advantage to test connectivity to each subnet without having to type ping x.x.x.x where X is the IP address of the destination. This is especially helpful if there are a large number of subnets to test. This lab includes the TCL script needed to test reachability for each router. To use the TCL script, type tclsh from the privileged exec mode. Once inside the TCL script shell, paste the script into the CLI and hit enter. To exit TCL script shell, type tclquit.

Challenge lab DOs and DON'Ts: •Do load the initial configurations before starting •Do backup your configurations if you can't finish the lab in one session •Do not change the IP addressing •Do not change the encapsulation on the interfaces •Do not use static routing unless told to do so

Topics Covered in this lab: OSPF (Multi-Area)Ipv4 & IPv6EIGRPIPv4eBGPIPv4RedistributionIpv4 & IPv6Route filteringIPv4Default RoutingIPv4EIGRP SummarizationIPv4TroubleshootingIPv4Floating Static RoutesIPv4

Challenge Lab Part I Interior Gateway Protocols: Section 1 OSPF •Configure OSPF according to the provided diagram •OSPF should log all neighbor relationship changes •Hard code all OSPF router Ids using the highest loopback interface IP address •Ensure that OSPF only runs on the interfaces specified in the diagram •Configure R2 and R3 such that they will never become the DR/BDR •All loopback interface should be seen with their native subnet mask •Configure hash-based authentication on R1, R2 &R3. Use key 5 with md5 CCNP to create the hash. Do not use area authentication to complete this task.

•R1 should send a default route to all downstream routers

Section 2 EIGRP •Configure EIGRP on R2, R3, R4 & R5 •Only the interfaces shown in the diagram should be configured for EIGRP •Advertise all loopback interfaces into EIGRP on R4 & R5 •EIGRP should not automatically summarize to the classful boundary •Traffic originating from loopback4 on R4 destined for loopback 5 on R5 should use R3 as the next hop. •Configure MD5 authentication between all EIGRP peers •EIGRP should only be allowed to use 25% of the interface bandwidth •Summarize the loopbacks of R5 in such a way that the most efficient subnet mask is used. •R2 should only install the summarized address and the third loopback of R5 into the route table.

Section 3 Redistribution •Perform mutual redistribution between OSPF and EIGRP on R2 •177.5.1.1 should not be redistributed. •Tag EIGRP and OSPF routes. •The metric of the 177.4.1.1 prefix should be set to 1500 in OSPF. •If R2s link to R4 should fail, R4 should still be able to reach any loopback on R1(You may use a static route to complete this task)

Section 4 eBGP •Create an eBGP peering between R1 and R7 •Use the first loopback on R1 and R7 for the peering •Advertise the last loopback on R1 into BGP. Do not use redistribution or summarization •R1 should receive a default route from R7

Solutions: Before you get started with any section of the lab, you need to make sure that the initial configurations loaded correctly and that there connectivity between the directly connected interfaces and connectivity in the frame-relay network. Test connectivity between all directly connected interfaces now. If you do not have connectivity between your directly connected interfaces, troubleshoot the issue and come back here when you are done. Example 1.1

R2#ping 10.1.123.3

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

..... Success rate is 0 percent (0/5)

There is no connectivity between the spoke routers in the frame relay network. Refer to Example 1.2 Example 1.2 R2#sh frame map Serial0/0 (up): ip 10.1.123.1 dlci 201(0xC9,0x3090), static, broadcast, CISCO, status defined, active

It appears by the output that there is only one frame relay mapping to the hub router. DLCI mappings between the spoke routers are needed to complete the frame-relay network configuration. **Note** The broadcast keyword is not needed when creating frame relay mappings between the spoke routers. It would be considered as an over configuration. Adding the broadcast keyword to the spoke routers isn't incorrect configuration, but the general rule of thumb is to add the broadcast keyword on your hub mappings only. Add the frame relay mappings to R2 and R3 and verify connectivity. Example 1.3 R2

configure terminal ! ! interface s0/0 frame-relay map ip 10.1.123.3 201

R3 configure terminal ! interface s0/0 frame-relay map ip 10.1.123.2 301

Verify:

R2#sh frame-relay map Serial0/0 (up): ip 10.1.123.3 dlci 201(0xC9,0x3090), static, CISCO, status defined, active Serial0/0 (up): ip 10.1.123.1 dlci 201(0xC9,0x3090), static, broadcast, CISCO, status defined, active R2#ping 10.1.123.3

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

Once connectivity has been verified, please proceed to section 1. **Hint** If you did not do this before starting, you will find yourself troubleshooting during the OSPF portion.

Section 1 OSPF •Configure OSPF according to the provided diagram •OSPF should log all neighbor relationship changes •Hard code all OSPF router Ids using the highest loopback interface IP address •Ensure that OSPF does not run on the interface between R1 and R7 •Configure R2 and R3 such that they will never become the DR/BDR •Advertise the loopback interfaces on R6 into OSPF •All loopback interface should be seen with their native subnet mask •R1 should send a default route to all downstream routers **Hint** Read all requirements for the section before attempting any portion of the configuration. Example 1.4

R1#sh run | sec ospf

ip ospf priority 255 router ospf 100 router-id 177.1.5.5 log-adjacency-changes passive-interface Serial0/1 network 10.1.123.0 0.0.0.255 area 0 network 10.1.12.0 0.0.0.255 area 0 network 177.1.1.0 0.0.0.255 area 0 network 177.1.2.0 0.0.0.255 area 0 network 177.1.3.0 0.0.0.255 area 0 network 177.1.4.0 0.0.0.255 area 0 network 177.1.5.0 0.0.0.255 area 0 neighbor 10.1.123.2 neighbor 10.1.123.3

R2#sh run | sec ospf ip ospf priority 0 router ospf 100 router-id 177.2.5.5 log-adjacency-changes passive-interface FastEthernet0/1 network 10.1.24.0 0.0.0.255 area 24 network 10.1.123.0 0.0.0.255 area 0 network 10.1.12.0 0.0.0.255 area 0 network 177.2.1.0 0.0.0.255 area 0 network 177.2.2.0 0.0.0.255 area 0 network 177.2.3.0 0.0.0.255 area 0

network 177.2.4.0 0.0.0.255 area 0 network 177.2.5.0 0.0.0.255 area 0

R3#sh run | sec ospf ip ospf priority 0 router ospf 100 router-id 177.3.5.5 log-adjacency-changes passive-interface FastEthernet0/1 network 10.1.35.0 0.0.0.255 area 35 network 10.1.123.0 0.0.0.255 area 0 network 177.3.1.0 0.0.0.255 area 0 network 177.3.2.0 0.0.0.255 area 0 network 177.3.3.0 0.0.0.255 area 0 network 177.3.4.0 0.0.0.255 area 0 network 177.3.5.0 0.0.0.255 area 0

R4#sh run | sec ospf router ospf 100 router-id 177.4.5.5 log-adjacency-changes passive-interface FastEthernet0/1 network 10.1.24.0 0.0.0.255 area 24 network 10.1.46.0 0.0.0.255 area 46

R5#sh run | sec ospf router ospf 100

router-id 177.5.5.5 log-adjacency-changes passive-interface FastEthernet0/1 network 10.1.35.0 0.0.0.255 area 35

R6#sh run | sec ospf router ospf 100 router-id 177.6.5.5 log-adjacency-changes network 10.1.46.0 0.0.0.255 area 46 network 177.6.1.0 0.0.0.255 area 46 network 177.6.2.0 0.0.0.255 area 46 network 177.6.3.0 0.0.0.255 area 46 network 177.6.4.0 0.0.0.255 area 46 network 177.6.5.0 0.0.0.255 area 46 network 177.6.6.0 0.0.0.255 area 46

Although it is not required to use the passive-interface command on the other routers, go ahead and add it. The reason is that the Fa0/1 interfaces will be running EIGRP on R2, R3, R4 and R5. Using this command is very useful to prevent misconfigurations when there is more than 1 routing protocol in your environment. It's also a good idea to use the passive-interface command on any interfaces that are service provider facing. Just in case....... Unless of course you decide to do so. So far with this configuration, we enabled OSPF on the interfaces. That satisfies one requirement. We also satisfied the requirement that R2 and R3 should never be elected the DR/BDR with the ip ospf priority 0 interface command. The interface configurations were not displayed above, so if you have not set the priorities on your frame relay spoke routers, go ahead and do that now. Don't forget to clear the OSPF process on R1, R2 and R3. This must be done so that a new election will take place. When the neighbors reform, the output of the show ip ospf neighbor command should resemble the output below.

Example 1.5 R1#sh ip ospf neighbor

Neighbor ID

Pri State

Dead Time

Address

Interface

177.2.5.5

0

FULL/DROTHER

00:01:42

10.1.123.2

Serial0/0.123

177.3.5.5

0

FULL/DROTHER

00:01:50

10.1.123.3

Serial0/0.123

Please notice that R1 sees two neighbors and both of the neighbors have a priority of 0. **Hint** Make sure all of the other OSPF neighbor relationships have formed and that the routers are receiving full routes for all areas.

Virtual Links You may have also noticed that R6 is not receiving any routes. The reason is that area 46 is not connected to area 0. Area 46 needs to be connected to the backbone. This can be accomplished with a virtual link or a GRE tunnel. Virtual links will be covered in the OSPF section and GRE tunnels will be covered briefly in the EIGRP section. What is a virtual link? A virtual link is what I would call a virtual area 0 interface that can be used to connect areas that are not connected to the backbone. A transit autonomous system must be used to form the virtual link. The transit AS must have a full routing table and can not be a stub area. In this lab, area 24 will be the transit AS and will be used to create the virtual link. The virtual link will be created between R2 and R4. **Note** See RFC 2328 for more information on OSPF and virtual links. The syntax for creating a virtual link is as follows under router configuration mode. Area virtual-link Example 1.6 R2 router ospf 100 area 24 virtual-link 177.4.5.5

R4 router ospf 100 area 24 virtual-link 177.2.5.5

Verify:

R4#sh ip ospf virtual-links Virtual Link OSPF_VL1 to router 177.2.5.5 is up Run as demand circuit DoNotAge LSA allowed. Transit area 24, via interface FastEthernet0/0, Cost of using 10 Transmit Delay is 1 sec, State POINT_TO_POINT,

---------Some output omitted---------

R4#sh ip ospf neighbor

Neighbor ID

Pri

State

Dead Time -

Address

177.2.5.5

0

FULL/ -

177.2.5.5

1

FULL/BDR

00:00:35

10.1.24.2

FastEthernet0/0

177.6.5.5

0

FULL/ -

00:00:37

10.1.46.6

Serial0/0

R6 R6#sh ip route ospf 177.1.0.0/24 is subnetted, 5 subnets O IA

177.1.1.0 [110/139] via 10.1.46.4, 00:02:09, Serial0/0

O IA

177.1.2.0 [110/139] via 10.1.46.4, 00:02:09, Serial0/0

O IA

177.1.3.0 [110/139] via 10.1.46.4, 00:02:09, Serial0/0

10.1.24.2

Interface OSPF_VL1

O IA

177.1.4.0 [110/139] via 10.1.46.4, 00:02:09, Serial0/0

O IA

177.1.5.0 [110/139] via 10.1.46.4, 00:02:09, Serial0/0

177.2.0.0/24 is subnetted, 5 subnets O IA

177.2.3.0 [110/75] via 10.1.46.4, 00:02:09, Serial0/0

O IA

177.2.2.0 [110/75] via 10.1.46.4, 00:02:09, Serial0/0

O IA

177.2.1.0 [110/75] via 10.1.46.4, 00:02:09, Serial0/0

O IA

177.2.5.0 [110/75] via 10.1.46.4, 00:02:09, Serial0/0

O IA

177.2.4.0 [110/75] via 10.1.46.4, 00:02:09, Serial0/0

177.3.0.0/24 is subnetted, 5 subnets O IA

177.3.2.0 [110/139] via 10.1.46.4, 00:02:09, Serial0/0

O IA

177.3.3.0 [110/139] via 10.1.46.4, 00:02:09, Serial0/0

O IA

177.3.1.0 [110/139] via 10.1.46.4, 00:02:09, Serial0/0

O IA

177.3.4.0 [110/139] via 10.1.46.4, 00:02:09, Serial0/0

O IA

177.3.5.0 [110/139] via 10.1.46.4, 00:02:09, Serial0/0

10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks O IA

10.1.24.0/24 [110/74] via 10.1.46.4, 00:02:09, Serial0/0

O IA

10.1.35.0/24 [110/148] via 10.1.46.4, 00:02:09, Serial0/0

O IA

10.1.123.0/24 [110/138] via 10.1.46.4, 00:02:09, Serial0/0

To test our end to end configuration, we can source traffic a loopback on R6 to a loopback on R3.

R6#ping 177.3.5.5 source 177.6.5.5

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.3.5.5, timeout is 2 seconds: Packet sent with a source address of 177.6.5.5 !!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/39/68 ms

**Note** If you can't reach R3 loopback from R6. It's time to troubleshoot. Do NOT continue until you can reach R3 loopback from a loopback on R6. **Hint** When testing connectivity, get in the habit of “sourcing” your traffic from different connected interfaces on the router.

OSPF Network Types In Example 1.6, the routing table on R6 displays a bolded “/24”. One of the requirements was that the loopback interfaces need to have the native subnet mask in the routing table. OSPF will treat loopback interfaces as network hosts, therefore assigning them a /32 mask in the IP routing table. To get the loopback interfaces to display their correct subnet mask, (the one that was configured on the interface) we need to add the ip ospf network point-to-point command on the loopback interfaces on all routers advertising loopbacks into OSPF. If you have not done this yet, go ahead and add that command to the loopbacks that are participating in OSPF. Remember that R4 & R5 are do not have any loopback interfaces participating in OSPF.

A chart is included listing the different OSPF network types. OSPF Network TypeDR/BDR ElectionNonBroadcast Multi-accessYesBroadcast MultiaccessYesPoint-to-pointNoPoint-to-multipointNoPoint-to-multipoint non-broadcastNo

The last two requirements in the OSPF section is to advertise a default route to all downstream routers and to configure a hash-based authentication method on R1, R2 and R3.

Default Routing Let's take a look at the default route first. Sending a default route can be accomplished with the default-information originate command with the always keyword. The reason we are using the always keyword is so R1 will advertise the default route. If you do not use the always keyword, a default route will not be injected because there is no default route configured on R1. In a production environment, it is likely that you will not use the always keyword. An engineer could risk black-holing traffic destined for outside networks if there is no default route in the routing table. Example 1.7 R1

R1(config-router)#default-information originate always

R6 R6#sh ip route | in E2 E1 - OSPF external type 1, E2 - OSPF external type 2 O*E2 0.0.0.0/0 [110/1] via 10.1.46.4, 00:03:08, Serial0/0

OSPF Authentication OSPF can use 3 types of authentication. •Null authentication •Plain test authentication •MD5 authentication For the purposes of this lab, we are being asked to use a hash-based authentication method, so the correct method is to use MD5. Example 1.8 R1 interface Serial0/0.123 multipoint ip address 10.1.123.1 255.255.255.0 ip ospf authentication message-digest ip ospf message-digest-key 5 md5 CCNP ip ospf priority 255 snmp trap link-status frame-relay map ip 10.1.123.3 103 broadcast frame-relay map ip 10.1.123.2 102 broadcast

R2

interface Serial0/0

ip address 10.1.123.2 255.255.255.0 encapsulation frame-relay ip ospf authentication message-digest ip ospf message-digest-key 5 md5 CCNP ip ospf priority 0 clock rate 2000000 frame-relay map ip 10.1.123.1 201 broadcast frame-relay map ip 10.1.123.3 201

R3

interface Serial0/0 ip address 10.1.123.3 255.255.255.0 encapsulation frame-relay ip ospf authentication message-digest ip ospf message-digest-key 5 md5 CCNP ip ospf priority 0 clock rate 2000000 frame-relay map ip 10.1.123.1 301 broadcast frame-relay map ip 10.1.123.2 301

R1#sh ip ospf neighbor

Neighbor ID

Pri State

Dead Time Address

Interface

177.2.5.5

0

FULL/DROTHER

00:01:34

10.1.123.2

Serial0/0.123

177.3.5.5

0

FULL/DROTHER

00:01:51

10.1.123.3

Serial0/0.123

If the OSPF neighbor relationships between R1, R2 and R3 did not reform, it's time to troubleshoot. Do NOT proceed until OSPF has been authenticated between these devices.

Section 2 EIGRP Since the basic configuration of EIGRP is a CCNA topic, it will not be covered in detail here. I would like to expand on a concept that we saw in the OSPF section. In the OSPF section I introduced a concept of using the passive-interface command. This is where the EIGRP configuration can get a little more complicated. The EIGRP requirement stated that only the interfaces shown in the diagram should participate in EIGRP. **Hint** Refer back to the provided network diagrams. See the new EIGRP configuration in Example 2.2 If you have done the configuration correctly, the EIGRP routes on R2 and R3 should resemble the following. Please refer to Example 2.2 for the EIGRP configurations. Example 2.1

R2#sh ip route eigrp 177.5.0.0/24 is subnetted, 5 subnets D

177.5.4.0 [90/409600] via 10.1.25.5, 00:00:42, FastEthernet0/1

D

177.5.5.0 [90/409600] via 10.1.25.5, 00:00:42, FastEthernet0/1

D

177.5.1.0 [90/409600] via 10.1.25.5, 00:00:42, FastEthernet0/1

D

177.5.2.0 [90/409600] via 10.1.25.5, 00:00:42, FastEthernet0/1

D

177.5.3.0 [90/409600] via 10.1.25.5, 00:00:42, FastEthernet0/1

R3#sh ip route eigrp 177.4.0.0/24 is subnetted, 5 subnets D

177.4.5.0 [90/409600] via 10.1.34.4, 00:04:29, FastEthernet0/1

D

177.4.4.0 [90/409600] via 10.1.34.4, 00:04:29, FastEthernet0/1

D

177.4.1.0 [90/409600] via 10.1.34.4, 00:04:29, FastEthernet0/1

D

177.4.3.0 [90/409600] via 10.1.34.4, 00:04:29, FastEthernet0/1

D

177.4.2.0 [90/409600] via 10.1.34.4, 00:04:29, FastEthernet0/1

Example 2.2

R2#sh run | sec eigrp router eigrp 200 passive-interface default no passive-interface FastEthernet0/1 network 10.1.25.0 0.0.0.255 no auto-summary

R3#sh run | sec eigrp router eigrp 200 passive-interface default no passive-interface FastEthernet0/1 network 10.1.34.0 0.0.0.255 no auto-summary

R4#sh run | sec eigrp router eigrp 200 passive-interface default no passive-interface FastEthernet0/1 no passive-interface Loopback1 no passive-interface Loopback2 no passive-interface Loopback3 no passive-interface Loopback4 no passive-interface Loopback5 network 10.1.34.0 0.0.0.255 network 177.4.0.0

R5#sh run | sec eigrp router eigrp 200 passive-interface default no passive-interface FastEthernet0/1 no passive-interface Loopback1 no passive-interface Loopback2 no passive-interface Loopback3 no passive-interface Loopback4 no passive-interface Loopback5 network 10.1.25.0 0.0.0.255 network 177.5.0.0 no auto-summary

In the above example, the passive-interface default command was used. This command can be used to make all interfaces passive. From there, the engineer can use the no passive-interface command to only allow specific interfaces to participate. Verify the configuration by using the IOS extended ping feature. It's important at the professional level to be able to use the tools that IOS provides. You may often see the extended ping feature used in a single line IOS command. You should use both methods and see what works for you. Example 2.3 R4#ping

Protocol [ip]: Target IP address: 177.5.5.5 Repeat count [5]: 25 Datagram size [100]: 1200 Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 177.4.4.4 Type of service [0]:

Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 25, 1200-byte ICMP Echos to 177.5.5.5, timeout is 2 seconds: Packet sent with a source address of 177.4.4.4 !!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (25/25), round-trip min/avg/max = 4/19/48 ms

Check the routing table on R4 to see what path was used to reach 177.5.5.5. Refer to Example 2.4 Example 2.4 R4#sh ip route 177.5.5.5 % Network not in table

The reason the 177.5.5.5 prefix is reachable even though there is no route to that destination in the routing table is because R4 is using the default route that was injected with OSPF. Refer to Example 2.5 Example 2.5 R4#sh ip route | in 0.0.0.0 Gateway of last resort is 10.1.24.2 to network 0.0.0.0 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks O*E2 0.0.0.0/0 [110/1] via 10.1.24.2, 00:58:40, FastEthernet0/0

Traffic Engineering From the output in Example 2.5 we can see that the next hop is R2. Let's take a look at one of the requirements in EIGRP. •Traffic originating from loopback4 on R4 destined for loopback 5 on R5 should use R3 as the next hop. R4 is using R2 as the next hop and the requirement states that R3 should be the next hop. It's time to

go back and look at the diagram. **Note** Please refer to the provided network diagrams Even if R4 sent packets to R3, R3 would send that traffic to the next hop using the default route. R1 would then drop that traffic because there is no redistribution in place yet. There is no link between R2 and R3. That's a problem. Our goal should be to find a way to get R5s routes to the routing table of R4. If that can happen, then R4 would prefer the path learned by EIGRP over the default route. A GRE tunnel can be created between R2 and R3. From there, the only thing left to do is to run EIGRP in tunnel interfaces. If the tunnel endpoints have connectivity, an EIGRP neighbor relationship should form. Don't forget to use the no passive-interface Tunnel command so EIGRP will send hellos out of the tunnel interfaces on R2 and R3. If you do not, the EIGRP neighbor relationship will not form. **Note** A GRE tunnel is a logical tunnel with no security natively supported. It can transport multiple protocols, by encapsulating the payload with a GRE header. Each protocol can then add the necessary transport encapsulation. Please refer to RFC 2784 for more information on GRE. R2 interface Tunnel10 ip address 100.1.1.1 255.255.255.0 tunnel source Loopback1 tunnel destination 177.3.1.1 ! ! router eigrp 200 no passive-interface Tunnel10

R3 interface Tunnel10 ip address 100.1.1.2 255.255.255.0 tunnel source Loopback1 tunnel destination 177.2.1.1

! ! router eigrp 200 no passive-interface Tunnel10

Verify the configuration by examining the EIGRP neighbor relationships on R2. You could also use R3 if you prefer. Example 2.6

R2#show ip eigrp neighbors IP-EIGRP neighbors for process 200 H Address

Interface

Hold Uptime SRTT (sec)

(ms)

RTO Q Cnt

Seq Num

1 100.1.1.2

Tu10

13 00:22:20

142

5000 0

18

0 10.1.25.5

Fa0/1

13 00:28:45

1016

5000 0

12

The requirement to prefer R3 as the next hop should be fulfilled. Verify by examining the routing table on R4. Example 2.7

R4#sh ip route 177.5.5.5 Routing entry for 177.5.5.0/24 Known via "eigrp 200", distance 90, metric 297423616, type internal Redistributing via eigrp 200 Last update from 10.1.34.3 on FastEthernet0/1, 00:25:54 ago Routing Descriptor Blocks: * 10.1.34.3, from 10.1.34.3, 00:25:54 ago, via FastEthernet0/1 Route metric is 297423616, traffic share count is 1 Total delay is 507000 microseconds, minimum bandwidth is 9 Kbit Reliability 255/255, minimum MTU 1476 bytes Loading 1/255, Hops 3

Example 2.6 now shows R3 as the next hop to reach 177.5.5.5. This can be further verified by using the traceroute command on R4.

Example 2.8 R4#traceroute Protocol [ip]: Target IP address: 177.5.5.5 Source address: 177.4.4.4 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 177.5.5.5

1 10.1.34.3 8 msec 4 msec 4 msec 2 100.1.1.1 16 msec 28 msec 20 msec 3 10.1.25.5 20 msec * 32 msec

The output of Example 2.8 shows that traffic destined for 177.5.5.5 used R3 as the next hop and that traffic passed over the GRE tunnel to reach 177.5.5.5.

Fine Tuning EIGRP The next requirement is to only allow EIGRP 25% of the interface bandwidth for control plane operations. By default, EIGRP will use 50% of the routers interface bandwidth. In today's networks, that's not much of an issue. If EIGRP is taking 50% of the interface bandwidth, there is a major problem in the network that needs to be addressed. When changing the value from 50% to 25%, don't forget to include the tunnel interfaces we created earlier in this section. Example 2.9 R2(config)#interface fa0/1 R2(config-if)#ip bandwidth-percent eigrp 200 25

! R2(config)#interface tunnel10 R2(config-if)#ip bandwidth-percent eigrp 200 25

R3(config)#interface fa0/1 R3(config-if)#ip bandwidth-percent eigrp 200 25 ! R3(config)#interface tunnel10 R3(config-if)#ip bandwidth-percent eigrp 200 25

R4(config)#interface fa0/1 R4(config-if)#ip bandwidth-percent eigrp 200 25

R5(config)#interface fa0/1 R5(config-if)#ip bandwidth-percent eigrp 200 25

EIGRP Authentication EIGRP authentication uses a system of keys and key chains. A key and a key string are used to create the md5 hash. This is very similar to RIP. One of the differences is that with EIGRP authentication, the key numbers must match. This means that if you configured key 5 on one side of the link, you will need to configure key5 for the other side of the link for the neighbor relationship to form. The steps to configuring EIGRP authentication is as follows: •Create the Key Chain •Create the key number •Create the key string •Configure EIGRP authentication mode to MD5 •Bind the key chain to the interface

Example 2.10 R2

key chain EIGRP_AUTH key 5 key-string CCNP ! ! ! interface fa0/1 ip authentication mode eigrp 200 md5 ip authentication key-chain eigrp 200 EIGRP_AUTH ! ! interface Tunnel10 ip authentication mode eigrp 200 md5 ip authentication key-chain eigrp 200 EIGRP_AUTH

R3

key chain EIGRP_AUTH key 5 key-string CCNP ! ! !

interface fa0/1 ip authentication mode eigrp 200 md5 ip authentication key-chain eigrp 200 EIGRP_AUTH ! ! interface Tunnel10 ip authentication mode eigrp 200 md5 ip authentication key-chain eigrp 200 EIGRP_AUTH

R4

key chain EIGRP_AUTH key 5 key-string CCNP ! ! ! interface fa0/1 ip authentication mode eigrp 200 md5 ip authentication key-chain eigrp 200 EIGRP_AUTH

R5

key chain EIGRP_AUTH key 5 key-string CCNP

! ! ! interface fa0/1 ip authentication mode eigrp 200 md5 ip authentication key-chain eigrp 200 EIGRP_AUTH

It is highly encouraged to experiment with EIGRP authentication keys. Change the key numbers on one side to see the results. Console messages should be sent stating that there is an authentication failure. Furthermore, if you are not getting the console messages, you can run debug eigrp packets to help with the troubleshooting process. I would also encourage the use of other debugs. It makes learning easier if the engineer can see what's happening behind the scenes. Don't forget to configure EIGRP authentication on the tunnel interfaces.

EIGRP Summarization The summary requirement in this section is to summarize the loopbacks of R5 to the most efficient subnet. The other requirement is that R2 should only install the summary route and the 3rd loopback of R5 into the IP routing table. R3 is receiving routes about R5, so the first thing we need to do is configure a summary address on the tunnel interface towards R2. To find the summary to use. Write out all of the subnets in binary and summarize the interesting octet. The interesting octet is the octet where the values are changing. In this example, the third octet is the interesting octet. Example 2.11 10110001.00000101.00000001 10110001.00000101.00000010 10110001.00000101.00000011 10110001.00000101.00000100 10110001.00000101.00000101

Now, from left to right, count the bits that all have the same values in common. All of the values that are equal have been put in bold type. The total number of bits in common are 21. So the summary route will be 177.5.0.0 255.255.248.0 or 177.5.0.0/21. Refer to Example 2.12 for the interface

configuration and verification on R3 and R2. Example 2.12 R3

interface tunnel10 ip summary-address eigrp 200 177.5.0.0 255.255.248.0

show ip route 177.5.0.0/16 is variably subnetted, 6 subnets, 2 masks D

177.5.4.0/24 [90/297398016] via 100.1.1.1, 00:14:02, Tunnel10

D

177.5.5.0/24 [90/297398016] via 100.1.1.1, 00:14:01, Tunnel10

D

177.5.0.0/21 is a summary, 00:15:15, Null0

D

177.5.1.0/24 [90/297398016] via 100.1.1.1, 00:14:02, Tunnel10

D

177.5.2.0/24 [90/297398016] via 100.1.1.1, 00:14:02, Tunnel10

D

177.5.3.0/24 [90/297398016] via 100.1.1.1, 00:15:37, Tunnel10

R2

show ip route 177.5.0.0/16 is variably subnetted, 6 subnets, 2 masks D

177.5.4.0/24 [90/409600] via 10.1.25.5, 00:15:07, FastEthernet0/1

D

177.5.5.0/24 [90/409600] via 10.1.25.5, 00:15:07, FastEthernet0/1

D

177.5.0.0/21 [90/310198016] via 100.1.1.2, 00:15:06, Tunnel10

D

177.5.1.0/24 [90/409600] via 10.1.25.5, 00:15:07, FastEthernet0/1

D

177.5.2.0/24 [90/409600] via 10.1.25.5, 00:15:07, FastEthernet0/1

D

177.5.3.0/24 [90/409600] via 10.1.25.5, 00:16:42, FastEthernet0/1

In Example 2.12, notice that there is a summary route to Null0(The trash can or bit bucket) This

means that if the router does not find a more specific match for the route, then drop the traffic. Of course R3 will have the more specific routes since it is the source of summarization. The requirement was that R2 should only have the summary route and the 3rd loopback of R5 in the routing table. In Example 2.12, we can see that R2 is receiving the summary route, but it is also still receiving the more specific routes from R5. Notice that the 177.5.0.0 prefixes are being received on the FastEthernet0/1 interface of R2. Another summary route will have to be created on R5s FastEthernet0/1 interface towards R2. To get the 3rd loopback of R5to be installed as well as the summary route, an EIGRP leak map will have to be created so the loopback can be “leaked” to R2

To create a Leak Map you must: •Create and ACL defining the traffic to match •Create a route-map •Apply the leak map to the summary-address command Refer to Example 2.13 for the configuration and verification Example 2.13 R5

ip access-list standard EIGRP_LEAK permit 177.5.3.0 0.0.0.255 ! ! route-map LEAK_MAP permit 10 match ip address EIGRP_LEAK ! ! interface fa0/1 ip summary-address eigrp 200 177.5.0.0 255.255.248.0 leak-map LEAK_MAP

R2

R2#sh ip route eigrp 177.4.0.0/24 is subnetted, 5 subnets D

177.4.5.0 [90/297398016] via 100.1.1.2, 00:43:54, Tunnel10

D

177.4.4.0 [90/297398016] via 100.1.1.2, 00:43:54, Tunnel10

D

177.4.1.0 [90/297398016] via 100.1.1.2, 00:43:54, Tunnel10

D

177.4.3.0 [90/297398016] via 100.1.1.2, 00:43:54, Tunnel10

D

177.4.2.0 [90/297398016] via 100.1.1.2, 00:43:54, Tunnel10 177.5.0.0/16 is variably subnetted, 2 subnets, 2 masks

D

177.5.0.0/21 [90/409600] via 10.1.25.5, 00:00:52, FastEthernet0/1

D

177.5.3.0/24 [90/409600] via 10.1.25.5, 00:27:48, FastEthernet0/1 10.0.0.0/24 is subnetted, 7 subnets

D

10.1.34.0 [90/297270016] via 100.1.1.2, 00:43:54, Tunnel10

By the output of Example 2.13, we can see that R2 is now only receiving the summary route and the more specific loopback 3 interface of R5.

Redistribution Redistribution is of of those topics that can make even a seasoned engineer cringe. This typically occurs during corporate acquisitions and outsourced IT. •Route redistribution is the ability to take routes from one IGP and inject them into another IGP. If not carefully controlled, routing loops can form. Of of the things that are unique to each IGP is how the protocol calculates the metric. So taking EIGRPs metric, using bandwidth and delay in the metric calculation, and change it to OSPF cost and vice versa. •Another thing to consider when designing a redistribution strategy is administrative distance. Redistributing a protocol with a higher administrative distance into a protocol with a lower administrative distance will likely cause sub-optimal routing problems. •Only routes that are present in the routing table will be redistributed. •The connected interfaces are also redistributed. • Routing loops can't form if there is only one point of redistribution in the network. Concerns about routing loops occur when there are multiple points of redistribution in the network. •IOS allows the engineer to tag routes that are being redistributed. This makes route filtering more efficient when multiple points of redistribution are present. For the exercise, turn on debug ip routing on R1

The first few requirements can be fulfilled with just one route map. **Note** If you need to brush up on route maps, please see your text book or the Cisco documentation for more information. The details of route maps will not be covered in this exercise. It is assumed that the student has covered this material and is familiar with the concept of route maps in context with redistribution. Example 3.1 R2

ip access-list standard FILTER_177_5_1_1 permit 177.5.1.0 0.0.0.255 ip access-list standard METRIC_177_4_1_1 permit 177.4.1.0 0.0.0.255 ! ! ! ! route-map EIGRP_2_OSPF deny 10 match ip address FILTER_177_5_1_1 ! route-map EIGRP_2_OSPF permit 20 match ip address METRIC_177_4_1_1 set metric 1500 ! route-map EIGRP_2_OSPF permit 30 ! ! route-map OSPF_2_EIGRP permit 10 match source-protocol ospf 100

set tag 2110 ! ! router ospf 100 redistribute eigrp 200 subnets route-map EIGRP_2_OSPF tag 2170 ! ! router eigrp 200 redistribute ospf metric 1 1 1 1 1 route-map OSPF_2_EIGRP

Let's take a look at R2 configuration in Example 3.1. The first thing we need to do is define our access lists to classify the traffic we need to match on in our route map. The ACL does not permit or deny the traffic, it is simply a way to classify specific traffic that we will use later in the route-map. This is where the CCNP candidate will have to begin thinking about the different ways to use ACLs. The CCNA only told part of the story about ACLs. The next step is to create our route maps. Since the requirement asks for mutual redistribution and to set route tagging, we need to create 2 route-maps, one for OSPF and one for EIGRP. In the route map EIGRP_2_OSPF, the 1st stanza is saying that if we match the IP address in ACL FILTER_177_5_1_1, then do NOT redistribute. Remember we will use the route map's permit or deny action to tell the router whether or not it should be redistributing when a match is made. The 2nd stanza is saying that if the route map matches on the IP address in ACL METRIC_177_4_1_1, then set the metric for that route to 1500. The second route map is for EIGRP. That route map is saying that it will match on the source protocol. In our case, the source protocol is the one that we need to redistribute. That's OSPF. If the route map finds a match of the OSPF protocol, it will set the tag of 2110 as it's being redistributed into EIGRP. You can set the tag to anything you like. I like to use the format. Therefore, 2110 tells the engineer the route was redistributed on R2 and it was originally an OSPF route.(AD = 110) Again, you can use whatever tag you like. Use what makes sense to you. Earlier, you were asked to turn on debug ip routing on R1. Let's take a look at the output of R1 after the redistribution statement was entered. Example 3.2 R1

R1#debug ip routing

RT: is_up: Serial0/1 0 state: 4 sub state: 1 line: 0 has_route: False R1# RT: is_up: Serial0/1 0 state: 4 sub state: 1 line: 0 has_route: False RT: add 100.1.1.0/24 via 10.1.12.2, ospf metric [110/20] RT: NET-RED 100.1.1.0/24 RT: add 177.4.5.0/24 via 10.1.12.2, ospf metric [110/20] RT: NET-RED 177.4.5.0/24 RT: add 177.4.4.0/24 via 10.1.12.2, ospf metric [110/20] RT: NET-RED 177.4.4.0/24 RT: add 177.4.1.0/24 via 10.1.12.2, ospf metric [110/1500] RT: NET-RED 177.4.1.0/24 RT: add 177.4.3.0/24 via 10.1.12.2, ospf metric [110/20] RT: NET-RED 177.4.3.0/24 RT: add 177.4.2.0/24 via 10.1.12.2, ospf metric [110/20] RT: NET-RED 177.4.2.0/24 RT: add 177.5.4.0/24 via 10.1.12.2, ospf metric [110/20] RT: NET-RED 177.5.4.0/24 RT: R1#add 177.5.5.0/24 via 10.1.12.2, ospf metric [110/20] RT: NET-RED 177.5.5.0/24 RT: add 177.5.2.0/24 via 10.1.12.2, ospf metric [110/20] RT: NET-RED 177.5.2.0/24 RT: add 177.5.3.0/24 via 10.1.12.2, ospf metric [110/20] RT: NET-RED 177.5.3.0/24 RT: add 10.1.25.0/24 via 10.1.12.2, ospf metric [110/20] RT: NET-RED 10.1.25.0/24 RT: add 10.1.34.0/24 via 10.1.12.2, ospf metric [110/20]

RT: NET-RED 10.1.34.0/24

In Example 3.2, note that the 177.4.1.1 prefix now has a metric of 1500. Also, from the output in Example 3.2, note that the 177.5.1.1 prefix was NOT redistributed. To verify that the routes are getting tagged correctly, look at the EIGRP topology table. In our example, we will need to add the all-links keyword. By default, EIGRP will only display the links that it is presently using. To display all the links in the EIGRP topology, use the all-links keyword. Example 3.3 R5#sh ip eigrp topology all-links | inc 177.1 P 177.1.1.0/24, 0 successors, FD is Inaccessible, tag is 2110, serno 0 P 177.1.2.0/24, 0 successors, FD is Inaccessible, tag is 2110, serno 0 P 177.1.3.0/24, 0 successors, FD is Inaccessible, tag is 2110, serno 0 P 177.1.4.0/24, 0 successors, FD is Inaccessible, tag is 2110, serno 0 P 177.1.5.0/24, 0 successors, FD is Inaccessible, tag is 2110, serno 0

In Example 3.3, the tag is shown as 2110. The reason why the prefixes are showing as “Inaccessible” is because R5 is using the OSPF learned routes because they have a lower administrative distance than external EIGRP learned routes. To see the tags on the OSPF routes, check the database for the E2 routes. When routes are redistributed into OSPF, the routes will show up as E2 (External Type 2) unless otherwise specified to use E1. Example 3.4 shows the output of the type 5 LSA 177.4.5.0 Example 3.4

R1#sh ip ospf database external 177.4.5.0

OSPF Router with ID (177.1.5.5) (Process ID 100)

Type-5 AS External Link States

Routing Bit Set on this LSA LS age: 765 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 177.4.5.0 (External Network Number )

Advertising Router: 177.2.5.5 LS Seq Number: 80000001 Checksum: 0x698C Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 2090

One last thing to cover in section is the different routes in the IP routing table. The CCNA only covered single area OSPF, so the “O” in the routing table should look familiar. However, there are two types that maybe you have not seen. These are “IA” and “E2”. (See Example 3.5) Example 3.5 R1#sh ip route ospf 100.0.0.0/24 is subnetted, 1 subnets O E2

100.1.1.0 [110/20] via 10.1.12.2, 00:20:53, FastEthernet1/0

177.2.0.0/24 is subnetted, 5 subnets O

177.2.3.0 [110/2] via 10.1.12.2, 01:39:05, FastEthernet1/0

O

177.2.2.0 [110/2] via 10.1.12.2, 01:39:05, FastEthernet1/0

O

177.2.1.0 [110/2] via 10.1.12.2, 01:39:05, FastEthernet1/0

O

177.2.5.0 [110/2] via 10.1.12.2, 01:39:05, FastEthernet1/0

O

177.2.4.0 [110/2] via 10.1.12.2, 01:39:05, FastEthernet1/0 177.3.0.0/24 is subnetted, 5 subnets

O

177.3.2.0 [110/65] via 10.1.123.3, 01:37:03, Serial0/0.123

O

177.3.3.0 [110/65] via 10.1.123.3, 01:37:03, Serial0/0.123

O

177.3.1.0 [110/65] via 10.1.123.3, 01:37:03, Serial0/0.123

O

177.3.4.0 [110/65] via 10.1.123.3, 01:37:03, Serial0/0.123

O

177.3.5.0 [110/65] via 10.1.123.3, 01:37:03, Serial0/0.123 177.4.0.0/24 is subnetted, 5 subnets

O E2

177.4.5.0 [110/20] via 10.1.12.2, 00:20:53, FastEthernet1/0

O E2

177.4.4.0 [110/20] via 10.1.12.2, 00:20:53, FastEthernet1/0

O E2

177.4.1.0 [110/1500] via 10.1.12.2, 00:20:53, FastEthernet1/0

O E2

177.4.3.0 [110/20] via 10.1.12.2, 00:20:53, FastEthernet1/0

O E2

177.4.2.0 [110/20] via 10.1.12.2, 00:20:53, FastEthernet1/0

177.5.0.0/24 is subnetted, 4 subnets O E2

177.5.4.0 [110/20] via 10.1.12.2, 00:20:53, FastEthernet1/0

O E2

177.5.5.0 [110/20] via 10.1.12.2, 00:20:53, FastEthernet1/0

O E2

177.5.2.0 [110/20] via 10.1.12.2, 00:20:56, FastEthernet1/0

O E2

177.5.3.0 [110/20] via 10.1.12.2, 00:20:56, FastEthernet1/0

177.6.0.0/24 is subnetted, 5 subnets O IA 177.6.5.0 [110/76] via 10.1.12.2, 01:35:16, FastEthernet1/0 O IA

177.6.4.0 [110/76] via 10.1.12.2, 01:35:15, FastEthernet1/0

O IA

177.6.3.0 [110/76] via 10.1.12.2, 01:35:15, FastEthernet1/0

O IA

177.6.2.0 [110/76] via 10.1.12.2, 01:35:15, FastEthernet1/0

O IA

177.6.1.0 [110/76] via 10.1.12.2, 01:35:15, FastEthernet1/0

10.0.0.0/24 is subnetted, 7 subnets O E2

10.1.25.0 [110/20] via 10.1.12.2, 00:20:56, FastEthernet1/0

O IA

10.1.24.0 [110/11] via 10.1.12.2, 01:39:08, FastEthernet1/0

O IA

10.1.46.0 [110/75] via 10.1.12.2, 01:35:26, FastEthernet1/0

O IA

10.1.35.0 [110/74] via 10.1.123.3, 01:37:07, Serial0/0.123

O E2

10.1.34.0 [110/20] via 10.1.12.2, 00:20:56, FastEthernet1/0

**Note** The following chart will outline the new OSPF route types.

Example 3.6 Route TypeLSA TypeOriginated ByO1All routers within an areaIA3ABRE1 & E25ASBR

Floating Static Routes Shut down the fastEthernet0/0 interface on R2. When the OSPF dead timer expires, you should notice that R4 will lose connectivity to R1 loopbacks. Please refer to Example 3.6 for the results using the TCL script. Example 3.5 R4#tclsh R4(tcl)#foreach address { +>(tcl)#177.1.1.1 +>(tcl)#177.1.2.2 +>(tcl)#177.1.3.3 +>(tcl)#177.1.4.4 +>(tcl)#177.1.5.5 +>(tcl)#177.2.1.1 +>(tcl)#177.2.2.2 +>(tcl)#177.2.3.3 +>(tcl)#177.2.4.4 +>(tcl)#177.2.5.5 +>(tcl)#177.3.1.1 +>(tcl)#177.3.2.2 +>(tcl)#177.3.3.3 +>(tcl)#177.3.4.4 +>(tcl)#177.3.5.5 +>(tcl)#177.5.1.1 +>(tcl)#177.5.2.2 +>(tcl)#177.5.3.3

+>(tcl)#177.5.4.4 +>(tcl)#177.5.5.5} {ping $address +>(tcl)#} Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.1.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.1.2.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.1.3.3, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.1.4.4, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.1.5.5, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.2.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.2.2.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.2.3.3, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.2.4.4, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.2.5.5, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.3.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.3.2.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.3.3.3, timeout is 2 seconds: .....

Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.3.4.4, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.3.5.5, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.5.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/40/48 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.5.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 24/30/40 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.5.3.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/33/52 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.5.4.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/31/52 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.5.5.5, timeout is 2 seconds:

!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/39/48 ms R4(tcl)#

By shutting down the fastEthernet0/0 interface on R2, we have lost connectivity to R1 loopback and other subnets. The reason is that we have lost the default route information that was being injected into OSPF. You might think that R4 would receive the 177.1.0.0 subnets by routing information that is being redistributed into EIGRP over the tunnel10 interface. The problem is when R3 receives the update over the GRE tunnel about the redistributed prefixes, it marks them as inaccessible and does not pass this information on to R4 over the fa0/1 interface because it has a better route via OSPF. One way to fix this problem is with a floating static route. A floating static route can be configured with a higher AD than the injected OSPF default route. This way when the default route is removed from the routing table on R4 via OSPF, it will install the default route with the higher AD towards R3. Refer to Example 3.6 for the addition of the floating static route and for the results of connectivity testing after the floating static route has been configured. Example 3.6 R4

Enter configuration commands, one per line. End with CNTL/Z. R4(config)#ip route 0.0.0.0 0.0.0.0 10.1.34.3 201

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

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/20/32 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.1.4.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/28 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.1.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/22/32 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.2.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/21/32 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 24/35/52 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.2.3.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/24/32 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.2.4.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/29/40 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.2.5.5, timeout is 2 seconds:

!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/24/48 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.3.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/20 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.3.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/7/20 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.3.3.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/12 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.3.4.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/11/16 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.3.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.5.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/25/40 ms Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 177.5.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/34/56 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.5.3.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/28/40 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.5.4.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/31/52 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 177.5.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/28/40 ms R4(tcl)#

External BGP eBGP neighbor relationships are usually formed on the physical links. But for the purposes of this lab the peering will use the loopback interfaces because that is one of the requirements. EBGP neighbor packets have a TTL of 1, so in order to peer using the loopback interfaces, the configuration will need to include the neighbor ebgp-multihop command to change this behavior. This command will allow the engineer to alter the number of hops the peering show use. Remember that BGP is a TCP application, so the neighbors don't need to be directly connected. But in the real world, eBGP peerings are normally done with the directly connected links. When BGP tries to form a neighbor relationship, it uses the IP address of the directly connected interface. The requirement is to form the neighbor relationship with the first loopback interfaces so the engineer needs to inform the other side that it is changing the source IP address information in the TCP packet. This is accomplished with the neighbor update-source command. **Hint** Newer versions of IOS will have summarization and synchronization disabled, but it may need to be manually disabled in older versions.

Example 5.1 R1

R1#sh run | sec bgp router bgp 100 no synchronization bgp log-neighbor-changes network 177.1.5.0 mask 255.255.255.0 neighbor 177.7.1.1 remote-as 700 neighbor 177.7.1.1 ebgp-multihop 2 neighbor 177.7.1.1 update-source Loopback1 no auto-summary

R7

router bgp 700 no synchronization bgp log-neighbor-changes neighbor 177.1.1.1 remote-as 100 neighbor 177.1.1.1 ebgp-multihop 2 neighbor 177.1.1.1 update-source Loopback1 neighbor 177.1.1.1 default-originate no auto-summary

**Hint** The output of the debug bgp ipv4 unicast command reveals the following BGP state information as the BPG neighbor relationship forms. Example 5.2

BGP: 177.1.1.1 went from Idle to Active BGP: 177.1.1.1 open active, local address 177.7.1.1 BGP: 177.1.1.1 went from Active to OpenSent BGP: 177.1.1.1 sending OPEN, version 4, my as: 700, holdtime 180 seconds BGP: 177.1.1.1 send message type 1, length (incl. header) 45 BGP: 177.1.1.1 rcv message type 1, length (excl. header) 26 BGP: 177.1.1.1 rcv OPEN, version 4, holdtime 180 seconds BGP: 177.1.1.1 rcv OPEN w/ OPTION parameter len: 16 BGP: 177.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6 BGP: 177.1.1.1 OPEN has CAPABILITY code: 1, length 4 BGP: 177.1.1.1 OPEN has MP_EXT CAP for afi/safi: 1/1 BGP: 177.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2 BGP: 177.1.1.1 OPEN has CAPABILITY code: 128, length 0 BGP: 177.1.1.1 OPEN has ROUTE-REFRESH capability(old) for all address-families BGP: 177.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2 BGP: 177.1.1.1 OPEN has CAPABILITY code: 2, length 0 BGP: 177.1.1.1 OPEN has ROUTER7(config-router)#REFRESH capability(new) for all address-families BGP: 177.1.1.1 rcvd OPEN w/ remote AS 100 BGP: 177.1.1.1 went from OpenSent to OpenConfirm BGP: 177.1.1.1 went from OpenConfirm to Established