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

Advanced IP Addressing and Routing Cisco CCNP (BSCI)

Fast Track CBT Video Lab 23
Part 1 of 4 in the Cisco CCNP Series

About the Authors Chris Bryant (CCIE #12933) has extensive experience in both the practical and theoretical sides 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 skills the market demands. His nine years of IT experience and enthusiastic teaching style enables him 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 "different level!" Train Signal, Inc. 400 West Dundee Road Suite #106 Buffalo Grove, IL 60089 Phone - (847) 229-8780 Fax (847) 229-8760 www.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 the Information or THE INFORMATION), may not be reproduced or distributed in any form 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, are the trademarks, registered trademarks, and service marks of their respective owners.

Disclaimer and Limitation of Liability Although the publishers and authors of the Information have made every effort to ensure that the information within it was correct at the time of publication, the publishers and the authors do not assume and hereby disclaim any liability to any party for any loss or damage caused by errors, omissions, or misleading information. TRAIN SIGNAL, INC. PROVIDES THE INFORMATION "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, NONINFRINGEMENT, 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 VIRUSFREE, 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 the Software, 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 the Information shall be determined in accordance with the laws of the State of Illinois, in the event Train Signal, Inc. is made a party thereto. You agree to submit to the jurisdiction of the state and federal courts in Cook County, Illinois for all actions, whether in contract or in tort, arising from your use or purchase of the Information.

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!

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. You will 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 welcome to practice your enable secret, enable password, console password, and telnet passwords. However, you MUST use the passwords cisco or ccna, without the quotation marks. 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 to learn 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.

Network 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 interfaces as 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.

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 will not 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 labs on my pods, the switch ports are all in VLAN 1 and a trunk is already present between 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 shown in 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: Serial0 is connected to R4's Serial2 (Frame Relay Switching) Ethernet0 is connected to Switch1, port 0/2 R3: Serial0 is connected to R4's Serial3 (Frame Relay Switching) 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) Serial1 is connected to R1's Serial0 (Frame Relay Switching) Serial2 is connected to R2's Serial0 (Frame Relay Switching) Serial3 is connected to R3's Serial0 (Frame Relay Switching) Ethernet0 is connected to Switch1, port 0/4.

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 phone numbers for your ISDN connection is also in that email.) You can use any Telnet version to connect to your access server. You can use HyperTerminal 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 to your C: prompt. From your C: prompt, you can type telnet to go into Microsoft telnet, or type telnet 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 User Access Verification 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 when you enter your username and password. Thats a Cisco default. You will not see asterisks, as you do when logging in to most Microsoft products.

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

User Access Verification Password: BRYANT_POD_ONE# Your four routers and two Cisco 2950 switches are all connected to this access server. Heres how to access each device. First, clear the lines leading to the other devices. BRYANT_POD_ONE#clear [confirm] [OK] BRYANT_POD_ONE#clear [confirm] [OK] BRYANT_POD_ONE#clear [confirm] [OK] BRYANT_POD_ONE#clear [confirm] [OK] BRYANT_POD_ONE#clear [confirm] [OK] BRYANT_POD_ONE#clear [confirm] [OK] line 01 line 02 line 03 line 04 line 05 line 06

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 or two. 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.

Now, you need to learn the big keystroke that youll be using to go back from the access server. Here it is: <CTRL SHIFT 6> < X>

This keystroke is a little awkward at first, but before long youll be doing it without thinking 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#r3 Trying R3 (100.1.1.1, 2003)... Open R2# < Use above keystroke to go back to access server > BRYANT_POD_ONE#r4 Trying 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 router to 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 numbers to get to each device: 1: 2: 3: 4: 5: 6: R1 R2 R3 R4 SW1 SW2

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 [Resuming connection 2 to r2 ... ] R2# BRYANT_POD_ONE#3 [Resuming connection 3 to r3 ... ] R2# BRYANT_POD_ONE#3 [Resuming connection 4 to r4 ... ] 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 BSCI exam 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 get started! To your success, Chris Bryant CCIE #12933 chris@thebryantadvantage.com

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 loopback address 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: 1w0d: 1w0d: 1w0d: 1w0d: IP: IP: IP: IP: IP: s=3.3.3.3 s=3.3.3.3 s=3.3.3.3 s=3.3.3.3 s=3.3.3.3 (local), (local), (local), (local), (local), d=2.2.2.2, d=2.2.2.2, d=2.2.2.2, d=2.2.2.2, d=2.2.2.2, len len len len len 100, 100, 100, 100, 100, unroutable. unroutable. unroutable. unroutable. 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 route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, 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 C C C 3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 is directly connected, Loopback0 172.12.0.0/24 is subnetted, 2 subnets 172.12.23.0 is directly connected, Ethernet0 172.12.123.0 is directly connected, Serial0

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 debug off 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, sending 1w0d: 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, sending 1w0d: 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.U 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 1w0d: 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 all All 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 unusual output, there is a problem with routing on a downstream router. When the debug was 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 - a static route. R3#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter ar * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Gateway of last resort is not set S C C C 2.0.0.0/32 is subnetted, 1 subnets 2.2.2.2 [1/0] via 172.12.123.1 3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 is directly connected, Loopback0 172.12.0.0/24 is subnetted, 2 subnets 172.12.23.0 is directly connected, Ethernet0 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 will be 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 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 = 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's loopback. R3(config)#ip route 0.0.0.0 0.0.0.0 172.12.123.1 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: !!!!! 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).

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 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 = 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 R3#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is 0.0.0.0 to network 0.0.0.0 3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 is directly connected, Loopback0 172.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 S* 0.0.0.0/0 is directly connected, Ethernet0 C 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 route command rather than the next-hop IP address, it's considered a directly connected route and has an administrative distance of zero.

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 rip R1(config-router)#network172.12.0.0 R1(config-router)#network 1.0.0.0 R2(config)#router rip R2(config-router)#network 172.12.0.0 R2(config-router)#network 2.0.0.0 R3(config)#router rip R3(config-router)#network 172.12.0.0 R3(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 RIP routing table because it is a directly connected route. R1#show ip route rip R 2.0.0.0/8 [120/1] via 172.12.123.2, 00:00:01, Serial0 R 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 protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 3 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Redistributing: rip Default version control: send version 1, receive any version Interface Send Recv Triggered RIP Key-chain Loopback0 1 12 Serial0 1 12 Automatic network summarization is in effect Maximum path: 4 Routing for Networks: 1.0.0.0 172.12.0.0 Routing Information Sources: Gateway Distance Last Update 172.12.123.3 120 00:00:18 172.12.123.2 120 00:00:22 Distance: (default is 120) Our old friend show ip protocols shows a lot of information, and that includes the version defaults. By default, RIP sends version 1 updates and receives both version 1 and version 2 updates. Right now, all three routers are sending only version 1 updates, and one of the limitations with version 1 is that there is no VLSM support. Let's revisit the RIP routing table:

R1#show ip route rip R 2.0.0.0/8 [120/1] via 172.12.123.2, 00:00:01, Serial0 R 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 full 32-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 the RIP routing updates, and version 1 does not allow us to do this. To hardcode RIP to send and receive version 2 updates only, use the version 2 command under the RIP process. First, configure this command on R1 and R2 only. Make sure to clear your routing tables after configuring this command. We'll also need to run the no auto-summary command to prevent RIP from summarizing the loopback network address as it crosses a network boundary. R1(config)#router rip R1(config-router)#version 2 R1(config-router)#no auto-summary R1#clear ip route * R2(config)#router rip R2(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 rip 2.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 rip 1.0.0.0/32 is subnetted, 1 subnets R 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. The full subnet mask of /32 is now seen, since RIPv2 supports VLSM. We've also lost the route to R3's loopback. That's because R3 is sending out RIPv1 updates, which neither R2 nor R1 are going to accept. That's great to know, but how can we see this? Any RIP-related issue is going to be quickly spotted by those who know to run the command debug ip rip. Let's run it on R1 and clear the routing table afterward to speed up the troubleshooting process. R1#debug ip rip RIP protocol debugging is on R1#clear ip route * R1#undebug all (You could also use no debug ip rip here as well.)

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

"Illegal version" simply means that a packet is being received from 172.12.123.3 that the local router is not allowed to accept. This can actually be changed on the interface level as well as under the RIP process. Here is how you would configure R1's S0 interface to send and accept R2 updates only: R1(config)#int s0 R1(config-if)#ip rip send version 2 R1(config-if)#ip rip receive version 2 Knowing that can come in handy, but generally you're going to configure the RIP version for the protocol as a whole. On R3, we'll now hardcode the RIP process for version 2 and then clear the routing tables. R3(config)#router rip R3(config-router)#version 2 R3(config-router)#no auto-summary R3#clear ip route * R3 now has a full RIP routing table, as do R1 and R2. R3#show ip route rip 1.0.0.0/32 is subnetted, 1 subnets R 1.1.1.1 [120/1] via 172.12.123.1, 00:00:24, Serial0 2.0.0.0/32 is subnetted, 1 subnets R 2.2.2.2 [120/2] via 172.12.123.2, 00:00:24, Serial0 R1#show ip route rip 2.0.0.0/32 is subnetted, 1 subnets R 2.2.2.2 [120/1] via 172.12.123.2, 00:00:23, Serial0 3.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 subnets R 1.1.1.1 [120/1] via 172.12.123.1, 00:00:14, Serial0 3.0.0.0/32 is subnetted, 1 subnets R 3.3.3.3 [120/2] via 172.12.123.3, 00:00:14, Serial0 The other major BSCI topic dealing with RIP is link authentication. You can actually configure authentication for the routing updates themselves, and we've got two options - MD5 (hashed) and clear-text. We're going to configure both. Before continuing, configure an address from the 172.12.23.0 /24 subnet onto the ethernet interfaces of R2 and R3. Make sure they can ping each other. R2(config)#int e0 R2(config-if)#ip address 172.12.23.2 255.255.255.0 R2(config-if)#no shut R3(config)#int e0 R3(config-if)#ip address 172.12.23.3 255.255.255.0 R3(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!

On R1, create a key chain called RIP, and assign key 1 a key-string of CISCO. (Multiple key strings 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 RIP R1(config-keychain)#key 1 R1(config-keychain-key)#key-string CISCO Now we'll apply this key chain to the S0 interface on R1. This requires two commands, shown below. Immediately after configuring these commands, run debug ip rip. R1(config)#interface s0 R1(config-if)#ip rip authentication mode md5 R1(config-if)#ip rip authentication key-chain RIP R1#debug ip rip RIP protocol debugging is on 5d03h: 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, the authentication mode being used is a mismatch (both sides have to use the same method, md5 or clear 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 RIP R2(config-keychain)#key 1 R2(config-keychain-key)#key-string CISCO R2(config-keychain-key)#interface serial0 R2(config-if)#ip rip authentication mode md5 R2(config-if)#ip rip authentication key-chain RIP R3(config)#key chain RIP R3(config-keychain)#key 1 R3(config-keychain-key)#key-string cisco R3(config-keychain-key)#interface serial0 R3(config-if)#ip rip authentication mode md5 R3(config-if)#ip rip authentication key-chain RIP On R1, run debug ip rip to ensure that authentication has been correctly configured. R1#debug ip rip RIP protocol debugging is on R1#clear ip route * 5d03h: RIP: received packet with MD5 authentication 5d03h: RIP: received v2 update from 172.12.123.2 on Serial0 5d03h: 2.2.2.2/32 via 0.0.0.0 in 1 hops 5d03h: 3.3.3.3/32 via 0.0.0.0 in 2 hops 5d03h: 172.12.23.0/24 via 0.0.0.0 in 1 hops 5d03h: 172.12.123.0/24 via 0.0.0.0 in 1 hops 5d03h: RIP: received packet with MD5 authentication 5d03h: RIP: ignored v2 packet from 172.12.123.3 (invalid authentication)

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 are case-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 1 R2(config-keychain-key)#key-string CISCO R3(config)#key chain RIP R3(config-keychain)#key 1 R3(config-keychain-key)#key-string cisco R3's password of cisco is in lower-case. Removing that lower-case password and setting the proper password of CISCO will allow R3's routing updates to authenticate properly. R3(config)#key chain RIP R3(config-keychain)#key 1 R3(config-keychain-key)#no key-string cisco R3(config)#key chain RIP R3(config-keychain)#key 1 R3(config-keychain-key)#key-string CISCO 5d03h: RIP: received packet with MD5 authentication 5d03h: RIP: received v2 update from 172.12.123.3 on Serial0 5d03h: 2.2.2.2/32 via 0.0.0.0 in 2 hops 5d03h: 3.3.3.3/32 via 0.0.0.0 in 1 hops 5d03h: 172.12.23.0/24 via 0.0.0.0 in 1 hops 5d03h: 172.12.123.0/24 via 0.0.0.0 in 1 hops

The packets from R3 are now authenticating properly, and R1 now has a full RIP routing table again. R1#show ip route rip 2.0.0.0/32 is subnetted, 1 subnets R 2.2.2.2 [120/1] via 172.12.123.2, 00:00:05, Serial0 3.0.0.0/32 is subnetted, 1 subnets R 3.3.3.3 [120/1] via 172.12.123.3, 00:00:20, Serial0 172.12.0.0/24 is subnetted, 2 subnets R 172.12.23.0 [120/1] via 172.12.123.3, 00:00:20, 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 ip protocols. R1#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 20 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Redistributing: rip Default version control: send version 2, receive version 2 Interface Send Recv Triggered RIP Key-chain Loopback0 2 2 Serial0 2 2 RIP Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: 1.0.0.0 172.12.0.0 Routing Information Sources: Gateway Distance Last Update 172.12.123.3 120 00:00:23 172.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 equalcost paths to the network 172.12.23.0 /24.

We'll now configure clear-text authentication on the ethernet segment connecting R2 and R3. A separate key chain will be created, and the only difference in the entire configuration between clear-text and MD5 is that clear-text is specified in one of the interface commands. R2(config)#key chain ETHERNET R2(config-keychain)#key 1 R2(config-keychain-key)#key-string CCNP R2(config-keychain-key)#interface ethernet0 R2(config-if)#ip rip authentication mode ? md5 Keyed message digest text Clear text authentication R2(config-if)#ip rip authentication mode text R2(config-if)#ip rip authentication key-chain ETHERNET R3(config)#key chain ETHERNET R3(config-keychain)#key 1 R3(config-keychain-key)#key-string CCNP R3(config-keychain-key)#interface ethernet0 R3(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 and R3. 5d03h: RIP: received packet with MD5 authentication 5d03h: RIP: received v2 update from 172.12.123.1 on Serial0 5d03h: 1.1.1.1/32 via 0.0.0.0 in 1 hops 5d03h: 3.3.3.3/32 via 172.12.123.3 in 2 hops 5d03h: 172.12.123.0/24 via 0.0.0.0 in 1 hops 5d03h: RIP: received packet with text authentication CCNP 5d03h: RIP: received v2 update from 172.12.23.3 on Ethernet0 5d03h: 1.1.1.1/32 via 0.0.0.0 in 2 hops 5d03h: 3.3.3.3/32 via 0.0.0.0 in 1 hops 5d03h: 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 is used.

OSPF Hub-And-Spoke For those of you who used my Ultimate CCNA Lab Workbook to pass the CCNA, much of what follows will seem familiar - but do not skip it! Cisco will test you on every aspect of OSPF on the BSCI exam, and that includes the many details of hub-and-spoke configurations, as well as virtual links. 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 particular configuration requires that R1 is the DR and that R2 and R3 have no chance to become either the DR or the BDR. This will be done with the command ip ospf priority 0 on the serial0 interfaces of both R2 and R3. The hub will also require neighbor statements. The routers will advertise their loopback interfaces as well. Place each loopback interface into an OSPF area that matches the router number. R1(config)#router ospf 1 R1(config-router)#network 172.12.123.0 0.0.0.255 area 0 R1(config-router)#network 1.1.1.1 0.0.0.0 area 1 R1(config-router)#neighbor 172.12.123.2 R1(config-router)#neighbor 172.12.123.3 R2(config)#interface serial0 R2(config-if)#ip ospf priority 0 R2(config-if)#router ospf 1 R2(config-router)#network 172.12.123.0 0.0.0.255 area 0 R2(config-router)#network 2.2.2.2 0.0.0.0 area 2 R3(config)#interface serial0 R3(config-if)#ip ospf priority 0

R3(config-if)#router ospf 1 R3(config-router)#network 172.12.123.0 0.0.0.255 area 0 R3(config-router)#network 3.3.3.3 0.0.0.0 area 3 Run show ip ospf neighbor on each router to ensure the adjacencies have formed. R1#show ip ospf neighbor Neighbor ID 3.3.3.3 2.2.2.2 Pri State Dead Time Address Interface 0 FULL/DROTHER 00:01:43 172.12.123.3 Serial0 0 FULL/DROTHER 00:01:35 172.12.123.2 Serial0

R2#show ip ospf neighbor Neighbor ID 1.1.1.1 Pri State 1 FULL/DR Dead Time Address Interface 00:01:42 172.12.123.1 Serial0

R3#show ip ospf neighbor Neighbor ID 1.1.1.1 Pri State 1 FULL/DR Dead Time Address Interface 00:01:33 172.12.123.1 Serial0

The expected adjacencies have formed, and both R2 and R3 see R1 as the DR. R1 sees both R2 and R3 as "DROTHER"s, meaning that neither R2 nor R3 is a DR or BDR. Run show ip route ospf on R1, and ping the remote loopbacks to ensure total IP connectivity. R1#show ip route ospf 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/65] via 172.12.123.2, 00:05:43, Serial0 3.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 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/69/72 ms Take a closer look at R1's OSPF table. The routes are marked "O IA", meaning that these destinations are in different areas - these are inter-area routes. Run the same command on R2 and R3, and make sure you can ping the remote loopbacks before continuing. (Pings not shown.) R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 00:07:46, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 00:07:46, Serial0

R3#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 00:07:58, Serial0 2.0.0.0/32 is subnetted, 1 subnets 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 serial0 Serial0 is up, line protocol is up Internet Address 172.12.123.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 1.1.1.1, Interface address 172.12.123.1 No backup designated router on this network Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 Hello due in 00:00:09 Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 2 Last flood scan time is 4 msec, maximum is 4 msec Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 3.3.3.3 Adjacent 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 network type is NBMA (non-broadcast), the OSPF cost of the interface is 64, the router is the DR, there is no BDR, and there are two adjacencies. Run this command on R2 and R3 as well to see the differences from R1's output. The reason we set the OSPF interface priority on R2 and R3 to zero is to make sure that if R1 goes down, there will be no DR/BDR election in its absence. To test this, we will first set the OSPF hello-interval on all three routers' serial0 interfaces to 5 seconds, making the dead-time 20 seconds by default. Then reload R1 and see if a DR or BDR is elected while R1 is gone. R2(config)#interface serial0 R2(config-if)#ip ospf hello 5 R3(config)#int serial0 R3(config-if)#ip ospf hello 5 R1(config)#interface serial0 R1(config-if)#ip ospf hello 5 R1(config-if)#^Z R1#reload System configuration has been modified. Save? [yes/no]: y Building configuration... [OK] Proceed with reload? [confirm] While R1 is reloading, run show ip ospf neighbor on R2. R2#show ip ospf neighbor R2 is not attempting to elect a DR or BDR during R1's downtime. When R1 comes back up, run the same command.

R1#show ip ospf neighbor Neighbor ID 3.3.3.3 2.2.2.2 Pri State 0 FULL/DROTHER 0 FULL/DROTHER Dead Time Address 00:00:17 172.12.123.3 00:00:15 172.12.123.2 Interface Serial0 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 ospf neighbor: R2#show ip ospf neighbor Neighbor ID 1.1.1.1 Pri State 1 FULL/DR Dead Time Address 00:00:15 172.12.123.1 Interface Serial0

R3#show ip ospf neighbor Neighbor ID 1.1.1.1 Pri State 1 FULL/DR Dead Time Address Interface 00:00:17 172.12.123.1 Serial0

By default, the highest IP address on a loopback interface will be the OSPF RID of a router, even if that loopback interface is not OSPF-enabled. If there is no loopback, the highest IP address assigned to a physical interface on the router becomes the RID, even if that interface is not OSPF-enabled. We'll now change the OSPF RID on R1 to 11.11.11.11. Use the router-id command to do this as shown below. To make this command take effect, you must either reload the router or clear the OSPF processes; doing either will tear down any existing OSPF adjacencies. Cisco is nice enough to mention this after you run the command. Also note that the default answer to the question you're asked when clearing the process is "no". That's an excellent tipoff in the real world that you're about to do something that maybe, just maybe, you shouldn't be doing. R1(config)#router ospf 1 R1(config-router)#router-id 11.11.11.11 Reload or use "clear ip ospf process" command, for this to take effect R1#clear ip ospf process Reset ALL OSPF processes? [no]: yes 5d04h: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0 from 2WAY to DOWN, Neighbor Down: Interface down or detached 5d04h: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0 from 2WAY to DOWN, Neighbor Down: Interface down or detached 5d04h: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0 from LOADING to FULL, Loading Done 5d04h: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0 from LOADING to FULL, Loading Done R1#show ip ospf interface seria0 Serial0 is up, line protocol is up Internet Address 172.12.123.1/24, Area 0 Process ID 1, Router ID 11.11.11.11, Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 11.11.11.11, Interface address 172.12.123.1

R1's OSPF RID has been successfully changed. Do the same for R2 and R3, changing their IDs to 22.22.22.22 and 33.33.33.33, respectively. Don't forget to reload the router or clear the OSPF processes after doing so. R2(config)#router ospf 1 R2(config-router)#router-id 22.22.22.22 Reload or use "clear ip ospf process" command, for this to take effect R2(config-router)#^Z R2#clear ip ospf process Reset ALL OSPF processes? [no]: yes R3(config)#router ospf 1 R3(config-router)#router-id 33.33.33.33 Reload or use "clear ip ospf process" command, for this to take effect R3(config-router)#^Z R3#clear ip ospf process Reset ALL OSPF processes? [no]: y We will now add an area, placing the directly connected serial interfaces of R3 and R4 into OSPF Area 34. R4's loopback address of 4.4.4.4 will be placed into Area 4.

R3(config)#router ospf 1 R3(config-router)#network 10.2.2.0 0.0.0.255 area 34 R4(config)#router R4(config-router)#network 10.2.2.0 R4(config-router)#network 4.4.4.4 0.0.0.0 area 4 Verify the adjacency on R3. R3#show ip ospf neighbor Neighbor ID Pri State 11.11.11.11 1 FULL/DR 4.4.4.4 1 FULL/ 00:00:35 Dead Time Address 00:00:15 172.12.123.1 10.2.2.4 Serial1 Interface Serial0 ospf 0.0.0.255 area 1 34

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 the OSPF network type point-to-point. By definition, a point-to-point network can only have two interfaces connected to it, eliminating the need for a DR or BDR. Verify this network type with the command show ip ospf interface serial1. There is no reference to a DR or BDR in this command output. R3#show ip ospf interface serial1 Serial1 is up, line protocol is up Internet Address 10.2.2.3/24, Area 34 Process ID 1, Router ID 33.33.33.33, Network Type POINT_TO_POINT, Cost:64 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:02 Index 1/3, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent 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. R3#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets 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 subnets O IA 2.2.2.2 [110/65] via 172.12.123.2, 00:23:16, Serial0

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

OSPF dictates that every OSPF area must contain a router that has a physical or logical interface in 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 to create 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 transit area, and this transit area cannot be a stub or total stub area.

The command used to build the virtual link is simple, but make sure you use the remote router's OSPF RID in the command, not the IP address of the interface found in the transit area. For R4 to successfully build a virtual link to R3, the dotted decimal value in the command must be R3's OSPF RID. R4(config)#router ospf 1 R4(config-router)#area 34 virtual-link 33.33.33.33 R3(config)#router ospf 1 R3(config-router)#area 34 virtual-link 4.4.4.4 R3(config-router)# 5d05h: %OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must 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 both sides, and when you start configuring the remote router, you will probably see this message. You may even see it just a second after you configure the router, as we did here. The only time this should concern you is if you keep getting the message over and over again after configuring the virtual 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-link to verify the configuration. The virtual link must have an adjacency state of FULL. R3, R2, and R1 should all now see R4's loopback and be able to ping it. R3#show ip ospf virtual-link Virtual Link OSPF_VL0 to router 4.4.4.4 is up Run as demand circuit DoNotAge LSA allowed. Transit area 34, via interface Serial1, Cost of using 64 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:04 Adjacency State FULL (Hello suppressed) Index 2/3, retransmission queue length 0, number of retransmission 1 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 1, maximum is 1 Last retransmission scan time is 0 msec, maximum is 0 msec R3#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 00:02:57, Serial0 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/65] via 172.12.123.2, 00:02:57, Serial0 4.0.0.0/32 is subnetted, 1 subnets O IA 4.4.4.4 [110/65] via 10.2.2.4, 00:02:57, Serial1

R3#ping 4.4.4.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/34/36 ms

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 while still allowing full IP connectivity, and also lessens the load on a router's resources by keeping the table small. To configure this section, you should have the entire OSPF Hub-And-Spoke configuration in place, EXCEPT that there will be no Area 4 on R4, and there will be no virtual link between R3 and R4. If you have just completed that lab, run the following commands to remove the area and the virtual link.

R3(config)#router ospf 1 R3(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

R4(config)#router ospf 1 R4(config-router)#no area 34 virtual-link 33.33.33.33 R4(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 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/129] via 10.2.2.3, 00:02:18, Serial0 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/129] via 10.2.2.3, 00:02:18, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 10.2.2.3, 00:02:18, Serial0 172.12.0.0/24 is subnetted, 1 subnets O IA 172.12.123.0 [110/128] via 10.2.2.3, 00:02:18, Serial0 Ping each of the remote destinations, including R1, R2, and R3's serial0 interfaces. You should have 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 every time a packet has to be routed is an unnecessary load on the router's resources, since the nexthop address is going to be the same address every time. There could be 100 routes in this table and the next-hop would always be the same, since there's only one interface on R4 that is currently enabled. Before addressing that topic, let's bring in some more routes via route redistribution. We're going to create three additional loopbacks on R1 and redistribute them into OSPF with the redistribute connected command. R1(config)#int loopback 12 R1(config-if)#ip address 12.12.12.12 255.255.255.255 R1(config-if)#int loopback 13 R1(config-if)#ip address 13.13.13.13 255.255.255.255 R1(config-if)#int loopback 14 R1(config-if)#ip address 14.14.14.14 255.255.255.255 R1(config)#router ospf 1 R1(config-router)#redistribute connected % Only classful networks will be redistributed R1(config-router)#redistribute connected subnets Here's the first of several route redistribution details you'll need to keep in mind! With OSPF, if you don't specify the "subnets" option, only classful networks will be redistributed. The router was kind enough to remind us of that, but it's doubtful the BSCI exam will be.

This redistribution makes R1 an Autonomous System Border Router (ASBR), verified by show ip ospf. R1#show ip ospf Routing Process "ospf 1" with ID 11.11.11.11 Supports only single TOS(TOS0) routes Supports opaque LSA It is an area border and autonomous system boundary router Redistributing External Routes from, connected, includes subnets in redistribution < output truncated here> Let's look at R4's routing table. R4#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/129] via 10.2.2.3, 00:01:27, Serial0 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/129] via 10.2.2.3, 00:01:27, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 10.2.2.3, 00:01:27, Serial0 172.12.0.0/24 is subnetted, 1 subnets O IA 172.12.123.0 [110/128] via 10.2.2.3, 00:01:27, Serial0 12.0.0.0/32 is subnetted, 1 subnets O E2 12.12.12.12 [110/20] via 10.2.2.3, 00:01:27, Serial0 13.0.0.0/32 is subnetted, 1 subnets O E2 13.13.13.13 [110/20] via 10.2.2.3, 00:01:27, Serial0 14.0.0.0/32 is subnetted, 1 subnets O E2 14.14.14.14 [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 R1 are 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 local router 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 must be E1 routes, and this is done at the ASBR with the redistribute command. R1(config)#router ospf 1 R1(config-router)#no redistribute connected subnets R1(config-router)#redistribute connected subnets metric-type ? 1 Set OSPF External Type 1 metrics 2 Set OSPF External Type 2 metrics R1(config-router)#redistribute connected subnets metric-type 1 Look at R4's routing table again. R4#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/129] via 10.2.2.3, 00:06:36, Serial0 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/129] via 10.2.2.3, 00:06:36, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 10.2.2.3, 00:06:36, Serial0 172.12.0.0/24 is subnetted, 1 subnets

O IA 172.12.123.0 [110/128] via 10.2.2.3, 00:06:36, Serial0 12.0.0.0/32 is subnetted, 1 subnets O E1 12.12.12.12 [110/148] via 10.2.2.3, 00:00:40, Serial0 13.0.0.0/32 is subnetted, 1 subnets O E1 13.13.13.13 [110/148] via 10.2.2.3, 00:00:40, Serial0 14.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 remote loopbacks, 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 1 R1(config-router)#no redistribute connected metric-type 1 subnets R1(config-router)#redistribute connected subnets You know the difference between E1 and E2 routes, you know the default, and you know how to change the default - but no matter what metric type we use, the next-hop for all three of those external 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 by configuring Area 34 as a stub area. A stub area's ABR - in this case, R3 - will generate a default route that will take the place of all external routes. To configure Area 34 as a stub area, run the area 34 stub command on both R3 and R4. All routers in a stub area must agree that this is indeed a stub area, or adjacencies will be dropped between the routers that do not agree on this. R3(config)#router ospf 1 R3(config-router)#area 34 stub 5d05h: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Serial1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset R4(config)#router ospf 1 R4(config-router)#area 34 stub R4#show ip ospf neighbor Neighbor ID 33.33.33.33 Pri State 1 FULL/ Dead Time Address 00:00:37 10.2.2.3 Interface Serial0

The adjacency between R3 and R4 went down immediately when Area 34 was configured as stub 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. R4#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/129] via 10.2.2.3, 00:00:04, Serial0 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/129] via 10.2.2.3, 00:00:04, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 10.2.2.3, 00:00:04, Serial0 172.12.0.0/24 is subnetted, 1 subnets

O IA 172.12.123.0 [110/128] via 10.2.2.3, 00:00:04, Serial0 O*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 pinging 12.12.12.12, 13.13.13.13, and 14.14.14.14. - you still have full IP connectivity, but the routing table 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 configuring Area 34 as a total stub area. To do this, add no-summary to 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 a good detail to remember that it only has to be configured on the ABR.) R3(config)#router ospf 1 R3(config-router)#area 34 stub no-summary Now look at R4's OSPF routing table. R4#show ip route ospf O*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 single default OSPF route with which to reach those seven destinations. Ping all the loopback on all the remote routers from R4. You still have total IP connectivity, and the load on R4 is much lighter since it has a much smaller routing table.

We'll now look at the two different methods by which OSPF routers can perform route summarization. (You MUST master the details of thes two commands before taking and passing the BSCI exam.) Before starting the next part of this lab, remove all stub routing commands from R3 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 Loopback12 ip address 12.12.12.12 255.0.0.0 ! interface Loopback13 ip address 13.13.13.13 255.0.0.0 ! interface Loopback14 ip 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 all routers see all four of these new routes. R1(config)#router ospf 1 R1(config-router)#network 12.0.0.0 0.255.255.255 a 1 R1(config-router)#network 13.0.0.0 0.255.255.255 a 1 R1(config-router)#network 14.0.0.0 0.255.255.255 a 1 R1(config-router)#network 15.0.0.0 0.255.255.255 a 1

R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 00:38:59, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 00:38:59, Serial0 10.0.0.0/24 is subnetted, 1 subnets O IA 10.2.2.0 [110/128] via 172.12.123.3, 00:38:59, Serial0 12.0.0.0/32 is subnetted, 1 subnets O IA 12.12.12.12 [110/65] via 172.12.123.1, 00:18:52, Serial0 13.0.0.0/32 is subnetted, 1 subnets O IA 13.13.13.13 [110/65] via 172.12.123.1, 00:18:42, Serial0 14.0.0.0/32 is subnetted, 1 subnets O IA 14.14.14.14 [110/65] via 172.12.123.1, 00:18:32, Serial0 15.0.0.0/32 is subnetted, 1 subnets 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 correct summary 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 the area 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 1 R1(config-router)#area 1 range 12.0.0.0 252.0.0.0 R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 00:43:37, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 00:43:37, Serial0 10.0.0.0/24 is subnetted, 1 subnets O IA 10.2.2.0 [110/128] via 172.12.123.3, 00:43:37, Serial0 O 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 redistribute command. interface Loopback16 ip address 16.16.16.16 255.0.0.0 ! interface Loopback17 ip address 17.17.17.17 255.0.0.0 ! interface Loopback18 ip address 18.18.18.18 255.0.0.0 ! interface Loopback19 ip address 19.19.19.19 255.0.0.0 R1(config)#router ospf 1 R1(config-router)#redistribute connected subnets

These four routes are seen on the downstream routers as External Type-2, the default for routes redistributed into OSPF. R2#show ip route ospf O E2 17.0.0.0/8 [110/20] via 172.12.123.1, 00:00:07, Serial0 O 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 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 00:00:07, Serial0 O E2 19.0.0.0/8 [110/20] via 172.12.123.1, 00:00:07, Serial0 O E2 18.0.0.0/8 [110/20] via 172.12.123.1, 00:00:07, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 00:00:07, Serial0 10.0.0.0/24 is subnetted, 1 subnets O IA 10.2.2.0 [110/128] via 172.12.123.3, 00:00:08, Serial0 O 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 summaryaddress. You can probably do this summarization in your head, but do so before continuing with the lab. : ) R1(config)#router ospf 1 R1(config-router)#summary-address 16.0.0.0 252.0.0.0 Check the downstream routers' OSPF tables. R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 00:04:48, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 00:04:48, Serial0 10.0.0.0/24 is subnetted, 1 subnets O IA 10.2.2.0 [110/128] via 172.12.123.3, 00:04:48, Serial0 O E2 16.0.0.0/6 [110/20] via 172.12.123.1, 00:00:05, Serial0 O 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 still marked as an E2 route. To complete the lab, go back to R1 and look at its OSPF table. R1#show ip route ospf 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 00:06:33, Serial0 10.0.0.0/24 is subnetted, 1 subnets O IA 10.2.2.0 [110/128] via 172.12.123.3, 00:06:33, Serial0 O 16.0.0.0/6 is a summary, 00:01:51, Null0 O 12.0.0.0/6 is a summary, 00:06:34, Null0

When you configure summary routes in OSPF, a route to null0 will be installed into the OSPF routing table. This helps to prevent routing loops. Any packets destined for the routes that have been summarized will have a longer match in the routing table.... R1#show ip route Gateway of last resort is not set C C 17.0.0.0/8 is directly connected, Loopback17 16.0.0.0/8 is directly connected, Loopback16 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 2.0.0.0/32 is subnetted, 1 subnets S 2.2.2.2 [1/0] via 172.12.123.2 C 19.0.0.0/8 is directly connected, Loopback19 C 18.0.0.0/8 is directly connected, Loopback18 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 00:07:49, Serial0 B 21.0.0.0/8 [200/0] via 172.12.123.3, 05:10:42 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0 10.0.0.0/24 is subnetted, 1 subnets O IA 10.2.2.0 [110/128] via 172.12.123.3, 00:07:52, Serial0 C 12.0.0.0/8 is directly connected, Loopback12 C 13.0.0.0/8 is directly connected, Loopback13 C 14.0.0.0/8 is directly connected, Loopback14 C 15.0.0.0/8 is directly connected, Loopback15 O 16.0.0.0/6 is a summary, 00:03:10, Null0 O 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 route will be dropped.

EIGRP

Before beginning this lab, each router should have a loopback using its own number for each octet, 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 serial interfaces. Enable EIGRP on all loopback interfaces except R1. Disable EIGRP autosummarization on all routers. R1(config)#router eigrp 100 R1(config-router)#no auto-summary R1(config-router)#network 172.12.123.0 0.0.0.255 R2(config)#router eigrp 100 R2(config-router)#no auto-summary R2(config-router)#network 172.12.123.0 0.0.0.255 R2(config-router)#network 172.12.23.0 0.0.0.255 R2(config-router)#network 2.2.2.2 0.0.0.0 R3(config)#router eigrp 100 R3(config-router)#no auto-summary R3(config-router)#network 172.12.123.0 0.0.0.255 R3(config-router)#network 172.12.23.0 0.0.0.255 R3(config-router)#network 10.2.2.0 0.0.0.255 R3(config-router)#network 3.3.3.3 0.0.0.0 R4(config)#router eigrp 100 R4(config-router)#no auto-summary R4(config-router)#network 10.2.2.0 0.0.0.255 ^ % Invalid input detected at '^' marker. R4(config-router)#network 10.2.2.0 R4(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 into some older IOS versions that do not allow you to do this, so I thought I'd remind you that not every EIGRP deployment in the real world uses them. You'll see that VLSM support is still present, though. Run show ip route eigrp 100 on R1. R1#show ip route eigrp 100 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/2297856] via 172.12.123.2, 00:04:13, Serial0 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/2297856] via 172.12.123.3, 00:04:03, Serial0 4.0.0.0/32 is subnetted, 1 subnets D 4.4.4.4 [90/2809856] via 172.12.123.3, 00:03:02, Serial0

172.12.0.0/24 is subnetted, 2 subnets 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, Serial0 10.0.0.0/24 is subnetted, 1 subnets D 10.2.2.0 [90/2681856] via 172.12.123.3, 00:04:09, Serial0 D Quite a bit of this is familiar to you from your CCNA studies, but let's review. These are all internal EIGRP routes and therefore have an AD of 90. The number in the brackets following the AD is the feasible distance. Finally, we see two paths to 172.12.23.0 /24. Why? Because the metric is exactly the same (2195456), and EIGRP performs equal-cost load-sharing over up to four paths by default. We can change this default value with the maximum-paths command, as shown here and then verified with show ip protocols. (This command also verifies that automatic summarization is not in effect - we turned it off with no auto-summary.) R1(config)#router eigrp 100 R1(config-router)#maximum-paths 6 R1#show ip protocols Routing Protocol is "eigrp 100" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 EIGRP maximum hopcount 100 EIGRP maximum metric variance 1 Redistributing: eigrp 100 Automatic network summarization is not in effect Maximum path: 6 Routing for Networks: 172.12.123.0/24 Routing Information Sources: Gateway Distance Last Update 172.12.123.3 90 00:00:06 172.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 is the more direct path directly to R3 through the frame and then on to R4, but another possible path is to go through R2 through the frame cloud, then to R3 through the ethernet segment, then to R4. But is this a valid path? We can find out by looking in the EIGRP topology table on R1. R1#show ip eigrp topology IP-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 2809856 via 172.12.123.3 (2809856/2297856), Serial0 via 172.12.123.2 (2835456/2323456), Serial0 P 3.3.3.3/32, 1 successors, FD is 2297856 via 172.12.123.3 (2297856/128256), Serial0 via 172.12.123.2 (2323456/409600), Serial0 P 2.2.2.2/32, 1 successors, FD is 2297856 via 172.12.123.2 (2297856/128256), Serial0 via 172.12.123.3 (2323456/409600), Serial0

P 10.2.2.0/24, 1 successors, FD is 2681856 via 172.12.123.3 (2681856/2169856), Serial0 via 172.12.123.2 (2707456/2195456), Serial0 P 172.12.23.0/24, 2 successors, FD is 2195456 via 172.12.123.3 (2195456/281600), Serial0 via 172.12.123.2 (2195456/281600), Serial0 P 172.12.123.0/24, 1 successors, FD is 2169856 via 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 is the feasible successor. (Note that since R1 is using two equal-cost paths to reach 172.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-sharing with the variance command. We need to come up with a number that when multiplied by the metric for the successor is greater than the metric of the feasible successor. It's a lot harder than it 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 variance command should do the job. Configure that value on R1 and clear the routing table. R1(config)#router eigrp 100 R1(config-router)#variance 2 R1#show ip route eigrp 100 2.0.0.0/32 is subnetted, 1 subnets 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 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/2297856] via 172.12.123.3, 00:00:12, Serial0 [90/2323456] via 172.12.123.2, 00:00:12, Serial0 4.0.0.0/32 is subnetted, 1 subnets 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 172.12.0.0/24 is subnetted, 2 subnets D 172.12.23.0 [90/2195456] via 172.12.123.3, 00:00:12, Serial0 [90/2195456] via 172.12.123.2, 00:00:12, Serial0 10.0.0.0/24 is subnetted, 1 subnets 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 to the metrics; if you want the paths participating in unequal-cost load-sharing to carry roughly the same percentage of the load, run the command traffic-share balanced under the EIGRP process. R1(config)#router eigrp 100 R1(config-router)#traffic-share balanced

Configure additional loopback interfaces on R1:

Loopback 11, ip address 11.11.11.11 /32 Loopback 12, ip address 12.12.12.12 /32 Loopback 13, ip address 13.13.13.13 /32 We'll now redistribute all loopback interfaces into EIGRP AS 100 with the redistribute command. The options will be different than what we saw with OSPF. There is no "subnets" option, but we must configure a seed metric for routes being redistributed into EIGRP or the redistribution will fail. 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 100 R1(config-router)#redistribute connected ? metric Metric for redistributed routes route-map Route map reference <cr> R1(config-router)#redistribute connected metric ? <1-4294967295> Bandwidth metric in Kbits per second R1(config-router)#redistribute connected metric 1544 ? <0-4294967295> IGRP delay metric, in 10 microsecond units R1(config-router)#redistribute connected metric 1544 100 ? <0-255> IGRP reliability metric where 255 is 100% reliable R1(config-router)#redistribute connected metric 1544 100 255 ? <1-255> IGRP Effective bandwidth metric (Loading) where 255 is 100% loaded R1(config-router)#redistribute connected metric 1544 100 255 1 ? <1-4294967295> 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. R3#show ip route eigrp 100 1.0.0.0/32 is subnetted, 1 subnets D EX 1.1.1.1 [170/2195456] via 172.12.123.1, 00:04:49, Serial0 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/409600] via 172.12.23.2, 00:29:08, Ethernet0 4.0.0.0/32 is subnetted, 1 subnets D 4.4.4.4 [90/2297856] via 10.2.2.4, 00:27:56, Serial1 11.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 subnets D EX 12.12.12.12 [170/2195456] via 172.12.123.1, 00:04:49, Serial0 13.0.0.0/32 is subnetted, 1 subnets D EX 13.13.13.13 [170/2195456] via 172.12.123.1, 00:04:49, Serial0 14.0.0.0/32 is subnetted, 1 subnets D EX 14.14.14.14 [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 that these are EXternal routes, and they have a higher administrative distance than internal

routes. The AD of EIGRP External routes is 170, as shown in the brackets for each of these routes. We're now going to add four more loopbacks to R1, but these will be advertised into EIGRP. Add the 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 100 R1(config-router)#network 16.16.16.16 0.0.0.0 R1(config-router)#network 17.17.17.17 0.0.0.0 R1(config-router)#network 18.18.18.18 0.0.0.0 R1(config-router)#network 19.19.19.19 0.0.0.0 R3's EIGRP routing table now looks like this: R3#show ip route eigrp 17.0.0.0/32 is subnetted, 1 subnets D 17.17.17.17 [90/2297856] via 172.12.123.1, 00:00:29, Serial0 16.0.0.0/32 is subnetted, 1 subnets D 16.16.16.16 [90/2297856] via 172.12.123.1, 00:00:36, Serial0 1.0.0.0/32 is subnetted, 1 subnets D EX 1.1.1.1 [170/2195456] via 172.12.123.1, 00:11:40, Serial0 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/409600] via 172.12.23.2, 00:35:58, Ethernet0 19.0.0.0/32 is subnetted, 1 subnets D 19.19.19.19 [90/2297856] via 172.12.123.1, 00:00:08, Serial0 18.0.0.0/32 is subnetted, 1 subnets D 18.18.18.18 [90/2297856] via 172.12.123.1, 00:00:22, Serial0 4.0.0.0/32 is subnetted, 1 subnets D 4.4.4.4 [90/2297856] via 10.2.2.4, 00:34:46, Serial1 11.0.0.0/32 is subnetted, 1 subnets D EX 11.11.11.11 [170/2195456] via 172.12.123.1, 00:11:40, Serial0 12.0.0.0/32 is subnetted, 1 subnets D EX 12.12.12.12 [170/2195456] via 172.12.123.1, 00:11:40, Serial0 13.0.0.0/32 is subnetted, 1 subnets D EX 13.13.13.13 [170/2195456] via 172.12.123.1, 00:11:41, Serial0 14.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 that summary.

To perform manual route summarization, write out the network addresses in binary and then determine the point at which the addresses no longer have a bit in common. For these four addresses, it will be enough to write out the first octet in binary: 16 17 18 19 00010000 00010001 00010010 00010011

Working from left to right, the common bits are the first six bits - 000100xx. In decimal, this value is 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 - the resulting 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 routing process. Configure the following on R1's serial interface: R1(config)#interface serial0 R1(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 configured 02: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 : new adjacency 02:40:17: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.3 (Serial0) is up: new adjacency There's an immediate side effect here that most books leave out. Your EIGRP adjacencies are going 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 production network, you may want to do this during non-peak hours. The timestamps on the above commands indicate that the adjacencies were down for about 27 seconds over the NBMA network. That's about 30 minutes in end-user time. ;) Check R3's EIGRP routing table. R3#show ip route eigrp 1.0.0.0/32 is subnetted, 1 subnets D EX 1.1.1.1 [170/2195456] via 172.12.123.1, 00:01:46, Serial0 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/409600] via 172.12.23.2, 00:50:24, Ethernet0 4.0.0.0/32 is subnetted, 1 subnets D 4.4.4.4 [90/2297856] via 10.2.2.4, 00:49:11, Serial1 11.0.0.0/32 is subnetted, 1 subnets D EX 11.11.11.11 [170/2195456] via 172.12.123.1, 00:01:46, Serial0 12.0.0.0/32 is subnetted, 1 subnets D EX 12.12.12.12 [170/2195456] via 172.12.123.1, 00:01:46, Serial0 13.0.0.0/32 is subnetted, 1 subnets D EX 13.13.13.13 [170/2195456] via 172.12.123.1, 00:01:46, Serial0 14.0.0.0/32 is subnetted, 1 subnets

D EX 14.14.14.14 [170/2195456] via 172.12.123.1, 00:01:46, Serial0 D 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 by the summary route shown at the bottom of the routing table. Notice the mask is /5, which is prefix notation for 248.0.0.0. We'll now configure link authentication on the adjacency over the Ethernet segment. Configure a key chain called EIGRP on both routers, use key number 1, and use the key-string BSCI. Run show key chain on both routers to see all key chains present on the router. R2(config)#key chain EIGRP R2(config-keychain)#key 1 R2(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 EIGRP R3(config-keychain)#key 1 R3(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 of the command, not the beginning. R2(config)#interface ethernet0 R2(config-if)#ip authentication key-chain eigrp 100 EIGRP R2(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 ethernet0 R3(config-if)#ip authentication key-chain eigrp 100 EIGRP R3(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 neighbor to verify the ethernet segment adjacency is up. R2#show ip eigrp neighbor IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO (sec) (ms)

0 172.12.23.3 1 172.12.123.1

Et0 Se0

14 156

00:02:40 423 00:18:01 88

2538 528

R3#show ip eigrp neighbor IP-EIGRP neighbors for process 100 H Address Interface Hold (sec) (ms) 0 172.12.23.2 Et0 14 1 172.12.123.1 Se0 165 2 10.2.2.4 Se1 12

Uptime SRTT RTO 00:03:31 20 200 00:18:48 97 582 01:06:14 35 210

BGP

R1, R2, and R3 will all be in BGP AS 123. The Frame Relay cloud should be in place and all routers 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 123 R1(config-router)#no synchronization R1(config-router)#neighbor 172.12.123.2 remote-as 123 R1(config-router)#neighbor 172.12.123.3 remote-as 123 R2(config)#router bgp 123 R2(config-router)#no synchronization R2(config-router)#neighbor 172.12.123.1 remote-as 123 R3(config)#router bgp 123 R3(config-router)#no synchronization R3(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 neighbor on all three routers. You'll notice you get a lot of information with the show neighbor command! It's important to know the information generated by each command, and in the real world I find the summary command to be more than enough to diagnose basic BGP connectivity issues. R1#show ip bgp summary BGP router identifier 1.1.1.1, local AS number 123 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down 172.12.123.2 4 123 9 9 1 0 0 0 0:00:36 172.12.123.3 4 123 8 8 1 0 0 0 0:00:36 R1#show ip bgp neighbor BGP neighbor is 172.12.123.2, remote AS 123, internal link

BGP version 4, remote router ID 2.2.2.2 BGP state = Established, up for 00:01:57 Last 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 be directly connected. Place R4 into BGP AS 4 and configure a peer relationship between R3 and R4.

R3(config)#router bgp 123 R3(config-router)#neighbor 10.2.2.4 remote-as 4 R4(config)#router bgp 4 R4(config-router)#no synch R4(config-router)#neighbor 10.2.2.3 remote-as 123 Verify with show ip bgp summary. R3#show ip bgp summary BGP router identifier 3.3.3.3, local AS number 123 BGP table version is 1, main routing table version 1 Neighbor 10.2.2.4 172.12.123.1 V AS MsgRcvd 4 4 3 4 123 28 MsgSent TblVer InQ OutQ Up/Down 4 1 0 0 00:00:07 30 1 0 0 00:20:15

Configure R4 to advertise its loopback address via BGP. R4(config)#router bgp 4 R4(config-router)#network 4.4.4.4 mask 255.255.255.255 View the BGP routing table on R3. R3#show ip bgp BGP table version is 2, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *> 4.4.4.4/32 Next Hop 10.2.2.4 Metric 0 LocPrf Weight Path 0 4i

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 bgp BGP table version is 1, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network * i4.4.4.4/32 Next Hop 10.2.2.4 Metric 0 LocPrf 100 Weight 0 Path 4i

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-hop IP address is retained. That's what happened here - R3 learned about the route from an eBGP neighbor, R4, and then advertised it to an iBGP neighbor, R1. Therefore, the next-hop IP address 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 of the network 10.2.2.4, so it does not know where the next-hop IP address is. Under those circumstances, the path is unusable. R3 can serve as the next-hop address for routes sent to R1 by configuring the next-hop self command 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 bgp BGP table version is 2, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i4.4.4.4/32 Next Hop 172.12.123.3 Metric LocPrf 0 100 Weight 0 Path 4i

The next-hop address has changed to 172.12.123.3, and since this is a directly connected network from R1's viewpoint, the path is now valid. Let's now go to R2 and check the BGP table. R2#show ip bgp < no output > We have a bigger problem here - the route to R4's loopback isn't in R2's table at all. This is due to another BGP limitation, this one on iBGP neighbors. By default, a BGP speaker cannot learn a route from an iBGP neighbor and then advertise it to another iBGP neighbor. R1 learned about the route from R3, an iBGP neighbor; therefore, R1 cannot advertise the route to R3.

With this network, we've got two choices. We can make R1 a route reflector, which will allow R1 to advertise iBGP-learned routes to other iBGP neighbors. We could also create an iBGP peering between R2 and R3. We're going to do both, starting with the route reflector. Configure both R2 and R3 as clients of the route reflector R1. R1(config)#router bgp 123 R1(config-router)#neighbor 172.12.123.2 route-reflector-client 1d19h: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Down RR client config change R1(config-router)#neighbor 172.12.123.3 route-reflector-client 1d19h: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Down RR client config change 1d19h: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Up 1d19h: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Up Notice that the existing adjacencies came down when R2 and R3 were configured as RR clients. Also note that no configuration is necessary on the clients themselves. The entire RR procedure is transparent to the clients. View R2's BGP routing table. R2#show ip bgp BGP table version is 2, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i4.4.4.4/32 Next Hop 172.12.123.3 Metric 0 LocPrf 100 Weight 0 Path 4i

The route is now in R2's routing table and is valid. Advertise R2's loopback into BGP and check R3's routing table to make sure it can be seen. R2(config)#router bgp 123 R2(config-router)#network 2.2.2.2 mask 255.255.255.255 R3#show ip bgp BGP table version is 3, local router ID is 3.3.3.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i2.2.2.2/32 *> 4.4.4.4/32 Next Hop 172.12.123.2 10.2.2.4 Metric 0 0 LocPrf 100 Weight 0 0 Path i 4i

Does R4 have an entry for R2's loopback? R4#show ip bgp BGP table version is 3, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

Network *> 2.2.2.2/32 *> 4.4.4.4/32

Next Hop 10.2.2.3 0.0.0.0

Metric 0

LocPrf

Weight 0 32768

Path 123 i i

It does. Note the default weight for a locally originated route. Remove the route reflector configuration from R1 and build an iBGP peering between R2 and R3. This gives us a full mesh in AS 123.

R1(config)#router bgp 123 R1(config-router)#no neighbor 172.12.123.2 route-reflector-client 1d19h: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Down RR client config change R1(config-router)#no neighbor 172.12.123.3 route-reflector-client 1d19h: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Down RR client config change R2(config)#router bgp 123 R2(config-router)#neighbor 172.12.123.3 remote-as 123 R3(config)#router bgp 123 R3(config-router)#neighbor 172.12.123.2 remote-as 123 Verify the peering with show ip bgp summary. Notice that as we add routes to the BGP AS, more and more information appears in the output of this command. R3#show ip bgp summ BGP router identifier 3.3.3.3, local AS number 123 BGP table version is 5, main routing table version 5

2 network entries and 2 paths using 266 bytes of memory 2 BGP path attribute entries using 120 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP activity 3/7 prefixes, 3/1 paths, scan interval 60 secs Neighbor V 10.2.2.4 4 172.12.123.1 4 172.12.123.2 4 AS MsgRcvd MsgSent TblVer InQ OutQ 4 28 31 5 0 0 123 61 65 5 0 0 123 5 5 5 0 0 Up/Down 00:24:37 00:01:12 00:00:23

Note that R2's BGP table now shows 10.2.2.4 as the next-hop to reach 4.4.4.4. To remedy this, configure R3 as the next-hop address for routes sent to R2. R2#show ip bgp BGP table version is 5, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *> 2.2.2.2/32 * i4.4.4.4/32 Next Hop 0.0.0.0 10.2.2.4 Metric 0 0 LocPrf 100 Weight 32768 0 Path i 4i

R3(config)#router bgp 123 R3(config-router)#neighbor 172.12.123.2 next-hop-self R2#show ip bgp BGP table version is 6, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *> 2.2.2.2/32 *>i4.4.4.4/32 Next Hop 0.0.0.0 172.12.123.3 Metric 0 0 LocPrf 100 Weight 32768 0 Path i 4i

On both R2 and R3, advertise the ethernet segment that connects these two routers. R2(config)#router bgp 123 R2(config-router)#network 172.12.23.0 mask 255.255.255.0 R3(config)#router bgp 123 R3(config-router)#network 172.12.23.0 mask 255.255.255.0 R1's routing table will display two routes to 172.12.23.0/24. R1#show ip bgp BGP table version is 10, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop *>i2.2.2.2/32 172.12.123.2 *>i4.4.4.4/32 172.12.123.3 * i172.12.23.0/24 172.12.123.3 *>i 172.12.123.2 Metric 0 0 0 0 LocPrf 100 100 100 100 Weight 0 0 0 0 Path i 4i i i

The path through 172.12.123.2 is currently preferred, as indicated by the ">" symbol. We have several options on how to change this, and since weight is the first BGP path attribute considered in the best path selection process, we'll use that attribute to prefer the path through R3. Configure R1 to assign a weight of 200 to all routes received from R3. R1(config)#router bgp 123 R1(config-router)#neighbor 172.12.123.3 weight 200 Perform a "soft reset" with clear ip bgp * soft (or a hard reset with clear ip bgp, but this will reset the peerings), and check R1's BGP entries for this network with the command show ip bgp 172.12.23.0. R1#show ip bgp 172.12.23.0 BGP routing table entry for 172.12.23.0/24, version 12 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer Local 172.12.123.3 from 172.12.123.3 (3.3.3.3) Origin IGP, metric 0, localpref 100, weight 200, valid, internal, best Local 172.12.123.2 from 172.12.123.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal The word "best" now appears under 172.12.123.3. Run show ip bgp and you'll see that the preferred path to 172.12.23.0 now has a next-hop of 172.12.123.3. To gain first-hand knowledge of how to use the LOCAL_PREF and MED values, we're going to reconfigure the network. Remove the BGP configurations from all routers before continuing. R1 will now be in BGP AS 1. Add five loopbacks to R1 as shown below and advertise all five via BGP.

The other routers are in AS 234. Place R4's ethernet0 interface into the same subnet as R2 and R3; ensure IP connectivity between these three interfaces. Close the directly connected serial interfaces on R3 and R4. The peerings will be as follows: R1 - R2, through the frame. R1 - R3, through the frame. R2 - R4, through the Ethernet R3 - R4, through the Ethernet

R1 Configuration: R1(config)#int loopback 5 R1(config-if)#ip address 5.5.5.5 255.255.255.255 R1(config-if)#int loopback6 R1(config-if)#ip address 6.6.6.6 255.255.255.255 R1(config-if)#int loopback7 R1(config-if)#ip address 7.7.7.7 255.255.255.255 R1(config-if)#int loopback8 R1(config-if)#ip address 8.8.8.8 255.255.255.255 R1(config-if)#int loopback9 R1(config-if)#ip address 9.9.9.9 255.255.255.255 R1(config-if)#router bgp 1 R1(config-router)#no synch R1(config-router)#neighbor 172.12.123.2 remote-as 234 R1(config-router)#neighbor 172.12.123.3 remote-as 234 R1(config-router)#network 5.5.5.5 mask 255.255.255.255 R1(config-router)#network 6.6.6.6 mask 255.255.255.255 R1(config-router)#network 7.7.7.7 mask 255.255.255.255 R1(config-router)#network 8.8.8.8 mask 255.255.255.255 R1(config-router)#network 9.9.9.9 mask 255.255.255.255 R1(config-router)#network 1.1.1.1 mask 255.255.255.255

R2(config)#router bgp 234 R2(config-router)#no syn R2(config-router)#neighbor 172.12.123.1 remote-as 1 R2(config-router)#neighbor 172.12.23.4 remote-as 234 R3(config)#router bgp 234 R3(config-router)#no syn R3(config-router)#neighbor 172.12.123.1 remote-as 1 R3(config-router)#neighbor 172.12.23.4 remote-as 234 R4(config)#router bgp 234 R4(config-router)#no syn R4(config-router)#neighbor 172.12.23.2 remote-as 234 R4(config-router)#neighbor 172.12.23.3 remote-as 234 R4 has no knowledge of the 172.12.123.0/24 network, so configure both R2 and R3 with the nexthop-self command. R2(config)#router bgp 234 R2(config-router)#neighbor 172.12.23.4 next-hop-self

R3(config)#router bgp 234 R3(config-router)#neighbor 172.12.23.4 next-hop-self View R4's BGP table. R4#show ip bgp BGP table version is 7, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i1.1.1.1/32 *i *>i5.5.5.5/32 *i *>i6.6.6.6/32 *i *>i7.7.7.7/32 *i *>i8.8.8.8/32 *i *>i9.9.9.9/32 *i Next Hop 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 Metric LocPrf Weight Path 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i

R4 seems to have two valid paths for each loopback on R1. Run show ip bgp 1.1.1.1. R4#show ip bgp 1.1.1.1 BGP routing table entry for 1.1.1.1/32, version 2 Paths: (2 available, best #1) Not advertised to any peer 1 172.12.23.2 from 172.12.23.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal, best, ref 2 1 172.12.23.3 from 172.12.23.3 (3.3.3.3) Origin IGP, metric 0, localpref 100, valid, internal, ref 2 You can run this command for every one of those loopbacks, and the results will be much like this. 172.12.23.2 will be the next-hop address for all the remote loopbacks. We changed the weight attribute earlier to alter the path selection; now we'll use the local preference attribute. We'll write a route map to do this and apply it to routes coming in from R1. To change the local preference on R3 of all routes coming in from R1, no access-list is needed. Write a route-map that will set the local preference to 200 and apply it to R1 with a neighbor statement. (Don't forget the "in" or "out" option at the end of the neighbor statement - this determines if the route map is applied to incoming or outgoing routes. The router won't let you forget it, but the exam might.) R3(config)#route-map PREFERRED_PATH permit 10 R3(config-route-map)#set local-pref 200 R3(config)#router bgp 234 R3(config-router)#neighbor 172.12.123.1 route-map PREFERRED_PATH in Clear the BGP connections. Run a soft config if possible, but here you see a router that will not allow it. In this case, run a hard reset.

R3#clear ip bgp * soft %BGP: Inbound soft reconfig for 172.12.23.4 not possible as it has neither refresh capability, nor inbound soft reconfig R3#clear ip bgp * 1w0d: %BGP-5-ADJCHANGE: neighbor 172.12.23.4 Down User reset 1w0d: %BGP-5-ADJCHANGE: neighbor 172.12.123.1 Down User reset 1w0d: %BGP-5-ADJCHANGE: neighbor 172.12.23.4 Up 1w0d: %BGP-5-ADJCHANGE: neighbor 172.12.123.1 Up View R4's BGP table. R4#show ip bgp BGP table version is 25, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i1.1.1.1/32 * i *>i5.5.5.5/32 * i *>i6.6.6.6/32 *i *>i7.7.7.7/32 *i *>i8.8.8.8/32 *i *>i9.9.9.9/32 *i Next Hop 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 Metric LocPrf Weight Path 0 200 01i 0 100 01i 0 200 01i 0 100 01i 0 200 01i 0 100 01i 0 200 01i 0 100 01i 0 200 01i 0 100 01i 0 200 01i 0 100 01i

R3 is now setting a local preference of 200 for all routes received from R1, and this value is passed on to R4. R4 now prefers the path through R3 to reach all these destinations. Changing the weight on R3 would not have accomplished this; weight is the first BGP attribute checked during best path selection, but weight is locally significant only. Weights changed on R3 would not have been advertised to R4. Local preference changes are advertised throughout the AS, but are not advertised to other ASes. Do these changes affect R2's BGP table? R2#show ip bgp BGP table version is 7, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *> 1.1.1.1/32 *> 5.5.5.5/32 *> 6.6.6.6/32 *> 7.7.7.7/32 *> 8.8.8.8/32 *> 9.9.9.9/32 Next Hop 172.12.123.1 172.12.123.1 172.12.123.1 172.12.123.1 172.12.123.1 172.12.123.1 Metric LocPrf Weight Path 0 0 1i 0 0 1i 0 0 1i 0 0 1i 0 0 1i 0 0 1i

Not at all. Remember, R4 cannot advertise the routes it received from R3 to other iBGP neighbors! What if we wanted R4 to use the path through R3 only if the remote destination is 1.1.1.1, but to use the path through R2 for all other destinations? That's where we have to combine an ACL with a route-map. Before continuing with this lab, delete the route-map and the neighbor statement referencing that route-map from R3. Clear BGP after doing so. R4 should then be using R2 as the next-hop for all remote networks. (Always run show route-map before deleting route maps. Don't depend on your memory, especially in production networks.) R3#show route-map route-map PREFERRED_PATH, permit, sequence 10 Match clauses: Set clauses: local-preference 200 Policy routing matches: 0 packets, 0 bytes R3(config)#no route-map PREFERRED_PATH R3(config)#router bgp 234 R3(config-router)#no neighbor 172.12.123.1 route-map PREFERRED_PATH in R3#clear ip bgp * 1w0d: %BGP-5-ADJCHANGE: neighbor 172.12.23.4 Down User reset 1w0d: %BGP-5-ADJCHANGE: neighbor 172.12.123.1 Down User reset[ 1w0d: %BGP-5-ADJCHANGE: neighbor 172.12.23.4 Up 1w0d: %BGP-5-ADJCHANGE: neighbor 172.12.123.1 Up R4#show ip bgp BGP table version is 31, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network * i1.1.1.1/32 *>i * i5.5.5.5/32 *>i * i6.6.6.6/32 *>i * i7.7.7.7/32 *>i * i8.8.8.8/32 *>i * i9.9.9.9/32 *>i Next Hop 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 Metric LocPrf Weight Path 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i

On R3, write an ACL that matches only the IP address 1.1.1.1. This ACL will be referenced in the route-map that will then be applied to routes coming in from R1. R3(config)#access-list 1 permit host 1.1.1.1

R3(config)#route-map PREFER_FOR_NETWORK_1 permit 10 R3(config-route-map)#match ip address 1 R3(config-route-map)#set local-preference 200 R3(config-route-map)#route-map PREFER_FOR_NETWORK_1 permit 20 R3(config-route-map)#router bgp 234 R3(config-router)#neighbor 172.12.123.1 route-map PREFER_FOR_NETWORK_1 in R3#clear ip bgp * On R3, the local preference has been changed only for the route named in the ACL - 1.1.1.1. R3#show ip bgp BGP table version is 7, local router ID is 3.3.3.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *> 1.1.1.1/32 *> 5.5.5.5/32 *> 6.6.6.6/32 *> 7.7.7.7/32 *> 8.8.8.8/32 *> 9.9.9.9/32 Next Hop 172.12.123.1 172.12.123.1 172.12.123.1 172.12.123.1 172.12.123.1 172.12.123.1 Metric LocPrf Weight Path 0 200 0 1 i 0 0 1i 0 0 1i 0 0 1i 0 0 1i 0 0 1i

R4 will now use R3 as the next-hop for the path to 1.1.1.1, but continue to use R2 as the next-hop for all other remote networks. Verify with show ip bgp and show ip bgp 1.1.1.1. R4#show ip bgp BGP table version is 32, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i1.1.1.1/32 *i * i5.5.5.5/32 *>i * i6.6.6.6/32 *>i * i7.7.7.7/32 *>i * i8.8.8.8/32 *>i * i9.9.9.9/32 *>i Next Hop 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 172.12.23.3 172.12.23.2 Metric LocPrf Weight Path 0 200 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i 0 100 0 1i

R4#show ip bgp 1.1.1.1 BGP routing table entry for 1.1.1.1/32, version 32 Paths: (2 available, best #1) Not advertised to any peer 1 172.12.23.3 from 172.12.23.3 (3.3.3.3) Origin IGP, metric 0, localpref 200, valid, internal, best, ref 2 1

172.12.23.2 from 172.12.23.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal, ref 2 The local preference attribute is used to inform routers in the remote AS which path to choose when multiple valid paths are available, but what if we want to influence R1's path selection when choosing a path to enter AS 234? That's where the Multi-Exit Discriminator - the MED - comes into play. R1 has two possible entry points into AS 234 - R2 and R3. Advertise R4's loopback into BGP and then check to see which router R1 is using as a next-hop. R4(config)#router bgp 234 R4(config-router)#network 4.4.4.4 mask 255.255.255.255 R1#show ip bgp 4.4.4.4 BGP routing table entry for 4.4.4.4/32, version 8 Paths: (2 available, best #2, table Default-IP-Routing-Table) Flag: 0x208 Advertised to non peer-group peers: 172.12.123.3 234 172.12.123.3 from 172.12.123.3 (3.3.3.3) Origin IGP, localpref 100, valid, external 234 172.12.123.2 from 172.12.123.2 (2.2.2.2) Origin IGP, localpref 100, valid, external, best R1 is using 172.12.123.2 as the next-hop to enter AS 234. If all values are left at their default, we could have 100 routes being advertised from AS 234 to AS 1 and the next-hop would remain the same. We can configure R2 and R3 to send different MED values to R1, and the router sending the lowest MED would be the preferred next-hop. (The MED is a metric, and the lowest metric is always preferred.) Configure this MED value on both R2 and R3, sending a MED of 200 from R2 and 100 from R3. R2(config)#route-map SET_MED_200 permit 10 R2(config-route-map)#set metric 200 R2(config-route-map)#router bgp 234 R2(config-router)#neighbor 172.12.123.1 route-map SET_MED_200 out R3(config)#route-map SET_MED_100 permit 10 R3(config-route-map)#set metric 100 R3(config-route-map)#router bgp 234 R3(config-router)#neighbor 172.12.123.1 route-map SET_MED_100 out Clear BGP on R1 and view the routing table. R1#clear ip bgp * soft R1#show ip bgp BGP table version is 10, local router ID is 9.9.9.9 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *> 1.1.1.1/32 Next Hop 0.0.0.0 Metric LocPrf Weight 0 32768 Path i

*> 4.4.4.4/32 * *> 5.5.5.5/32 *> 6.6.6.6/32 *> 7.7.7.7/32 *> 8.8.8.8/32 *> 9.9.9.9/32

172.12.123.3 172.12.123.2 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

100 200 0 0 0 0 0

0 0 32768 32768 32768 32768 32768

234 i 234 i i i i i i

R1 now considers the path to 4.4.4.4 through R3 to be more desirable, due to its lower metric. BGP route summarization has an option that you haven't seen with IGP route summarization. To test this, configure the following four loopback interfaces on R1 and advertise them in BGP. interface Loopback16 ip address 16.1.1.1 255.0.0.0 ! interface Loopback17 ip address 17.1.1.1 255.0.0.0 ! interface Loopback18 ip address 18.1.1.1 255.0.0.0 ! interface Loopback19 ip address 19.1.1.1 255.0.0.0 R1(config-if)#router bgp 1 R1(config-router)#network 16.0.0.0 mask 255.0.0.0 R1(config-router)#network 17.0.0.0 mask 255.0.0.0 R1(config-router)#network 18.0.0.0 mask 255.0.0.0 R1(config-router)#network 19.0.0.0 mask 255.0.0.0 View R2's BGP table. R2#show ip bgp < some of the table has been removed for clarity > Network *> 16.0.0.0 *> 17.0.0.0 *> 18.0.0.0 *> 19.0.0.0 Next Hop 172.12.123.1 172.12.123.1 172.12.123.1 172.12.123.1 Metric 0 0 0 0 LocPrf Weight 0 0 0 0 Path 1i 1i 1i 1i

R2 has the routes. We can summarize these routes on R1 to keep the downstream tables smaller, though. Summarize these four routes on paper before continuing.

The correct summary for these routes is 16.0.0.0 252.0.0.0. In BGP, summary networks are advertised with the aggregate-address command. R1(config)#router bgp 1 R1(config-router)#aggregate-address 16.0.0.0 252.0.0.0 R1#clear ip bgp * soft View R2's BGP table. R2#show ip bgp < some of this table has been removed for clarity > Network *> 16.0.0.0 *> 16.0.0.0/6 *> 17.0.0.0 *> 18.0.0.0 *> 19.0.0.0 Next Hop 172.12.123.1 172.12.123.1 172.12.123.1 172.12.123.1 172.12.123.1 Metric LocPrf Weight Path 0 0 1i 0 1i 0 0 1i 0 0 1i 0 0 1i

You might have been expecting to see only the summary route, as you would with EIGRP or RIP's summary address command. You must remember that the BGP default for summary addresses is to advertise the summary and the routes being summarized! To advertise only the summary, the option summary-only must be configured at the end of the aggregate-address command. R1(config)#router bgp 1 R1(config-router)#no aggregate-address 16.0.0.0 252.0.0.0 R1(config-router)#aggregate-address 16.0.0.0 252.0.0.0 summary-only R1#clear ip bgp * soft View R2's BGP table. R2#show ip bgp < some of this table has been removed for clarity > Network *> 16.0.0.0/6 Next Hop 172.12.123.1 Metric LocPrf Weight Path 0 1i

R2 now has the summary and not the more-specific routes.

Finally, it's time to get some practice in with prefix-lists. Remove all BGP configurations from all four routers. Create a full iBGP mesh between R1, R2, and R3 and place them into AS 123. Place R4 into AS 4. Open R3 and R4's directly connected serial interfaces. Test IP connectivity between these two interfaces. R3 and R4 will form an eBGP peering relationship over the directly connected serial network. There's no need to remove each BGP statement separately - just run the command "no router bgp x" and that will get rid of the entire routing process and all commands configured under that process. Shut R4's Ethernet interface.

R1(config)#router bgp 123 R1(config-router)#no synch R1(config-router)#neighbor 172.12.123.2 remote-as 123 R1(config-router)#neighbor 172.12.123.3 remote-as 123 R2(config)#router bgp 123 R2(config-router)#no synch R2(config-router)#neighbor 172.12.123.1 remote-as 123 R2(config-router)#neighbor 172.12.123.3 remote-as 123 R3(config)#router bgp 123 R3(config-router)#no synch R3(config-router)#neighbor 172.12.123.1 remote-as 123 R3(config-router)#neighbor 172.12.123.2 remote-as 123 R3(config-router)#neighbor 10.2.2.4 remote-as 4 R4(config)#router bgp 4 R4(config-router)#no synch R4(config-router)#neighbor 10.2.2.3 remote-as 123 Verify the peerings on all four routers with show ip bgp summary. On R4, create three loopbacks and advertise them into BGP. Configure R3 as the next-hop router for all routes advertised to R1 and R2. View the BGP table on R1, R2, and R3; the loopbacks on R4 should be visible and valid.

R4: interface Loopback21 ip address 21.1.1.1 255.0.0.0 no ip directed-broadcast ! interface Loopback22 ip address 22.1.1.1 255.0.0.0 no ip directed-broadcast ! interface Loopback23 ip address 23.1.1.1 255.0.0.0 no ip directed-broadcast R4(config)#router bgp 4 R4(config-router)#network 21.0.0.0 mask 255.0.0.0 R4(config-router)#network 22.0.0.0 mask 255.0.0.0 R4(config-router)#network 23.0.0.0 mask 255.0.0.0

R3#show ip bgp BGP table version is 4, local router ID is 3.3.3.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *> 21.0.0.0 *> 22.0.0.0 *> 23.0.0.0 Next Hop 10.2.2.4 10.2.2.4 10.2.2.4 Metric LocPrf Weight Path 0 0 4i 0 0 4i 0 0 4i

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

R2#show ip bgp BGP table version is 4, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i21.0.0.0 *>i22.0.0.0 *>i23.0.0.0 Next Hop 172.12.123.3 172.12.123.3 172.12.123.3 Metric LocPrf Weight Path 0 100 0 4i 0 100 0 4i 0 100 0 4i

R1#show ip bgp BGP table version is 4, local router ID is 19.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i21.0.0.0 Next Hop 172.12.123.3 Metric LocPrf Weight Path 0 100 0 4i

*>i22.0.0.0 *>i23.0.0.0

172.12.123.3 172.12.123.3

0 0

100 100

0 0

4i 4i

If we wanted R3 to receive all three of these routes from R4 but not advertise them to R2 and R1, we've got a couple of options on how to block these routes. Cisco's recommendation is the use of prefix-lists, and once you get used to the syntax (which you should do before taking and passing the BSCI), you'll see they are actually easier to use than access-lists. In this case, we're going to configure R3 to send only the route to 21.0.0.0 to R1 and 223.0.0.0 to R2. However, we do want these two routers to get any future routes that R4 advertises into BGP. Since these two routers will learn about these routes from an iBGP neighbor, they will not advertise the routes to each other after learning their one assigned route. On R3, write a prefix-list that denies 22.0.0.0/8 and 23.0.0.0/8, but permits all other routes. Apply this to the neighbor relationship with R1, and view R1's BGP table to make sure only the route to 21.0.0.08 is there. R3(config)#ip prefix-list FILTER_R1 deny 22.0.0.0/8 R3(config)#ip prefix-list FILTER_R1 deny 23.0.0.0/8 R3(config)#ip prefix-list FILTER_R1 permit 0.0.0.0/0 le 32 R3(config)#router bgp 123 R3(config-router)#neighbor 172.12.123.1 prefix-list FILTER_R1 out R3#clear ip bgp * soft R1#show ip bgp BGP table version is 6, local router ID is 19.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i21.0.0.0 Next Hop 172.12.123.3 Metric LocPrf Weight Path 0 100 0 4i

The paths to 22.0.0.0/8 and 23.0.0.0/8 have been successfully filtered. On R3, write a prefix-list that will filter 21.0.0.0/8 and 22.0.0.0/8, but allow all other routes. Apply this to the neighbor relationship with R2, and view R2's BGP table to make sure only the route to 23.0.0.0/8 is there. R3(config)#ip prefix-list FILTER_R2 deny 21.0.0.0/8 R3(config)#ip prefix-list FILTER_R2 deny 22.0.0.0/8 R3(config)#ip prefix-list FILTER_R2 permit 0.0.0.0/0 le 32 R3(config)#router bgp 123 R3(config-router)#neighbor 172.12.123.2 prefix-list FILTER_R2 out R3#clear ip bgp * soft

R2#show ip bgp BGP table version is 6, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i23.0.0.0 Next Hop 172.12.123.3 Metric LocPrf Weight Path 0 100 0 4i

The paths to 21.0.0.0/8 and 22.0.0.0/8 have been successfully filtered. To see the prefix lists configured on a route as well as the order of the statements in each list, run show ip prefix-list.

R3#show ip prefix-list ip prefix-list FILTER_R1: 3 entries seq 5 deny 22.0.0.0/8 seq 10 deny 23.0.0.0/8 seq 15 permit 0.0.0.0/0 le 32 ip prefix-list FILTER_R2: 3 entries seq 5 deny 21.0.0.0/8 seq 10 deny 22.0.0.0/8 seq 15 permit 0.0.0.0/0 le 32