TS BSCI Labbook

8/6/2019 TS BSCI Labbook

1/68

Cisco Certified Network Professional

Video CBT

LAB SERIES

Building Scalable Cisco Internetworks (BSCI)

CCNP Study Package

Video CBT Lab 23

Advanced IP Addressing and Routing


2/68

Advanced IP Addressing and Routing

Cisco CCNP (BSCI)

Fast Track CBT Video Lab 23

Part 1 of 4 in the Cisco CCNP Series


3/68


4/68

About the Authors

Chris Bryant (CCIE #12933) has extensive experience in both the practical and theoreticalsides of Cisco technologies. He is the owner of The Bryant Advantage(www.thebryantadvantage.com), a unique training organization that specializes in helping

CCNA and CCNP candidates earn their certifications while developing the hands-on skillsthe market demands. His nine years of IT experience and enthusiastic teaching style enableshim to offer Cisco training that is both unique and highly effective. When you finish Chris'Cisco Certified Network Professional Study Package you will know Cisco at a "differentlevel!"

Train Signal, Inc.400 West Dundee RoadSuite #106Buffalo Grove, IL 60089Phone - (847) 229-8780

Fax (847) 229-8760www.trainsignal.com

Copyright and other Intellectual Property Information Train Signal, Inc., 2002 - 2006. All rights are reserved. No part of this publication,including written work, videos, and on-screen demonstrations (together called theInformation or THE INFORMATION), may not be reproduced or distributed in anyform or by any means without the prior written permission of the copyright holder.

Products and company names, including but not limited to, Microsoft, Novell and Cisco, arethe trademarks, registered trademarks, and service marks of their respective owners.


5/68

Disclaimer and Limitation of LiabilityAlthough the publishers and authors of the Information have made every effort to ensurethat the information within it was correct at the time of publication, the publishers and theauthors do not assume and hereby disclaim any liability to any party for any loss or damagecaused by errors, omissions, or misleading information.

TRAINSIGNAL,INC.PROVIDESTHEINFORMATION"AS-IS." NEITHER TRAIN

SIGNAL, INC. NOR ANY OF ITS SUPPLIERS MAKES ANY WARRANTY OF ANY

KIND, EXPRESS OR IMPLIED. TRAIN SIGNAL, INC. AND ITS SUPPLIERS

SPECIFICALLY DISCLAIM THE IMPLIED WARRANTIES OF TITLE, NON-

INFRINGEMENT, MERCHANTABILITY, AND FITNESS FOR A PARTICULAR

PURPOSE. THERE IS NO WARRANTY OR GUARANTEE THAT THE OPERATION

OF THE INFORMATION WILL BE UNINTERRUPTED, ERROR-FREE, OR VIRUS-

FREE, OR THAT THE INFORMATION WILL MEET ANY PARTICULAR

CRITERIA OF PERFORMANCE OR QUALITY. YOU ASSUME THE ENTIRE RISK

OF SELECTION, INSTALLATION, AND USE OF THE INFORMATION.

IN NO EVENT AND UNDER NO LEGAL THEORY, INCLUDING WITHOUT

LIMITATION, TORT, CONTRACT, OR STRICT PRODUCTS LIABILITY, SHALL

TRAIN SIGNAL, INC. OR ANY OF ITS SUPPLIERS BE LIABLE TO YOU OR ANY

OTHER PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR

CONSEQUENTIAL DAMAGES OF ANY KIND, INCLUDING WITHOUT

LIMITATION, DAMAGES FOR LOSS OF GOODWILL, WORK STOPPAGE,

COMPUTER MALFUNCTION, OR ANY OTHER KIND OF DAMAGE, EVEN IF

TRAIN SIGNAL, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH

DAMAGES. IN NO EVENT SHALL TRAIN SIGNAL, INC. BE LIABLE FOR

DAMAGES IN EXCESS OF TRAIN SIGNAL, INC.'S LIST PRICE FOR THE

INFORMATION.

To the extent that this Limitation is inconsistent with the locality where you use theSoftware, the Limitation shall be deemed to be modified consistent with such local law.

Choice of Law:

You agree that any and all claims, suits, or other disputes arising from your use of theInformation shall be determined in accordance with the laws of the State of Illinois, in theevent Train Signal, Inc. is made a party thereto. You agree to submit to the jurisdiction ofthe state and federal courts in Cook County, Illinois for all actions, whether in contract or intort, arising from your use or purchase of the Information.


6/68

Welcome to The Bryant Advantages BSCI Lab Workbook!

This lab book has been created by Chris Bryant of The Bryant Advantage for

supplemental use with Train Signals Lab 23 Cisco CCNP (BSCI) video training. Used

in combination with your own personal Cisco Network or a Cisco Rack Rentals, this

book will help you master all the skills youll need to pass the BSCI exam and give you a

solid foundation for your future Cisco studies. Please reference the Video 20 Home

Primer Lab video on CD 2 for details about the setup of the lab.

The best way to learn about Cisco technologies is to use them. Youve got to read to

learn the theory, but its vital to see the theory in action. You can adapt these labs to run

on your own home lab, or rent one of my CCNP racks that are designed to run these labs

and help you build the skill level needed to become a CCNP and a world-class network

engineer. I invite you to visit the Rack Rentals section of my website,

www.thebryantadvantage.com, to learn how easy and affordable rack rental time is!


7/68

The Bryant Advantages Rack Rental Rule:

Please Read The Following Rules Carefully. Theyre Not the Usual mumbo jumbo Legalities.

By connecting to The Bryant Advantages remote labs, you agree to abide by the following rules.

1. Do not change the configuration of the access server in any way.

Doing so may end your session, and a refund will not be given. Youw ill also be prohibited from renting the pods in the future.

2. Do not change the configuration register of any router or switch.

3. You are more than w elcome to practice your enable secret, enablepassword, console password, and telnet passwords. However, you

MUST use the passwords cisco or ccna, without the quotationmarks. Upper case or lower case is fine.

Thank you!

The best way to learn about Cisco technologies is to use them. Youve got to read tolearn the theory, but its vital to see the theory in action. With that in mind, lets

take a look at the network topology youll use in this lab workbook.


8/68

Netw ork Topology and Layer 2 Configuration

While Frame Relay and directly connected serial interfaces are not part of the BSCI

exam, you've got to have Layer 2 running before you can configure Layer 3!

The following physical network topology is used for all labs in this workbook.

Not all routers and interfaces are used in every lab, so read the network setup for

each section carefully. The BGP lab does have you close and open certain interfacesas the lab progresses in order to give you the maximum experience with as many

BGP attributes and features as possible.

If you are running these labs on your own home lab and need a frame relay switch

configuration, visit my website's "Home Lab Help" section for a sample configuration.

The networks used during the labs:

Frame Cloud network: 172.12.123.0 /24

Ethernet segment: 172.12.23.0 /24

Directly Connected Serial Interfaces (R3 - R4): 10.2.2.0 /24.

The last octet of each address should be the router's number. For example, on R1

the Serial0 interface will be 172.12.123.1 /24.


9/68

PLEASE NOTE - R4 is also serving as your network's frame relay switch. If you

delete the configuration of this device, you'll have to paste it back (which is easy

enough, copy and paste it from my website's Home Lab Help section) or the labs willnot work correctly. You can't have Layer 3 without Layer 2!

Before beginning these labs, make sure to have the frame cloud up and running and

IP connectivity present between the three endpoints. If you are running these labson my pods, the switch ports are all in VLAN 1 and a trunk is already presentbetween the two switches. Since no configuration is needed on the switches and

there is no switch configuration tested in the BSCI exam, the switches are not shownin the network diagram. R4 is your Frame Relay switch and is pre-configured as

such, but you must configure frame map statements on R1, R2, and R3.

All you need to do at Layer 2 is configure frame map statements on R1, R2, and R3.

DLCI assignments are as follows:

R1, the hub, uses DLCI 122 to reach R2 and DLCI 123 to reach R3.

R2 uses DLCI 221 to reach both R1 and R2.

R3 uses DLCI 321 to reach both R1 and R2.

Physical Setup:

R1:

Serial0 is connected to R4's Serial1 (Frame Relay Switching)

R2:


Ethernet0 is connected to Switch1, port 0/2

R3:


Serial1 is connected to R4's Serial0 (Used For Routing)

Ethernet0 is connected to Switch1, port 0/3

R4 (Frame Relay Switch):

Serial0 is connected to R3's Serial 1 (Used For Routing)




Ethernet0 is connected to Switch1, port 0/4.


10/68

No additional configuration is needed on the switches. They are already trunking

and all ports are in VLAN 1.

Connecting To Your Remote Pod

Getting started with your pod of Cisco routers and 2950 switches is easy! First,youll need to Telnet to your access server. The IP address, username, and

password for your session was sent to you in a separate email. (The phonenumbers for your ISDN connection is also in that email.)

You can use any Telnet version to connect to your access server. You can useHyperTerminal if you like, but Ive seen some versions have trouble with Telnet. If

you use HyperTerminal and have trouble authenticating, use Telnet by going out toyour C: prompt.

From your C: prompt, you can type telnet to go into Microsoft telnet, or typetelnet x.x.x.x, with the IP address in place of the xs.

C:\ > telnet

Welcome to Microsoft Telnet Client

Escape Character is 'CTRL+]'

Microsoft Telnet> open 100.100.100.100 (put the IP address you were sent

in email in place of the 100.100.100.100)

User Access Verification

Username:

Password:

OR:

C:\>telnet 100.100.100.100


Username:

Password:

A few tips for logging in:

1. You will be prompted for a password.2. Do not hit the space bar at the end of entering either; this will send a null

space and you will not be authenticated.3. The cursor WILL NOT MOVE w hen you enter your username and

password. Thats a Cisco default. You will not see asterisks, as you dowhen logging in to most Microsoft products.


11/68

After entering your username and password, youll be put into privileged exec modeon the access server:


Password:

BRYANT_POD_ONE#

Your four routers and two Cisco 2950 switches are all connected to this accessserver. Heres how to access each device.

First, clear the lines leading to the other devices.

BRYANT_POD_ONE#clear line 01

[confirm][OK]BRYANT_POD_ONE#clear line 02

[confirm][OK]

BRYANT_POD_ONE#clear line 03[confirm]

[OK]


[OK]BRYANT_POD_ONE#clear line 05

[confirm][OK]


[OK]

When you see the [confirm] choice, just hit your enter key to accept it.

Now that the lines are cleared, youre going to connect to each device from your

access server. This reads like a long process, but it will only take you a minute ortwo.

Type R1 at the prompt:

BRYANT_POD_ONE#r1

Trying R1 (100.1.1.1, 2001)... Open

R1#

Note: When you see the word Open, hit the Enter key again. Youll then see the

prompt for R1.


12/68

Now, you need to learn the big keystroke that youll be using to go back from the

access server. Here it is:

< X>

This keystroke is a little awkward at first, but before long youll be doing it withoutthinking about it. You hit ctrl-shift-6 the same way youd enter ctrl-alt-delete (we all

know that one!), then release those keys and hit x. Then youre right back at the

access server. Repeat the process for R2, R3, SW1, and SW2.

R1# < Use above keystroke to go back to access server >BRYANT_POD_ONE#r2

Trying R2 (100.1.1.1, 2002)... Open

R2# < Use above keystroke to go back to access server >

BRYANT_POD_ONE#r3Trying R3 (100.1.1.1, 2003)... Open

R2# < Use above keystroke to go back to access server >BRYANT_POD_ONE#r4Trying R3 (100.1.1.1, 2003)... Open

R3# < Use above keystroke to go back to access server >BRYANT_POD_ONE#sw1

Trying SW1 (100.1.1.1, 2004)... Open

sw1# < Use above keystroke to go back to access server >BRYANT_POD_ONE#sw2

Trying SW2 (100.1.1.1, 2005)... Open

sw2# < Use above keystroke to go back to access server >BRYANT_POD_ONE#

Remember, youre always coming back to the access server to get from one routerto another. Before long, youll be using that keystroke without even thinking about

it.

Now that youve created those connections, you will use only the number of the

connection to go back to each device. At the access server, just type these numbersto get to each device:

1: R1

2: R2

3: R34: R4

5: SW16: SW2


13/68

Dont type the entire name of the device again; just type the numbers you see here

on the access server, as shown below.

BRYANT_POD_ONE#1

[Resuming connection 1 to r1 ... ]

R1#BRYANT_POD_ONE#2


R2#

BRYANT_POD_ONE#3[Resuming connection 3 to r3 ... ]

R2#

BRYANT_POD_ONE#3


R3#

BRYANT_POD_ONE#4[Resuming connection 5 to sw1 ... ]

sw1#

BRYANT_POD_ONE#5[Resuming connection 6 to sw2 ... ]

sw2#

BRYANT_POD_ONE#

Dont forget to hit enter again after you see the resuming connection message.

That will get you to the enable prompt.

Thats all there is to it!And a final word to the wise -

I know you mastered static routing, RIP, and EIGRP in the CCNA curriculum. Don't

skip these in your BSCI prep, especially EIGRP. The EIGRP material on your BSCIexam goes into a lot more detail than your CCNA exam did. (And besides, we want

to make sure the RIP and static routing questions are easy points for you!)

Let ' s ge t s t a r t ed !

To your success,

Chris Bryant

CCIE #12933

[email protected]


14/68

Static Routing

Before starting this lab, make sure R1, R2, and R3 can ping each other's serial

interfaces over the frame cloud. R2 and R3 should also be able to ping the ethernet

interface of the other router. Each of those routers should have a single loopbackaddress that uses its router number for each octet; 1.1.1.1, etc. R4 will not be used

in this lab.

Static routes are second nature to you as a CCNA, but let's review them and point

out a few details that you might not have known.

First, on R3, run debug ip packet and ping 2.2.2.2.

R3#debug ip packet

IP packet debugging is on

R3#ping 2.2.2.2

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

1w0d: IP: s=3.3.3.3 (local), d=2.2.2.2, len 100, unroutable.1w0d: IP: s=3.3.3.3 (local), d=2.2.2.2, len 100, unroutable.

1w0d: IP: s=3.3.3.3 (local), d=2.2.2.2, len 100, unroutable.1w0d: IP: s=3.3.3.3 (local), d=2.2.2.2, len 100, unroutable.

1w0d: IP: s=3.3.3.3 (local), d=2.2.2.2, len 100, unroutable.

You knew we wouldn't be able to ping 2.2.2.2, and this debug shows us why. The

packets are unroutable, because there is no entry in the routing table that matches

this destination.

R3#show ip routeCodes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - 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, ia - IS-IS inter area* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

3.0.0.0/32 is subnetted, 1 subnets

C 3.3.3.3 is directly connected, Loopback0172.12.0.0/24 is subnetted, 2 subnets

C 172.12.23.0 is directly connected, Ethernet0

C 172.12.123.0 is directly connected, Serial0


15/68

Configure a host route to R2's loopback on R3, using R1's serial0 ip address as a

next-hop IP address. With the debug still running, send a ping. Then turn the debugoff and send the ping again so you can more clearly see the ping result.

R3#ping 2.2.2.2

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

U

1w0d: IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending1w0d: IP: s=172.12.123.1 (Serial0), d=172.12.123.3 (Serial0), len 56, rcvd 3

1w0d: IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending1w0d: IP: s=172.12.123.1 (Serial0), d=172.12.123.3, len 44, rcvd 0

1w0d: IP: s=172.12.123.3 (local), d=172.12.123.1 (Serial0), len 40, sending.U1w0d: IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending

1w0d: IP: s=172.12.123.1 (Serial0), d=172.12.123.3 (Serial0), len 56, rcvd 31w0d: IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending.U

Success rate is 0 percent (0/5)

R3#1w0d: IP: s=172.12.123.3 (local), d=2.2.2.2 (Serial0), len 100, sending

1w0d: IP: s=172.12.123.1 (Serial0), d=172.12.123.3 (Serial0), len 56, rcvd 3

R3#undebug allAll possible debugging has been turned off

R3#ping 2.2.2.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:U.U.U

Success rate is 0 percent (0/5)

Generally, a ping will return five of the same character. When you see this unusualoutput, there is a problem with routing on a downstream router. When the debugwas running, you saw that the packets were being sent, so R3 considers them

routable. This is because there's a match in the routing table for this destination - astatic route.



E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGPi - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter ar

* - candidate default, U - per-user static route, o - ODR



16/68


2.0.0.0/32 is subnetted, 1 subnetsS 2.2.2.2 [1/0] via 172.12.123.1

3.0.0.0/32 is subnetted, 1 subnetsC 3.3.3.3 is directly connected, Loopback0

172.12.0.0/24 is subnetted, 2 subnetsC 172.12.23.0 is directly connected, Ethernet0C 172.12.123.0 is directly connected, Serial0

The problem is that R1 does not have a route to 2.2.2.2, so when R1 receives a

packet destined for that network, there is no match in the routing table and the

packet is dropped. By placing a static route on R1 for the destination 2.2.2.2, R1 willbe able to route packets to that address.

R1(config)#ip route 2.2.2.2 255.255.255.255 172.12.123.2

Pings now go through to 2.2.2.2 from R3.

R3#ping 2.2.2.2


Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 132/136/148 ms

Remove the static route from R3.

R3(config)#no ip route 2.2.2.2 255.255.255.255 172.12.123.1

For a static default route, simply use the ip route command with all zeroes for both

the destination and the mask. As with regular static routes, the end of the command

can specify either a next-hop IP address OR a local exit interface. Configure a

default static route on R3 using R1's serial0 IP address as the next-hop and ping R2'sloopback.

R3(config)#ip route 0.0.0.0 0.0.0.0 172.12.123.1

R3#ping 2.2.2.2


Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 132/132/136 ms

Run show ip route static.

R3#show ip route static

S* 0.0.0.0/0 [1/0] via 172.12.123.1

The asterisk indicates a candidate default route. Note that the administrative

distance is 1 (the first number in the brackets is the AD, the second is the route's

metric).


17/68

A static route, default or not, can also reference the local router's exit interface

instead of a downstream next-hop IP address. Configure a default static route that

uses R3's ethernet0 as the exit interface and ping 2.2.2.2.

R3(config)#ip route 0.0.0.0 0.0.0.0 ethernet0

R3#ping 2.2.2.2


Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

No surprise there - but now run show ip route static on R3 again, followed by show ip

route.

R3#show ip route static

S* 0.0.0.0/0 is directly connected, Ethernet0



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, ia - IS-IS inter area* - candidate default, U - per-user static route, o - ODR


Gateway of last resort is 0.0.0.0 to network 0.0.0.0


C 3.3.3.3 is directly connected, Loopback0

172.12.0.0/24 is subnetted, 2 subnetsC 172.12.23.0 is directly connected, Ethernet0C 172.12.123.0 is directly connected, Serial0

S* 0.0.0.0/0 is directly connected, Ethernet0

The default static route is now seen as "directly connected" in the output of both

commands. When a router's local exit interface is referenced in the ip routecommand rather than the next-hop IP address, it's considered a directly connected

route and has an administrative distance of zero.


18/68

RIP Versions 1 And 2

The RIP lab will use R1, R2, and R3. You should have the frame-relay connections

between the three up and running, and create a loopback on each router using the

router number for each octet. Use a 32-bit mask on all loopback interfaces.

Enable RIP on both the Serial and loopback interfaces.

R1(config)#router ripR1(config-router)#network172.12.0.0R1(config-router)#network 1.0.0.0

R2(config)#router ripR2(config-router)#network 172.12.0.0R2(config-router)#network 2.0.0.0

R3(config)#router ripR3(config-router)#network 172.12.0.0R3(config-router)#network 3.0.0.0

R1 now sees the loopbacks of R2 and R3. The network 172.12.0.0 does not show up in the RIProuting table because it is a directly connected route.

R1#show ip route ripR 2.0.0.0/8 [120/1] via 172.12.123.2, 00:00:01, Serial0R 3.0.0.0/8 [120/1] via 172.12.123.3, 00:00:26, Serial0

You know that RIP has two different versions, but do you remember what the default version is,and how to view it?

R1#show ip protocolsRouting Protocol is "rip"Sending updates every 30 seconds, next due in 3 secondsInvalid after 180 seconds, hold down 180, flushed after 240Outgoing update filter list for all interfaces is not setIncoming update filter list for all interfaces is not setRedistributing: ripDefault version control: send version 1, receive any version

Interface Send Recv Triggered RIP Key-chainLoopback0 1 1 2Serial0 1 1 2

Automatic network summarization is in effectMaximum path: 4Routing for Networks:1.0.0.0172.12.0.0

Routing Information Sources:

Gateway Distance Last Update172.12.123.3 120 00:00:18172.12.123.2 120 00:00:22

Distance: (default is 120)

Our old friend show ip protocolsshows a lot of information, and that includes the versiondefaults. By default, RIP sends version 1 updates and receives both version 1 and version 2updates. Right now, all three routers are sending only version 1 updates, and one of thelimitations with version 1 is that there is no VLSM support. Let's revisit the RIP routing table:


19/68

R1#show ip route ripR 2.0.0.0/8 [120/1] via 172.12.123.2, 00:00:01, Serial0R 3.0.0.0/8 [120/1] via 172.12.123.3, 00:00:26, Serial0

The routes have 8-bit masks set. That is the classful mask for a Class A network. To see the full32-bit mask, we'll have to use RIP version 2.

There is another limitation that is not yet evident. We're going to configure authentication for theRIP routing updates, and version 1 does not allow us to do this. To hardcode RIP to send andreceive version 2 updates only, use the version 2command under the RIP process.

First, configure this command on R1 and R2 only. Make sure to clear your routing tables afterconfiguring this command. We'll also need to run the no auto-summarycommand to prevent RIPfrom summarizing the loopback network address as it crosses a network boundary.

R1(config)#router ripR1(config-router)#version 2R1(config-router)#no auto-summary

R1#clear ip route *

R2(config)#router ripR2(config-router)#version 2

R2#clear ip route *

Let's take a look at the RIP routing tables on R1 and R2.

R1#show ip route rip2.0.0.0/32 is subnetted, 1 subnets

R 2.2.2.2 [120/1] via 172.12.123.2, 00:00:04, Serial0

R2#show ip route rip1.0.0.0/32 is subnetted, 1 subnetsR 1.1.1.1 [120/1] via 172.12.123.1, 00:00:01, Serial0

There are two important differences evident after R1 and R2 are changed to RIP version 2. Thefull subnet mask of /32 is now seen, since RIPv2 supports VLSM. We've also lost the route toR3's loopback. That's because R3 is sending out RIPv1 updates, which neither R2 nor R1 aregoing to accept.

That's great to know, but how can we see this? Any RIP-related issue is going to be quicklyspotted by those who know to run the command debug ip rip. Let's run it on R1 and clear therouting table afterward to speed up the troubleshooting process.

R1#debug ip rip

RIP protocol debugging is onR1#clear ip route *

R1#undebug all (You could also use no debug ip riphere as well.)

5d02h: RIP: ignored v1 packet from 172.12.123.3 (illegal version)


20/68

"Illegal version" simply means that a packet is being received from 172.12.123.3 that the localrouter is not allowed to accept. This can actually be changed on the interface level as well asunder the RIP process. Here is how you would configure R1's S0 interface to send and acceptR2 updates only:

R1(config)#int s0

R1(config-if)#ip rip send version 2R1(config-if)#ip rip receive version 2

Knowing that can come in handy, but generally you're going to configure the RIP version for theprotocol as a whole. On R3, we'll now hardcode the RIP process for version 2 and then clear therouting tables.

R3(config)#router ripR3(config-router)#version 2R3(config-router)#no auto-summary

R3#clear ip route *

R3 now has a full RIP routing table, as do R1 and R2.


R 1.1.1.1 [120/1] via 172.12.123.1, 00:00:24, Serial02.0.0.0/32 is subnetted, 1 subnets

R 2.2.2.2 [120/2] via 172.12.123.2, 00:00:24, Serial0


R 2.2.2.2 [120/1] via 172.12.123.2, 00:00:23, Serial03.0.0.0/32 is subnetted, 1 subnets

R 3.3.3.3 [120/1] via 172.12.123.3, 00:00:12, Serial0

R2#show ip route rip

1.0.0.0/32 is subnetted, 1 subnetsR 1.1.1.1 [120/1] via 172.12.123.1, 00:00:14, Serial0


The other major BSCI topic dealing with RIP is link authentication. You can actually configureauthentication for the routing updates themselves, and we've got two options - MD5 (hashed) andclear-text. We're going to configure both. Before continuing, configure an address from the172.12.23.0 /24 subnet onto the ethernet interfaces of R2 and R3. Make sure they can ping eachother.

R2(config)#int e0R2(config-if)#ip address 172.12.23.2 255.255.255.0

R2(config-if)#no shut

R3(config)#int e0R3(config-if)#ip address 172.12.23.3 255.255.255.0R3(config-if)#no shut

We'll now configure MD5 authentication for the RIP updates transmitted over the serial cloud.This configuration does take a little getting used to, so get a lot of practice!


21/68

On R1, create a key chain called RIP, and assign key 1 a key-string of CISCO. (Multiple keystrings can be created and applied according to different criteria such as time of day, the month,etc. That's a skill you'll learn in your CCIE studies.)

R1(config)#key chain RIPR1(config-keychain)#key 1R1(config-keychain-key)#key-string CISCO

Now we'll apply this key chain to the S0 interface on R1. This requires two commands, shownbelow. Immediately after configuring these commands, run debug ip rip.

R1(config)#interface s0R1(config-if)#ip rip authentication mode md5R1(config-if)#ip rip authentication key-chain RIP

R1#debug ip ripRIP protocol debugging is on5d03h: RIP: ignored v2 packet from 172.12.123.3 (invalid authentication)5d03h: RIP: ignored v2 packet from 172.12.123.2 (invalid authentication)

The version 2 updates from R2 and R3 are being ignored, because they are not authenticating.You'll see this message when the remote router is sending unauthenticated messages, theauthentication mode being used is a mismatch (both sides have to use the same method, md5 orclear text), or the password is incorrect.

Let's go to R2 and R3 and configure their s0 interfaces for md5 authentication.

R2(config)#key chain RIPR2(config-keychain)#key 1R2(config-keychain-key)#key-string CISCOR2(config-keychain-key)#interface serial0R2(config-if)#ip rip authentication mode md5R2(config-if)#ip rip authentication key-chain RIP

R3(config)#key chain RIPR3(config-keychain)#key 1R3(config-keychain-key)#key-string ciscoR3(config-keychain-key)#interface serial0R3(config-if)#ip rip authentication mode md5R3(config-if)#ip rip authentication key-chain RIP

On R1, run debug ip ripto ensure that authentication has been correctly configured.

R1#debug ip ripRIP protocol debugging is onR1#clear ip route *

5d03h: RIP: received packet with MD5 authentication

5d03h: RIP: received v2 update from 172.12.123.2 on Serial05d03h: 2.2.2.2/32 via 0.0.0.0 in 1 hops5d03h: 3.3.3.3/32 via 0.0.0.0 in 2 hops5d03h: 172.12.23.0/24 via 0.0.0.0 in 1 hops5d03h: 172.12.123.0/24 via 0.0.0.0 in 1 hops

5d03h: RIP: received packet with MD5 authentication5d03h: RIP: ignored v2 packet from 172.12.123.3 (invalid authentication)


22/68

The packet from R2 authenticated properly, but the packet from R3 has invalid authentication.What did we do wrong?

You're going to see a very common error with link authentication right now - these passwords arecase-sensitive. Take a look at the passwords we set on R2 and R3 in the key chains.

R2(config)#key chain RIP

R2(config-keychain)#key 1R2(config-keychain-key)#key-string CISCO

R3(config)#key chain RIPR3(config-keychain)#key 1R3(config-keychain-key)#key-string cisco

R3's password of cisco is in lower-case. Removing that lower-case password and setting theproper password of CISCO will allow R3's routing updates to authenticate properly.

R3(config)#key chain RIPR3(config-keychain)#key 1R3(config-keychain-key)#no key-string cisco

R3(config)#key chain RIPR3(config-keychain)#key 1R3(config-keychain-key)#key-string CISCO

5d03h: RIP: received packet with MD5 authentication5d03h: RIP: received v2 update from 172.12.123.3 on Serial05d03h: 2.2.2.2/32 via 0.0.0.0 in 2 hops5d03h: 3.3.3.3/32 via 0.0.0.0 in 1 hops5d03h: 172.12.23.0/24 via 0.0.0.0 in 1 hops5d03h: 172.12.123.0/24 via 0.0.0.0 in 1 hops


23/68

The packets from R3 are now authenticating properly, and R1 now has a full RIP routing tableagain.


R 2.2.2.2 [120/1] via 172.12.123.2, 00:00:05, Serial0



[120/1] via 172.12.123.2, 00:00:05, Serial0

The links you're running RIP update authentication on is seen with - what else? - show ipprotocols.

R1#show ip protocolsRouting Protocol is "rip"Sending updates every 30 seconds, next due in 20 secondsInvalid after 180 seconds, hold down 180, flushed after 240Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not setRedistributing: ripDefault version control: send version 2, receive version 2

Interface Send Recv Triggered RIP Key-chainLoopback0 2 2Serial0 2 2 RIP

Automatic network summarization is not in effectMaximum path: 4Routing for Networks:1.0.0.0172.12.0.0

Routing Information Sources:Gateway Distance Last Update

172.12.123.3 120 00:00:23172.12.123.2 120 00:00:07

Distance: (default is 120)

You can also see that RIP is performing equal-cost load-sharing on R1, since R1 has two equal-cost paths to the network 172.12.23.0 /24.


24/68

We'll now configure clear-text authentication on the ethernet segment connecting R2 and R3. Aseparate key chain will be created, and the only difference in the entire configuration betweenclear-text and MD5 is that clear-text is specified in one of the interface commands.

R2(config)#key chain ETHERNETR2(config-keychain)#key 1

R2(config-keychain-key)#key-string CCNPR2(config-keychain-key)#interface ethernet0R2(config-if)#ip rip authentication mode ?md5 Keyed message digesttext Clear text authentication

R2(config-if)#ip rip authentication mode textR2(config-if)#ip rip authentication key-chain ETHERNET

R3(config)#key chain ETHERNETR3(config-keychain)#key 1R3(config-keychain-key)#key-string CCNPR3(config-keychain-key)#interface ethernet0R3(config-if)#ip rip authentication mode text

R3(config-if)#ip rip authentication key-chain ETHERNET

Run debug ip rip on R2 to ensure that routing updates are being properly received from R1 andR3.

5d03h: RIP: received packet with MD5 authentication5d03h: RIP: received v2 update from 172.12.123.1 on Serial05d03h: 1.1.1.1/32 via 0.0.0.0 in 1 hops5d03h: 3.3.3.3/32 via 172.12.123.3 in 2 hops5d03h: 172.12.123.0/24 via 0.0.0.0 in 1 hops

5d03h: RIP: received packet with text authentication CCNP5d03h: RIP: received v2 update from 172.12.23.3 on Ethernet0

5d03h: 1.1.1.1/32 via 0.0.0.0 in 2 hops5d03h: 3.3.3.3/32 via 0.0.0.0 in 1 hops5d03h: 172.12.123.0/24 via 0.0.0.0 in 1 hops

Notice that the password "CCNP" is clearly seen with the debug when clear-text authentication isused.


25/68

OSPF Hub-And-Spoke

For those of you who used my Ultimate CCNA Lab Workbook to pass the CCNA, much of whatfollows will seem familiar - but do not skip it! Cisco will test you on every aspect of OSPF on theBSCI exam, and that includes the many details of hub-and-spoke configurations, as well as virtuallinks. Besides, you need this section to be up-and-running before we configure route

redistribution, stub area, and total stub areas. So let's get started!

Our OSPF backbone area will be the frame cloud connecting R1, R2, and R3. This particularconfiguration requires that R1 is the DR and that R2 and R3 have no chance to become either theDR or the BDR. This will be done with the command ip ospf priority 0on the serial0 interfaces ofboth R2 and R3.

The hub will also require neighbor statements. The routers will advertise their loopbackinterfaces as well. Place each loopback interface into an OSPF area that matches the routernumber.

R1(config)#router ospf 1R1(config-router)#network 172.12.123.0 0.0.0.255 area 0R1(config-router)#network 1.1.1.1 0.0.0.0 area 1R1(config-router)#neighbor 172.12.123.2R1(config-router)#neighbor 172.12.123.3

R2(config)#interface serial0R2(config-if)#ip ospf priority 0R2(config-if)#router ospf 1R2(config-router)#network 172.12.123.0 0.0.0.255 area 0R2(config-router)#network 2.2.2.2 0.0.0.0 area 2

R3(config)#interface serial0R3(config-if)#ip ospf priority 0


26/68

R3(config-if)#router ospf 1R3(config-router)#network 172.12.123.0 0.0.0.255 area 0R3(config-router)#network 3.3.3.3 0.0.0.0 area 3

Run show ip ospf neighboron each router to ensure the adjacencies have formed.

R1#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface3.3.3.3 0 FULL/DROTHER 00:01:43 172.12.123.3 Serial02.2.2.2 0 FULL/DROTHER 00:01:35 172.12.123.2 Serial0


Neighbor ID Pri State Dead Time Address Interface1.1.1.1 1 FULL/DR 00:01:42 172.12.123.1 Serial0



The expected adjacencies have formed, and both R2 and R3 see R1 as the DR. R1 sees bothR2 and R3 as "DROTHER"s, meaning that neither R2 nor R3 is a DR or BDR.

Run show ip route ospfon R1, and ping the remote loopbacks to ensure total IP connectivity.

R1#show ip route ospf2.0.0.0/32 is subnetted, 1 subnets

O IA 2.2.2.2 [110/65] via 172.12.123.2, 00:05:43, Serial03.0.0.0/32 is subnetted, 1 subnets

O IA 3.3.3.3 [110/65] via 172.12.123.3, 00:05:43, Serial0

R1#ping 2.2.2.2

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

R1#ping 3.3.3.3


Take a closer look at R1's OSPF table. The routes are marked "O IA", meaning that thesedestinations are in different areas - these are inter-area routes. Run the same command on R2and R3, and make sure you can ping the remote loopbacks before continuing. (Pings not shown.)



O IA 3.3.3.3 [110/65] via 172.12.123.3, 00:07:46, Serial0


27/68



O IA 2.2.2.2 [110/65] via 172.12.123.2, 00:07:58, Serial0

On R1, run the command show ip ospf interface serial0.

R1#show ip ospf interface serial0Serial0 is up, line protocol is upInternet Address 172.12.123.1/24, Area 0Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64Transmit Delay is 1 sec, State DR, Priority 1Designated Router (ID) 1.1.1.1, Interface address 172.12.123.1No backup designated router on this networkTimer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5Hello due in 00:00:09

Index 1/1, flood queue length 0Next 0x0(0)/0x0(0)Last flood scan length is 1, maximum is 2

Last flood scan time is 4 msec, maximum is 4 msecNeighbor Count is 2, Adjacent neighbor count is 2Adjacent with neighbor 3.3.3.3Adjacent with neighbor 2.2.2.2

Suppress hello for 0 neighbor(s)

There's a lot of interesting information in the output of this command. You see that the networktype is NBMA (non-broadcast), the OSPF cost of the interface is 64, the router is the DR, there isno BDR, and there are two adjacencies. Run this command on R2 and R3 as well to see thedifferences from R1's output.

The reason we set the OSPF interface priority on R2 and R3 to zero is to make sure that if R1goes down, there will be no DR/BDR election in its absence. To test this, we will first set theOSPF hello-interval on all three routers' serial0 interfaces to 5 seconds, making the dead-time 20seconds by default. Then reload R1 and see if a DR or BDR is elected while R1 is gone.

R2(config)#interface serial0R2(config-if)#ip ospf hello 5

R3(config)#int serial0R3(config-if)#ip ospf hello 5

R1(config)#interface serial0R1(config-if)#ip ospf hello 5R1(config-if)#^ZR1#reloadSystem configuration has been modified. Save? [yes/no]: y

Building configuration...[OK]Proceed with reload? [confirm]

While R1 is reloading, run show ip ospf neighboron R2.


R2 is not attempting to elect a DR or BDR during R1's downtime. When R1 comes back up, runthe same command.


28/68


Neighbor ID Pri State Dead Time Address Interface3.3.3.3 0 FULL/DROTHER 00:00:17 172.12.123.3 Serial02.2.2.2 0 FULL/DROTHER 00:00:15 172.12.123.2 Serial0

R1 has again become the DR and sees R2 and R3 as DROTHERS - just as it did before the

reload.

All three routers will show the Router ID (RID) of the DR to be 1.1.1.1, as seen with show ip ospfneighbor:





By default, the highest IP address on a loopback interface will be the OSPF RID of a router, evenif that loopback interface is not OSPF-enabled. If there is no loopback, the highest IP addressassigned to a physical interface on the router becomes the RID, even if that interface is notOSPF-enabled.

We'll now change the OSPF RID on R1 to 11.11.11.11. Use the router-idcommand to do this asshown below. To make this command take effect, you must either reload the router or clear theOSPF processes; doing either will tear down any existing OSPF adjacencies. Cisco is niceenough to mention this after you run the command. Also note that the default answer to thequestion you're asked when clearing the process is "no". That's an excellent tipoff in the realworld that you're about to do something that maybe, just maybe, you shouldn't be doing.

R1(config)#router ospf 1R1(config-router)#router-id 11.11.11.11Reload or use "clear ip ospf process" command, for this to take effect

R1#clear ip ospf processReset ALL OSPF processes? [no]: yes

5d04h: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0 from 2WAY to DOWN, NeighborDown: Interface down or detached5d04h: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0 from 2WAY to DOWN, NeighborDown: Interface down or detached

5d04h: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0 from LOADING to FULL, LoadingDone

5d04h: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0 from LOADING to FULL, LoadingDone

R1#show ip ospf interface seria0Serial0 is up, line protocol is upInternet Address 172.12.123.1/24, Area 0Process ID 1, Router ID 11.11.11.11, Network Type NON_BROADCAST, Cost: 64Transmit Delay is 1 sec, State DR, Priority 1Designated Router (ID) 11.11.11.11, Interface address 172.12.123.1


29/68

R1's OSPF RID has been successfully changed. Do the same for R2 and R3, changing their IDsto 22.22.22.22 and 33.33.33.33, respectively. Don't forget to reload the router or clear the OSPFprocesses after doing so.

R2(config)#router ospf 1R2(config-router)#router-id 22.22.22.22Reload or use "clear ip ospf process" command, for this to take effectR2(config-router)#^ZR2#clear ip ospf processReset ALL OSPF processes? [no]: yes

R3(config)#router ospf 1R3(config-router)#router-id 33.33.33.33Reload or use "clear ip ospf process" command, for this to take effectR3(config-router)#^ZR3#clear ip ospf processReset ALL OSPF processes? [no]: y

We will now add an area, placing the directly connected serial interfaces of R3 and R4 into OSPFArea 34. R4's loopback address of 4.4.4.4 will be placed into Area 4.


30/68

R3(config)#router ospf 1

R3(config-router)#network 10.2.2.0 0.0.0.255 area 34

R4(config)#router ospf 1R4(config-router)#network 10.2.2.0 0.0.0.255 area 34R4(config-router)#network 4.4.4.4 0.0.0.0 area 4

Verify the adjacency on R3.



4.4.4.4 1 FULL/ - 00:00:35 10.2.2.4 Serial1

The adjacency is present, but note that there is a dash where we would usually expect to see DR,BDR, or DROTHER. That is because this is a point-to-point connection, which defaults to theOSPF network type point-to-point. By definition, a point-to-point network can only have twointerfaces connected to it, eliminating the need for a DR or BDR. Verify this network type with thecommand show ip ospf interface serial1. There is no reference to a DR or BDR in this commandoutput.

R3#show ip ospf interface serial1Serial1 is up, line protocol is upInternet Address 10.2.2.3/24, Area 34Process ID 1, Router ID 33.33.33.33, Network Type POINT_TO_POINT, Cost:64Transmit Delay is 1 sec, State POINT_TO_POINT,Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

Hello due in 00:00:02Index 1/3, flood queue length 0Next 0x0(0)/0x0(0)Last flood scan length is 1, maximum is 1Last flood scan time is 0 msec, maximum is 0 msecNeighbor Count is 1, Adjacent neighbor count is 1Adjacent with neighbor 4.4.4.4

Suppress hello for 0 neighbor(s)

Check R3's OSPF routing table to make sure it sees R4's loopback interface.


O IA 1.1.1.1 [110/65] via 172.12.123.1, 00:23:16, Serial0

2.0.0.0/32 is subnetted, 1 subnetsO IA 2.2.2.2 [110/65] via 172.12.123.2, 00:23:16, Serial0


31/68

This is interesting - we've got an adjacency between R3 and R4, and we put R4's loopbackinterface into OSPF. Why don't we see R4's loopback interface, then? Let's take another look atthe network topology - do you see the problem?

OSPF dictates that every OSPF area must contain a router that has a physical or logical interfacein Area 0. Area 4 violates this rule, and as a result we are not going to have total IP connectivity.Since we do not have another interface on R4 that can be connected to Area 0, we're going tocreate a logical connection - a virtual link.

A virtual link is like a tunnel to Area 0. The area through which the virtual link is built is the transitarea, and this transit area cannot be a stub or total stub area.


32/68

The command used to build the virtual link is simple, but make sure you use the remote router'sOSPF RID in the command, not the IP address of the interface found in the transit area. For R4to successfully build a virtual link to R3, the dotted decimal value in the command must be R3'sOSPF RID.

R4(config)#router ospf 1

R4(config-router)#area 34 virtual-link 33.33.33.33

R3(config)#router ospf 1R3(config-router)#area 34 virtual-link 4.4.4.4R3(config-router)#5d05h: %OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone areamust be virtual-link but not found from 10.2.2.4, Serial1

Don't let that error message distract you. The virtual link command must be configured on bothsides, and when you start configuring the remote router, you will probably see this message. Youmay even see it just a second after you configure the router, as we did here. The only time thisshould concern you is if you keep getting the message over and over again after configuring thevirtual link. The most common reason for this is that the OSPF RID value was not used.

Luckily for us, we see this message very shortly after the configuration was finished:

5d05h: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on OSPF_VL0 from LOADING to FULL,Loading Done

Always run show ip ospf virtual-linkto verify the configuration. The virtual link must have anadjacency state of FULL. R3, R2, and R1 should all now see R4's loopback and be able to pingit.

R3#show ip ospf virtual-linkVirtual Link OSPF_VL0 to router 4.4.4.4 is upRun as demand circuitDoNotAge LSA allowed.Transit area 34, via interface Serial1, Cost of using 64Transmit Delay is 1 sec, State POINT_TO_POINT,Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5Hello due in 00:00:04Adjacency State FULL (Hello suppressed)Index 2/3, retransmission queue length 0, number of retransmission 1First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)Last retransmission scan length is 1, maximum is 1Last retransmission scan time is 0 msec, maximum is 0 msec




O IA 4.4.4.4 [110/65] via 10.2.2.4, 00:02:57, Serial1


33/68

R3#ping 4.4.4.4


OSPF Stub Areas, Total Stub Areas, Route Redistribution & Summarization

OSPF stub and total stub areas are a great way to keep a routing table as small as possible whilestill allowing full IP connectivity, and also lessens the load on a router's resources by keeping thetable small.

To configure this section, you should have the entire OSPF Hub-And-Spoke configuration inplace, EXCEPT that there will be no Area 4 on R4, and there will be no virtual link between R3and R4. If you have just completed that lab, run the following commands to remove the area andthe virtual link.

R3(config)#router ospf 1R3(config-router)#no area 34 virtual-link 4.4.4.4

5d05h: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on OSPF_VL0 from FULL to DOWN,Neighbor Down: Interface down or detached


34/68

R4(config)#router ospf 1R4(config-router)#no area 34 virtual-link 33.33.33.33R4(config-router)#no network 4.4.4.4 0.0.0.0 area 4

View R4's OSPF routing table.

R4#show ip route ospf





Ping each of the remote destinations, including R1, R2, and R3's serial0 interfaces. You shouldhave full IP connectivity.

Looking at that routing table, we see that no matter what the destination is, the next-hop IP

address is the same. There's nothing "wrong" with this table, but parsing the entire table everytime a packet has to be routed is an unnecessary load on the router's resources, since the next-hop address is going to be the same address every time. There could be 100 routes in this tableand the next-hop would always be the same, since there's only one interface on R4 that iscurrently enabled.

Before addressing that topic, let's bring in some more routes via route redistribution. We're goingto create three additional loopbacks on R1 and redistribute them into OSPF with the redistributeconnectedcommand.

R1(config)#int loopback 12R1(config-if)#ip address 12.12.12.12 255.255.255.255R1(config-if)#int loopback 13R1(config-if)#ip address 13.13.13.13 255.255.255.255

R1(config-if)#int loopback 14R1(config-if)#ip address 14.14.14.14 255.255.255.255

R1(config)#router ospf 1R1(config-router)#redistribute connected% Only classful networks will be redistributedR1(config-router)#redistribute connected subnets

Here's the first of several route redistribution details you'll need to keep in mind! With OSPF, ifyou don't specify the "subnets" option, only classful networks will be redistributed. The routerwas kind enough to remind us of that, but it's doubtful the BSCI exam will be.


35/68

This redistribution makes R1 an Autonomous System Border Router (ASBR), verified by show ipospf.

R1#show ip ospfRouting Process "ospf 1" with ID 11.11.11.11Supports only single TOS(TOS0) routes

Supports opaque LSAIt is an area border and autonomous system boundary routerRedistributing External Routes from,

connected, includes subnets in redistribution

< output truncated here>

Let's look at R4's routing table.



O IA 2.2.2.2 [110/129] via 10.2.2.3, 00:01:27, Serial0



12.0.0.0/32 is subnetted, 1 subnetsO E2 12.12.12.12 [110/20] via 10.2.2.3, 00:01:27, Serial0



The routing table is now twice as large as it was. The routes that are being redistributed on R1are seen on R4 as "O E2" routes. This means that they were learned by OSPF via redistribution

(external routes), and the cost shown for each route does NOT include the cost between the localrouter and the ASBR. This is the default for routes redistributed into OSPF.

To have the external routes reflect the entire cost of the path to the remote destination, they mustbe E1 routes, and this is done at the ASBR with the redistributecommand.

R1(config)#router ospf 1R1(config-router)#no redistribute connected subnetsR1(config-router)#redistribute connected subnets metric-type ?1 Set OSPF External Type 1 metrics2 Set OSPF External Type 2 metrics

R1(config-router)#redistribute connected subnets metric-type 1

Look at R4's routing table again.






36/68


O E1 12.12.12.12 [110/148] via 10.2.2.3, 00:00:40, Serial013.0.0.0/32 is subnetted, 1 subnets

O E1 13.13.13.13 [110/148] via 10.2.2.3, 00:00:40, Serial014.0.0.0/32 is subnetted, 1 subnets

O E1 14.14.14.14 [110/148] via 10.2.2.3, 00:00:41, Serial0

The routes are now E1 routes, and the cost is the cost of the entire path from R4 to the remoteloopbacks, including the cost between R4 and R1.

We'll now change the metric type back to E2 with the following configuration:

R1(config)#router ospf 1R1(config-router)#no redistribute connected metric-type 1 subnetsR1(config-router)#redistribute connected subnets

You know the difference between E1 and E2 routes, you know the default, and you know how tochange the default - but no matter what metric type we use, the next-hop for all three of thoseexternal routes is still 10.2.2.3. Instead of having three separate external route entries, it would be

more efficient to have a single default route replace all four of these routes. This can be done byconfiguring Area 34 as a stub area. A stub area's ABR - in this case, R3 - will generate a defaultroute that will take the place of all external routes.

To configure Area 34 as a stub area, run the area 34 stubcommand on both R3 and R4. Allrouters in a stub area must agree that this is indeed a stub area, or adjacencies will be droppedbetween the routers that do not agree on this.

R3(config)#router ospf 1R3(config-router)#area 34 stub

5d05h: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Serial1 from FULL to DOWN, NeighborDown: Adjacency forced to reset

R4(config)#router ospf 1R4(config-router)#area 34 stub


Neighbor ID Pri State Dead Time Address Interface33.33.33.33 1 FULL/ - 00:00:37 10.2.2.3 Serial0

The adjacency between R3 and R4 went down immediately when Area 34 was configured asstub on R3, but came right back up when R4 agreed that Area 34 is a stub area.

Let's take a look at R4's OSPF table.






37/68

O IA 172.12.123.0 [110/128] via 10.2.2.3, 00:00:04, Serial0O*IA 0.0.0.0/0 [110/65] via 10.2.2.3, 00:00:04, Serial0

The three external routes have been replaced with a default inter-area route. Try pinging12.12.12.12, 13.13.13.13, and 14.14.14.14. - you still have full IP connectivity, but the routingtable is smaller.

As noted earlier in this section, the next-hop address for all the inter-area routes is also 10.2.2.3.We can replace all the external and inter-area routes with a single default route by configuringArea 34 as a total stub area. To do this, add no-summaryto the stub command on the ABR only.(It doesn't hurt anything in the real world if you put "no-summary" on the non-ABRs, but it's agood detail to remember that it only has to be configured on the ABR.)

R3(config)#router ospf 1R3(config-router)#area 34 stub no-summary

Now look at R4's OSPF routing table.

R4#show ip route ospfO*IA 0.0.0.0/0 [110/65] via 10.2.2.3, 00:04:24, Serial0

Instead of seven more-specific routes - four internal and three external - R4 now has a singledefault OSPF route with which to reach those seven destinations. Ping all the loopback on all theremote routers from R4. You still have total IP connectivity, and the load on R4 is much lightersince it has a much smaller routing table.

We'll now look at the two different methods by which OSPF routers can perform routesummarization. (You MUST master the details of thes two commands before taking and passingthe BSCI exam.) Before starting the next part of this lab, remove all stub routing commands fromR3 and R4.

Additionally, the only loopback R1 should be advertising is 1.1.1.1/32, in Area 1. Delete all other

loopbacks entirely.

Create the following loopbacks on R1:

interface Loopback12ip address 12.12.12.12 255.0.0.0!interface Loopback13ip address 13.13.13.13 255.0.0.0!interface Loopback14ip address 14.14.14.14 255.0.0.0!interface Loopback15

ip address 15.15.15.15 255.0.0.0

Place all four networks into Area 1. After doing so, check the other routers and make sure allrouters see all four of these new routes.

R1(config)#router ospf 1R1(config-router)#network 12.0.0.0 0.255.255.255 a 1R1(config-router)#network 13.0.0.0 0.255.255.255 a 1R1(config-router)#network 14.0.0.0 0.255.255.255 a 1R1(config-router)#network 15.0.0.0 0.255.255.255 a 1


38/68








O IA 15.15.15.15 [110/65] via 172.12.123.1, 00:18:32, Serial0

The area range command can be used to summarize routes that reside in one OSPF area.Summarize the four networks on paper before continuing with this lab. What is the correctsummary to advertise?

The correct summary route is 12.0.0.0 252.0.0.0. The area range command is easy to configure,but there's one very important detail to keep in mind - the area number in this command is thearea containing the routes being summarized, NOT the area that will see the summary.Configure the area range command on R1 and check the routing tables of the other routers.

R1(config)#router ospf 1R1(config-router)#area 1 range 12.0.0.0 252.0.0.0




O IA 10.2.2.0 [110/128] via 172.12.123.3, 00:43:37, Serial0O IA 12.0.0.0/6 [110/65] via 172.12.123.1, 00:00:21, Serial0

The routes have been successfully summarized.

Add the following four loopbacks to R1, and advertise them into OSPF with the redistributecommand.

interface Loopback16ip address 16.16.16.16 255.0.0.0!interface Loopback17ip address 17.17.17.17 255.0.0.0

!interface Loopback18ip address 18.18.18.18 255.0.0.0!interface Loopback19ip address 19.19.19.19 255.0.0.0

R1(config)#router ospf 1R1(config-router)#redistribute connected subnets


39/68

These four routes are seen on the downstream routers as External Type-2, the default for routesredistributed into OSPF.

R2#show ip route ospfO E2 17.0.0.0/8 [110/20] via 172.12.123.1, 00:00:07, Serial0O E2 16.0.0.0/8 [110/20] via 172.12.123.1, 00:00:07, Serial0

1.0.0.0/32 is subnetted, 1 subnetsO IA 1.1.1.1 [110/65] via 172.12.123.1, 00:00:07, Serial0O E2 19.0.0.0/8 [110/20] via 172.12.123.1, 00:00:07, Serial0O E2 18.0.0.0/8 [110/20] via 172.12.123.1, 00:00:07, Serial0


10.0.0.0/24 is subnetted, 1 subnetsO IA 10.2.2.0 [110/128] via 172.12.123.3, 00:00:08, Serial0O IA 12.0.0.0/6 [110/65] via 172.12.123.1, 00:00:08, Serial0

To summarize networks learned by redistribution, use the OSPF command summary-address. You can probably do this summarization in your head, but do so before continuing withthe lab. : )

R1(config)#router ospf 1R1(config-router)#summary-address 16.0.0.0 252.0.0.0

Check the downstream routers' OSPF tables.




O IA 10.2.2.0 [110/128] via 172.12.123.3, 00:04:48, Serial0O E2 16.0.0.0/6 [110/20] via 172.12.123.1, 00:00:05, Serial0O IA 12.0.0.0/6 [110/65] via 172.12.123.1, 00:04:48, Serial0

The external routes have been successfully summarized. Note that the summary route is stillmarked as an E2 route.

To complete the lab, go back to R1 and look at its OSPF table.



O IA 10.2.2.0 [110/128] via 172.12.123.3, 00:06:33, Serial0O 16.0.0.0/6 is a summary, 00:01:51, Null0O 12.0.0.0/6 is a summary, 00:06:34, Null0


40/68

When you configure summary routes in OSPF, a route to null0 will be installed into the OSPFrouting table. This helps to prevent routing loops. Any packets destined for the routes that havebeen summarized will have a longer match in the routing table....

R1#show ip route


C 17.0.0.0/8 is directly connected, Loopback17C 16.0.0.0/8 is directly connected, Loopback16

1.0.0.0/32 is subnetted, 1 subnetsC 1.1.1.1 is directly connected, Loopback0

2.0.0.0/32 is subnetted, 1 subnetsS 2.2.2.2 [1/0] via 172.12.123.2C 19.0.0.0/8 is directly connected, Loopback19C 18.0.0.0/8 is directly connected, Loopback18

3.0.0.0/32 is subnetted, 1 subnetsO IA 3.3.3.3 [110/65] via 172.12.123.3, 00:07:49, Serial0B 21.0.0.0/8 [200/0] via 172.12.123.3, 05:10:42


C 172.12.123.0 is directly connected, Serial010.0.0.0/24 is subnetted, 1 subnets

O IA 10.2.2.0 [110/128] via 172.12.123.3, 00:07:52, Serial0C 12.0.0.0/8 is directly connected, Loopback12C 13.0.0.0/8 is directly connected, Loopback13C 14.0.0.0/8 is directly connected, Loopback14C 15.0.0.0/8 is directly connected, Loopback15O 16.0.0.0/6 is a summary, 00:03:10, Null0O 12.0.0.0/6 is a summary, 00:07:53, Null0

.. and packets that do not match one of the summarized routes but do match the summary routewill be dropped.


41/68

EIGRP

Before beginning this lab, each router should have a loopback using its own number for eachoctet, and the following networks should be up and running:

R1-R2-R3 Serial interfaces, 172.12.123.0 /24

R2 - R3 Ethernet interfaces, 172.12.23.0 /24

R3 - R4 Directly connected serial interfaces, 10.2.2.0 /24.

Enable EIGRP on all serial interfaces, the ethernet segment, and the directly connected serialinterfaces. Enable EIGRP on all loopback interfaces except R1. Disable EIGRP auto-summarization on all routers.

R1(config)#router eigrp 100R1(config-router)#no auto-summaryR1(config-router)#network 172.12.123.0 0.0.0.255

R2(config)#router eigrp 100R2(config-router)#no auto-summaryR2(config-router)#network 172.12.123.0 0.0.0.255R2(config-router)#network 172.12.23.0 0.0.0.255R2(config-router)#network 2.2.2.2 0.0.0.0

R3(config)#router eigrp 100R3(config-router)#no auto-summaryR3(config-router)#network 172.12.123.0 0.0.0.255R3(config-router)#network 172.12.23.0 0.0.0.255R3(config-router)#network 10.2.2.0 0.0.0.255R3(config-router)#network 3.3.3.3 0.0.0.0

R4(config)#router eigrp 100R4(config-router)#no auto-summaryR4(config-router)#network 10.2.2.0 0.0.0.255

^% Invalid input detected at '^' marker.

R4(config-router)#network 10.2.2.0R4(config-router)#network 4.4.4.4

Note that R4 does not allow you to configure a wildcard mask for EIGRP. You may well run intosome older IOS versions that do not allow you to do this, so I thought I'd remind you that notevery EIGRP deployment in the real world uses them. You'll see that VLSM support is stillpresent, though.

Run show ip route eigrp 100on R1.

R1#show ip route eigrp 1002.0.0.0/32 is subnetted, 1 subnets

D 2.2.2.2 [90/2297856] via 172.12.123.2, 00:04:13, Serial03.0.0.0/32 is subnetted, 1 subnets


D 4.4.4.4 [90/2809856] via 172.12.123.3, 00:03:02, Serial0


42/68

172.12.0.0/24 is subnetted, 2 subnetsD 172.12.23.0 [90/2195456] via 172.12.123.3, 00:04:15, Serial0

[90/2195456] via 172.12.123.2, 00:04:15, Serial010.0.0.0/24 is subnetted, 1 subnets

D 10.2.2.0 [90/2681856] via 172.12.123.3, 00:04:09, Serial0

Quite a bit of this is familiar to you from your CCNA studies, but let's review. These are allinternal EIGRP routes and therefore have an AD of 90. The number in the brackets following theAD is the feasible distance. Finally, we see two paths to 172.12.23.0 /24. Why? Because themetric is exactly the same (2195456), and EIGRP performs equal-cost load-sharing over up tofour paths by default. We can change this default value with the maximum-pathscommand, asshown here and then verified with show ip protocols. (This command also verifies that automaticsummarization is not in effect - we turned it off with no auto-summary.)

R1(config)#router eigrp 100R1(config-router)#maximum-paths 6

R1#show ip protocolsRouting Protocol is "eigrp 100"Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not setDefault networks flagged in outgoing updatesDefault networks accepted from incoming updatesEIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0EIGRP maximum hopcount 100EIGRP maximum metric variance 1Redistributing: eigrp 100Automatic network summarization is not in effectMaximum path: 6Routing for Networks:172.12.123.0/24

Routing Information Sources:Gateway Distance Last Update172.12.123.3 90 00:00:06172.12.123.2 90 00:00:06

Distance: internal 90 external 170

Looking at the network topology, we know there are two paths to R4's loopback from R1. One isthe more direct path directly to R3 through the frame and then on to R4, but another possiblepath is to go through R2 through the frame cloud, then to R3 through the ethernet segment, thento R4. But is this a valid path? We can find out by looking in the EIGRP topology table on R1.

R1#show ip eigrp topologyIP-EIGRP Topology Table for AS(100)/ID(14.14.14.14)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,r - reply Status, s - sia Status

P 4.4.4.4/32, 1 successors, FD is 2809856via 172.12.123.3 (2809856/2297856), Serial0via 172.12.123.2 (2835456/2323456), Serial0




43/68



P 172.12.123.0/24, 1 successors, FD is 2169856via Connected, Serial0

Not only does R1 have two valid paths to 4.4.4.4, it also has two valid paths to 3.3.3.3, 2.2.2.2,and 10.2.2.0/24. The path that is in use is the successor; the path that is valid but is not in use isthe feasible successor. (Note that since R1 is using two equal-cost paths to reach172.12.23.0/24, there are two successors for that network.)

We will configure EIGRP to allow us to use the feasible successors in unequal-cost load-sharingwith the variancecommand. We need to come up with a number that when multiplied by themetric for the successor is greater than the metric of the feasible successor. It's a lot harder thanit sounds!

The metric for the successor to 4.4.4.4 is 2809856. The metric for the feasible successor is

2835456. Therefore, a value of 2 for the variancecommand should do the job. Configure thatvalue on R1 and clear the routing table.

R1(config)#router eigrp 100R1(config-router)#variance 2


D 2.2.2.2 [90/2297856] via 172.12.123.2, 00:00:12, Serial0[90/2323456] via 172.12.123.3, 00:00:12, Serial0



D 4.4.4.4 [90/2809856] via 172.12.123.3, 00:00:12, Serial0[ 90/2835456] via 172.12.123.2, 00:00:12, Serial0



D 10.2.2.0 [90/2681856] via 172.12.123.3, 00:00:12, Serial0[90/2707456] via 172.12.123.2, 00:00:12, Serial0

The metrics themselves do not change, but now any route to 4.4.4.4 that has a metric less than(2297856 * 2) will be placed into the routing table. Unequal-cost load-sharing is in proportion tothe metrics; if you want the paths participating in unequal-cost load-sharing to carry roughly thesame percentage of the load, run the command traffic-share balancedunder the EIGRP process.

R1(config)#router eigrp 100R1(config-router)#traffic-share balanced

Configure additional loopback interfaces on R1:


44/68

Loopback 11, ip address 11.11.11.11 /32



We'll now redistribute all loopback interfaces into EIGRP AS 100 with the redistributecommand.

The options will be different than what we saw with OSPF. There is no "subnets" option, but wemust configure a seed metric for routes being redistributed into EIGRP or the redistribution willfail.

You recall from your CCNA studies that the metrics for EIGRP are bandwidth, delay, load,reliability, and MTU. Each one of these values must be defined for the redistributed routes.

R1(config)#router eigrp 100R1(config-router)#redistribute connected ?metric Metric for redistributed routesroute-map Route map reference

R1(config-router)#redistribute connected metric ? Bandwidth metric in Kbits per second

R1(config-router)#redistribute connected metric 1544 ? IGRP delay metric, in 10 microsecond units

R1(config-router)#redistribute connected metric 1544 100 ? IGRP reliability metric where 255 is 100% reliable

R1(config-router)#redistribute connected metric 1544 100 255 ? IGRP Effective bandwidth metric (Loading) where 255 is 100% loaded

R1(config-router)#redistribute connected metric 1544 100 255 1 ? IGRP MTU of the path

R1(config-router)#redistribute connected metric 1544 100 255 1 1500

On R2, R3, or R4, run show ip route eigrp 100.


D EX 1.1.1.1 [170/2195456] via 172.12.123.1, 00:04:49, Serial02.0.0.0/32 is subnetted, 1 subnets

D 2.2.2.2 [90/409600] via 172.12.23.2, 00:29:08, Ethernet04.0.0.0/32 is subnetted, 1 subnets


D EX 11.11.11.11 [170/2195456] via 172.12.123.1, 00:04:49, Serial0

12.0.0.0/32 is subnetted, 1 subnetsD EX 12.12.12.12 [170/2195456] via 172.12.123.1, 00:04:49, Serial0



The routes being redistributed into EIGRP are showing as "D EX" routes. The "EX" indicates thatthese are EXternal routes, and they have a higher administrative distance than internal


45/68

routes. The AD of EIGRP External routes is 170, as shown in the brackets for each of theseroutes.

We're now going to add four more loopbacks to R1, but these will be advertised into EIGRP. Addthe following loopbacks to R1 and then place them into AS 100:

Loopback 16, 16.16.16.16 /32

Loopback 17, 17.17.17.17 /32

Loopback 18, 18.18.18.18 /32

Loopback 19. 19.19.19.19 /32

R1(config-if)#router eigrp 100R1(config-router)#network 16.16.16.16 0.0.0.0R1(config-router)#network 17.17.17.17 0.0.0.0R1(config-router)#network 18.18.18.18 0.0.0.0R1(config-router)#network 19.19.19.19 0.0.0.0

R3's EIGRP routing table now looks like this:

R3#show ip route eigrp17.0.0.0/32 is subnetted, 1 subnets




D 2.2.2.2 [90/409600] via 172.12.23.2, 00:35:58, Ethernet019.0.0.0/32 is subnetted, 1 subnets







D EX 14.14.14.14 [170/2195456] via 172.12.123.1, 00:11:41, Serial0

That's a pretty big table. Let's summarize those last four networks on R1 and then advertise thatsummary.


46/68

To perform manual route summarization, write out the network addresses in binary and thendetermine the point at which the addresses no longer have a bit in common. For these fouraddresses, it will be enough to write out the first octet in binary:

16 00010000

17 00010001

18 00010010

19 00010011

Working from left to right, the common bits are the first six bits - 000100xx. In decimal, this valueis 16. The summary mask must be determined as well, and that value is derived from putting a"1" in the mask for each common bit. With the first six bits all set to one - 11111100 - theresulting mask is 252.0.0.0. The full summary address is 16.0.0.0 252.0.0.0.

In EIGRP, the summary address is actually configured on an interface, not under the routingprocess. Configure the following on R1's serial interface:

R1(config)#interface serial0R1(config-if)#ip summary-address eigrp 100 16.0.0.0 252.0.0.0

02:39:50: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.3 (Serial0) is down:summary configured02:39:50: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.2 (Serial0) is down:summary configured

02:40:16: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.2 (Serial0) is up : newadjacency

02:40:17: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.3 (Serial0) is up: newadjacency

There's an immediate side effect here that most books leave out. Your EIGRP adjacencies aregoing to come down after you configure this summary, but they should come back up quickly.The key word there is "should". If you configure EIGRP summary addresses on a productionnetwork, you may want to do this during non-peak hours. The timestamps on the abovecommands indicate that the adjacencies were down for about 27 seconds over the NBMAnetwork. That's about 30 minutes in end-user time. ;)

Check R3's EIGRP routing table.

R3#show ip route eigrp1.0.0.0/32 is subnetted, 1 subnets


D 2.2.2.2 [90/409600] via 172.12.23.2, 00:50:24, Ethernet04.0.0.0/32 is subnetted, 1 subnetsD 4.4.4.4 [90/2297856] via 10.2.2.4, 00:49:11, Serial1






47/68

D EX 14.14.14.14 [170/2195456] via 172.12.123.1, 00:01:46, Serial0D 16.0.0.0/6 [90/2297856] via 172.12.123.1, 00:01:46, Serial0

The four summarized routes are no longer in the routing table, and they have been replaced bythe summary route shown at the bottom of the routing table. Notice the mask is /5, which is prefixnotation for 248.0.0.0.

We'll now configure link authentication on the adjacency over the Ethernet segment. Configure akey chain called EIGRP on both routers, use key number 1, and use the key-string BSCI. Runshow key chainon both routers to see all key chains present on the router.

R2(config)#key chain EIGRPR2(config-keychain)#key 1R2(config-keychain-key)#key-string BSCI

R2#show key chain

Key-chain EIGRP:key 1 -- text "BSCI"

accept lifetime (always valid) - (always valid) [valid now]

send lifetime (always valid) - (always valid) [valid now]

R3(config)#key chain EIGRPR3(config-keychain)#key 1R3(config-keychain-key)#key-string BSCI

R3#show key chain

Key-chain EIGRP:key 1 -- text "BSCI"

accept lifetime (always valid) - (always valid) [valid now]send lifetime (always valid) - (always valid) [valid now]

Apply the key chain to the ethernet interfaces on both R2 and R3. The EIGRP command for this

is a bit of a pain to remember, because the protocol and AS number is identified in the middle ofthe command, not the beginning.

R2(config)#interface ethernet0R2(config-if)#ip authentication key-chain eigrp 100 EIGRPR2(config-if)#ip authentication mode eigrp 100 md5

5d07h: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.23.3 (Ethernet0) is down:keychain changed

R3(config)#interface ethernet0R3(config-if)#ip authentication key-chain eigrp 100 EIGRPR3(config-if)#ip authentication mode eigrp 100 md5

5d07h: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.23.2 (Ethernet0) is up:

On both R2 and R3, run show ip eigrp neighborto verify the ethernet segment adjacency is up.

R2#show ip eigrp neighborIP-EIGRP neighbors for process 100H Address Interface Hold Uptime SRTT RTO

(sec) (ms)


48/68

0 172.12.23.3 Et0 14 00:02:40 423 25381 172.12.123.1 Se0 156 00:18:01 88 528

R3#show ip eigrp neighborIP-EIGRP neighbors for process 100H Address Interface Hold Uptime SRTT RTO

(sec) (ms)0 172.12.23.2 Et0 14 00:03:31 20 2001 172.12.123.1 Se0 165 00:18:48 97 5822 10.2.2.4 Se1 12 01:06:14 35 210


49/68

BGP

R1, R2, and R3 will all be in BGP AS 123. The Frame Relay cloud should be in place and allrouters should be able to successfully ping any other IP address on the cloud. Each router

should have a single loopback interface, with an IP address with the router number in each octet.

Build an eBGP peering between R1-R2 and R1-R3. Disable BGP synchronization.

R1(config)#router bgp 123R1(config-router)#no synchronizationR1(config-router)#neighbor 172.12.123.2 remote-as 123R1(config-router)#neighbor 172.12.123.3 remote-as 123

R2(config)#router bgp 123R2(config-router)#no synchronizationR2(config-router)#neighbor 172.12.123.1 remote-as 123

R3(config)#router bgp 123R3(config-router)#no synchronizationR3(config-router)#neighbor 172.12.123.1 remote-as 123

Verify the peering on all three routers with show ip bgp summary. (Only R1 is shown here.) Also,run show ip bgp neighboron all three routers. You'll notice you get a lot of information with theshow neighbor command! It's important to know the information generated by eachcommand, and in the real world I find the summary command to be more than enough todiagnose basic BGP connectivity issues.

R1#show ip bgp summaryBGP router identifier 1.1.1.1, local AS number 123BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down172.12.123.2 4 123 9 9 1 0 0 0 0:00:36172.12.123.3 4 123 8 8 1 0 0 0 0:00:36

R1#show ip bgp neighborBGP neighbor is 172.12.123.2, remote AS 123, internal link


50/68

BGP version 4, remote router ID 2.2.2.2BGP state = Established, up for 00:01:57Last read 00:00:57, hold time is 180, keepalive interval is 60 seconds

< output truncated >

We're now going to bring R4 into the configuration. The direct serial connection between R3 and

R4 must be operational. This also follows Cisco's recommendation that eBGP neighbors bedirectly connected.

Place R4 into BGP AS 4 and configure a peer relationship between R3 and R4.

R3(config)#router bgp 123R3(config-router)#neighbor 10.2.2.4 remote-as 4

R4(config)#router bgp 4R4(config-router)#no synchR4(config-router)#neighbor 10.2.2.3 remote-as 123

Verify with show ip bgp summary.

R3#show ip bgp summaryBGP router identifier 3.3.3.3, local AS number 123BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down10.2.2.4 4 4 3 4 1 0 0 00:00:07172.12.123.1 4 123 28 30 1 0 0 00:20:15

Configure R4 to advertise its loopback address via BGP.

R4(config)#router bgp 4R4(config-router)#network 4.4.4.4 mask 255.255.255.255

View the BGP routing table on R3.

R3#show ip bgpBGP table version is 2, local router ID is 3.3.3.3


51/68

Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 4.4.4.4/32 10.2.2.4 0 0 4 i

R4's loopback is in the table, is valid, and is the best path. The next-hop IP address is 10.2.2.4,

which is the IP address of the interface that advertised the route to R3.

View the BGP routing table on R1.

R1#show ip bgpBGP table version is 1, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path* i4.4.4.4/32 10.2.2.4 0 100 0 4 i

There are a few key BGP points illustrated here. First, the next-hop IP address is still 10.2.2.4.When an iBGP neighbor advertises a route that was learned via an eBGP neighbor, the next-hopIP address is retained. That's what happened here - R3 learned about the route from an eBGPneighbor, R4, and then advertised it to an iBGP neighbor, R1. Therefore, the next-hop IPaddress is retained.

The network has an asterisk next to it, indicating it as a valid route - but there is no ">" next to it.Both symbols must be seen or this is an invalid path. Why is it invalid? R1 has no knowledge ofthe network 10.2.2.4, so it does not know where the next-hop IP address is. Under thosecircumstances, the path is unusable.

R3 can serve as the next-hop address for routes sent to R1 by configuring the next-hop selfcommand on R3. Configure this command on R3 and then check R1's BGP table.

R3(config)#router bgp 123

R3(config-router)#neighbor 172.12.123.1 next-hop-self

R1#show ip bgpBGP table version is 2, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*>i4.4.4.4/32 172.12.123.3 0 100 0 4 i

The next-

Documents

TS BSCI Labbook