CCNP Route Guide

Welcome to your Bulldog Study Guide for the CCNP ROUTE exam! I know you’re anxious to get started, so I’ll keep this short… Your CCNP ROUTE exam prep requires you to tackle some complex subjects, with BGP, multiarea OSPF, and route redistribution among them. In this guide, you’ll find clear and comprehensive explanations for each and every one of these topics, along with hundreds of illustrations and configs from live Cisco routers.

(I do not use simulators in my books or videos.) Speaking of videos, I’ve added a special feature to this ebook that’s guaranteed to help you master these complex concepts. And just as exciting, these features don’t cost anything! At the end of each section, you’ll find links to videos on my YouTube computer certification video training channel that are related to the topic you just studied.

You’ll find Video Practice Exams, 5-minute Video Boot Camps, and other video types - all of which will help you nail this difficult exam. You’ll also find links to my free CCNP ROUTE Video Boot Camp on route redistribution and OSPF stub areas, and my full 22-hour CCNP ROUTE Video Boot Camp, available on both DVD and in downloadable format. That last one’s not quite free, but in a world of $500 video courses, you’ll find the price to be quite

refreshing. I also invite you to join me on Twitter, Facebook, LinkedIn, and other social media sites. I’m there live every day and happy to chat with you there! ‘Nuff said! Let’s get started … … and as always, thanks for making TBA part of your CCNP success story! Chris Bryant CCIE #12933 “The Computer Certification

Bulldog” Chris Bryant CCIE #12933 “The Computer Certification Bulldog” [email protected] Website: http://www.thebryantadvantage.com/ Twitter: http://www.twitter.com/ccie12933 Facebook: http://on.fb.me/gPq52d

Blog: http://thebryantadvantage.blogspot.co

YouTube: http://www.youtube.com/user/ccie12

Free Resources To Help You Pass The CCNP ROUTE Exam!

In addition to this informationpacked CCNP ROUTE Study Guide, TBA has literally dozens of additional practice exams, Video Boot Camps, and illustrated tutorials to help you destroy this exam! First, for some videos! My

YouTube

Computer

Certification Channel has quite a few videos on the CCNP ROUTE exam:

http://www.youtube.com/user/ccie12 I hope you’ll click “subscribe” while you’re out there - I’m adding new videos AND certifications on a regular basis, including Security+, Network+, and a new CCNA Security course in 2012! You’ll also find links to individual videos on that channel at the end of most chapters of this ebook.

I have a separate Videos & Tutorials page on my website for each of the CCNP exams - here’s the page dedicated to ROUTE:

http://www.thebryantadvantage.com/C Be sure to scroll ALL the way down that page - there are links to practice exams, tutorials, and Video Boot Camps! For future reference, or for review, here are my pages for the SWITCH and TSHOOT exams: SWITCH:

http://www.thebryantadvantage.com/C TSHOOT:

http://www.thebryantadvantage.com/C I also have a Video Boot Camp hosted on Udemy.com -- well, actually, two of them! The first is 100% free and is a tremendous lab and lecture on route redistribution and multiarea OSPF. This is must-see material, my friends… and you can watch it online, or you can download it - or both!

http://www.udemy.com/ccnp-routeboot-camp-redistribution-and-ospfstub-areas/ There’s also a full hour-long preview from my CCNP ROUTE DVD on that site: http://www.udemy.com/ccnp-routeon-demand-video-boot-camp/ And should you choose to enroll in that course OR get the DVD, please remember to use this link and save yourself $10!

http://www.thebryantadvantage.com/C When I post new videos or tutorials, or whenever there’s important news in the computer certification world, I always post it on our Facebook and Twitter feeds as well as the Bulldog Blog. I urge you to click these links and join us! We have some great conversations and the occasional giveaway out there -- and if you have a question or comment, just send it via Twitter

or leave it on Facebook! I’m always happy to hear from you! Twitter: http://www.twitter.com/ccie12933 Facebook: http://on.fb.me/gPq52d

Bulldog Blog: http://thebryantadvantage.blogspot.co The CCNP ROUTE exam is a tough one. Use all of these resources in addition to this study guide - and thanks for making TBA part of your CCNP success story!

Chris Bryant CCIE #12933 “The Computer Bulldog”

Certification

Copyright © 2012 The Bryant Advantage. All Rights Reserved.

Dedication For Suzy and Squeaky

Always loved, never forgotten.

Copyright © 2012 The Bryant Advantage. All Rights Reserved.

There’s only one way to get my crystal-clear CCNP ROUTE Video Boot Camp instruction --- and that’s directly from TBA. All of my Video Boot Camp DVDs give you a full, free HOUR

of training to let you “Try Before You Buy”! It’s this sweet and simple: My CCNP Bulldog Boot Camps DVDs have helped network admins around the world - from the UK to Australia, from Russia to the US become CCNPs. No other DVD offers my crystalclear and concise instruction - and I never use simulators in my labs. And I don’t charge you an arm and a

leg for a DVD. Even better - you can save $10 on any DVD or Bulldog DVD Bundle by following this link:

http://www.thebryantadvantage.com/C I know you’ll be happy with any and all of my Video Boot Camp DVDs. You have my word and my name on it. Chris Bryant CCIE #12933 “The Computer

Certification

Bulldog” http://www.thebryantadvantage.com/

Copyright Information: Cisco®, Cisco® Systems, CCIE™, CCNP, CCNA, Cisco Certified Network Administrator, Cisco Certified Network Professional, and Cisco Certified Internetwork Expert are registered trademarks of Cisco® Systems, Inc., and/or its affiliates in the U.S. and certain countries. All other products and company names are the trademarks, registered trademarks, and service marks of the respective owners.

Throughout this Study Guide, The Bryant Advantage has used its best efforts to distinguish proprietary trademarks from descriptive names by following the capitalization styles used by the manufacturer. Disclaimer: This publication, The Bryant Advantage CCNP ROUTE Study Guide, is designed and intended to assist candidates in preparation for the CCNP ROUTE exam for the Cisco Certified Network Professional ® certification.

All efforts have been made by the author to make this book as accurate and complete as possible, but no guarantee, warranty, or fitness are implied, expressly or implicitly. The enclosed material is presented on an “as is” basis. Neither the author, The Bryant Advantage, Incorporated, or the parent company assume any liability or responsibility to any person or entity with respect to loss or damages incurred from the information contained in this workbook.

This Course Guide is an original work by the Author. Any similarities between materials presented in this Study Guide and actual CCNP® exam questions are completely coincidental. Copyright 2012 © The Bryant Advantage

Copyright © 2012 The Bryant Advantage. All Rights Reserved.

Table Of Contents

Introduction: Free Resources For The CCNP ROUTE Exam: Dedication: DVD Discount Offer: Legal Notices: IP Routing Fundamentals:

EIGRP Fundamentals: EIGRP Intermediate and Advanced Skills: Link State Protocols And Single-Area OSPF: Multi-Area OSPF And OSPF Route Redistribution: BGP: Remote Workplace: VPNs and IPSec: Remote Workplace, Part II :

IP Version 6: Route Redistribution: Bonus Section: Creating A VLSM Scheme: More VLSM!:

IP Routing Fundamentals

Okay, I know what you’re thinking! “I’m a CCNA already, I already studied RIP, I know all the Distance Vector stuff, I know my admin distances. Let’s get to the new stuff!” Before we do that, we’re going to take some time to review and master some fundamental routing skills … … because without that mastery, we

can’t become truly great. And while I know you’re familiar with these protocols, this chapter is going to be more than a review for you - it’s going to sharpen your skills with these critical protocols to the point where the CCNP ROUTE questions will be child’s play for you. There’s also more than a little material in this section that will help you big time on your CCNP TSHOOT exam as well. Sooooo…..

Let’s get started! How and Where Distance Vector Protocols Operate Typically, distance vector protocols are used on Local Area Networks (LANs). While DV protocols work well in smaller and more stable environments, they have several drawbacks that prevent them from being used as Wide Area Network (WAN) protocols. One drawback is that RIP broadcasts routing updates every 30 seconds, as illustrated by show ip

protocols: R5#show ip protocols Routing Protocol is “rip” Sending updates every 30 seconds, next due in 16 seconds Invalid after 180 seconds, hold down 180, flushed after 240

RIPv1 will broadcast full routing tables as the update, regardless of whether anything has actually changed since the last update. This is a waste of bandwidth and resources, since your average LAN’s subnets aren’t going to change every minute. (We hope!)

RIPv2 multicasts updates to 224.0.0.9 rather than broadcasting them, but the updates are still sent out every 30 seconds. In a larger network, another problem arises. RIP routing updates can hold a maximum of 25 routes, so if there are 105 routes in your network, five separate update packets would be needed. Since these updates would go out every 30 seconds, whether anything had actually changed in the network, RIP is generally a poor choice for a WAN protocol.

Remember, everything we do on a router has a cost to that router and others - a cost in CPU, bandwidth, and time. Those continual RIP updates have a high cost and very little value. Drawback 2: RIPv1 is a classful routing protocol, and therefore does not support VLSM. The only masks RIPv1 understands are the classful masks for Class A (255.0.0.0), Class B (255.255.0.0), and Class C (255.255.255.0). Drawback 3: Both versions of RIP only understand hop count -

literally, how many “hops” there are from Point A to Point B. On a LAN, this really isn’t a problem, but RIP’s limitations quickly become a problem on a WAN.

There are two paths between A and B. The path using the two T1 lines is much faster than the 56 kbps path,

but RIP will see these paths as equals. RIP’s routing algorithm, the Bellman-Ford algorithm, considers only hop count in computing its metric. In this example, RIP will then perform equal-cost load balancing over the two links. (DV protocols perform equal-cost load balancing over four paths by default.) Default DV Protocol Behaviors DV protocols do have some drawbacks, but they also have some default behaviors that help prevent

routing loops. You saw all of these in your CCNA studies, but let’s do a quick review. Split Horizon simply means that a routing protocol cannot advertise a route via the same interface upon which it was learned. Here, Router 3 cannot advertise the loopback network 2.0.0.0 via its ethernet interface, because that is the interface upon which the router first learned about the network.

Poison Reverse allows a router to advertise a network with an metric of “unreachable” when that network becomes unavailable. This allows the other routers to learn that the network is unreachable much faster than if it were left up to the normal DV protocol behaviors -- and in turn, that results in fewer misrouted / lost packets.

It’s obviously in our best interest to have the quickest convergence time possible. If some routers think “network A” is available and others think the network is unavailable, routing for that network is going to be substandard at best and routing loops can easily form.

The Basics Of RIPv1, RIPv2, and EIGRP RIPv1: Broadcasts updates every 30 seconds Classful, does not recognize VLSM, update carries entire routing table Uses Bellman-Ford algorithm Equal-cost load shares by

default, max hop count is 15 No routing update authentication available Updates carry 25 routes max RIPv2: Multicasts updates every 30 seconds to 224.0.0.9 Classless, supports VLSM, update carries entire routing

table Uses Bellman-Ford and default equal-cost load sharing, max hop count is 15, updates carry 25 routes max Supports routing update authentication (clear-text and MD5) EIGRP: Multicasts to 224.0.0.10

Sends entire routing table only when the adjacency is first formed Sends only routing update after that when necessary, update reflects only the changes Uses DUAL routing algorithm Equal-cost load sharing by default, unequal-cost load sharing configured with the variance command

EIGRP is not a pure distance-vector protocol, but I’ve put it here for easy comparison to RIP. I also didn’t go into a discussion of EIGRP here, since we’ll be doing plenty of that later in the course. The Role Distance

Of

Administrative

When a route lookup is performed in a routing table, there may be more than one path that meets the criteria for being selected. Basically, there is a four-step process a router goes through when

looking for the best route to use: 1. If there are multiple routes to a destination, the route with the longest prefix length is used. 2. If there are multiple routes to a destination and they have the same prefix length, the route with the lowest administrative distance is used. 3. If there are multiple routes with the same prefix length and

AD, the route with the lowest metric is used. 4. If there are multiple routes with the same prefix length, AD, and metric, all of these routes will be used in load balancing as allowed by the protocol. Consider a router that is looking through its routing table to decide the next-hop IP address to use to reach the destination 222.1.3.1. I’m going to use IGRP in this

example, but please note that IGRP is obsolete and is no longer tested on Cisco certification exams. In the unlikely but possible circumstance that the router has one path discovered by OSPF and another by IGRP, the two paths could look like this: O: 222.1.3.0 /25 via 172.1.1.2, serial1 I: 222.1.3.0 /24 via 175.1.1.2, serial0

In this case, the OSPF route would be chosen, because it is the longest match; its mask is /25, a longer match than IGRP’s classful mask of

/24. The administrative distance (AD) does not come into use. But what if the masks were the exact same length? O: 222.1.3.0 /24 via 172.1.1.2, serial1 I: 222.1.3.0 /24 via 175.1.1.2, serial0

A tiebreaker is needed, and that’s where the AD comes in. The path discovered by the protocol with the lowest AD will be used. Since IGRP’s AD is 100 and OSPF’s is 110, the IGRP path will actually be used over the OSPF path.

AD values to know: Directly connected route / Static route using exit interface: 0 Static route with next-hop IP address: 1 EIGRP Summary: 5 (if you know where to look -- more on that later) External BGP: 20

Internal EIGRP: 90 OSPF: 110 RIP: 120 External EIGRP: 170 Internal BGP: 200 Unknown network: 255 You may notice some differences

here from the ADs you learned in earning your CCNA. There are now two kinds of non-summary EIGRP routes listed, internal and external. Much more about those route types in the EIGRP sessions. Routing Table Operation This entire operation is practically transparent to you and I as network admins, and that’s fine when things go as we expect. When things don’t go as we expect and when we’re studying for Cisco exams! -- we better know the

“hows” and “whys” of the routing table. We love it when the router has multiple paths to a given network! That way, if we lose one path, we have another - and we’ll take all the redundancy we can get in today’s delay-sensitive networks. Now that we know how a routing table is built, let’s take a closer look at a small table and identify the different values. R1#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 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:01, Serial0 [120/1] via 172.12.123.3, 00:00:04, Serial0 C 172.12.123.0/24 is directly connected, Serial0

10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Ethernet0

There is one RIP route and two directly connected routes. Since we’re primarily interested in the RIP route for this discussion, we’ll run show ip route rip to see only the routes that RIP has discovered. R1#show ip route rip 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks R R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:04, Serial0 [120/1] via 172.12.123.3, 00:00:04, Serial0

The network 172.12.23.0/27 is the destination. The numbers contained in the brackets are the administrative distance of the protocol that discovered the route, followed by the metric for that path. Since this is a RIP route, the metric shown is the number of hops to that network. The IP addresses following the word “via” are the next-hop IP addresses, followed by the time this route was last refreshed. Since RIP sends full routing updates every 30 seconds regardless of version, this value will not exceed 30 seconds

for a valid RIP route unless the holddown timers are in use. Finally, each line ends by naming an interface. This is the local interface that data sent to this destination will use to exit the router. It has nothing to do with the downstream router. In this example, we have two separate paths listed for a single destination. Remember the process a router uses to determine the best path? It’s worth repeating…. The route with the longest prefix length will be selected.

The term “longest prefix match” refers to the length of the subnet mask. If there are multiple routes with the same prefix length, the route with the lowest administrative distance will be used. Generally referred to as “AD”, this is a measurement of a protocol’s believability. The lower the AD, the more believable the protocol. If there are multiple routes

with the same prefix length and AD, the route with the lowest metric will be preferred. Finally, if the preceding three values are all equal, equalcost load sharing will be put into action. The prefix length, administrative distance, and metrics are all the same. Therefore, RIP will use both paths via equal-cost load sharing. You can verify that load sharing is in operation (and a lot of other

things!) by protocols.

running

show

ip

In this example, we can also see when the next routing update is expected, what version of RIP you’re running, whether routing updates are being authenticated (you would see a value under “Keychain” if authentication was in use), and whether autosummarization is on or off. R1#show ip protocols Routing Protocol is “rip” Sending updates every 30 seconds, next due in 7 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

R

Serial0

2

2

Automatic network summarization is not in effect (autosummarization has been turned off) Maximum path: 4 Routing for Networks: 172.12.0.0 Routing Information Sources:

Gateway

Distance

172.12.123.3 120

172.12.123.2 120 Distance: (default is 120)

As great as dynamic routing protocols are, I can guarantee you that the time will come when you need to use a routing method that has less overhead. Maybe you’re working with a router with very limited resources; maybe you want to have more personal control about routing operations. There are several methods you can use in these scenarios, and the most common are static routes and default static routes.

Static Routing Routing protocols are much more effective in keeping an accurate routing table, and adapt to network changes much more quickly than static routing - and it takes a lot less of our time, too. So why use static routing at all? If a route has one IP address as the next-hop address for every single route in its table, why keep a full dynamic routing table when a single static default route will do?

As we’ll see in the Advanced EIGRP and especially the multiarea OSPF sections, this strategy is actually built in to these dynamic routing protocols. Static routes can also serve as a tourniquet of sorts for your network. If something goes wrong with your dynamic protocol and you need to give your users a quick path to a gateway that can get them where they need to go, a quick static route can give you (some) peace and quiet while you fix the problem. A static route can also serve as a

backup to a dynamic routing protocols - a floating static route, that is. A floating static route is assigned an administrative distance higher than that of any dynamic protocol running on the router, ensuring that the only way the static route can be used is if all dynamic routes leave the table. A default static route serves as a router’s gateway of last resort. Remember that a default static route isn’t the path packets will take first, it’s the path they’ll take if there is

no other match in the routing table at all. You learned how to configure a static route in your CCNA studies, but let’s quickly review the syntax: R1(config)#ip route 3.3.3.3 255.255.255.255 172.12.123.3

R1(config)#ip route 3.3.3.3 255.255.255.255 serial0

These two static routes are both host routes; that is, they are valid for only one destination, in this case 3.3.3.3 /32. Note that the mask is a subnet mask, not a wildcard mask.

In the first example, the IP address at the end of the static route is the next-hop IP address for the route. In the second, the interface named at the end of the static route is the local exit interface. You will never configure a static route that uses a local IP address or a remote interface name. You’ll use the ip route command for a default static route, but the IP address and mask look rather odd: R1(config)#ip route 0.0.0.0 0.0.0.0 172.12.123.3 R1#show ip route

< code table removed for clarity > Gateway of last resort is 172.12.123.3 to network 0.0.0.0 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:14, Serial0 [120/1] via 172.12.123.3, 00:00:26, Serial0 C 172.12.123.0/24 is directly connected, Serial0 10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Ethernet0 S* 0.0.0.0/0 [1/0] via 172.12.123.3

The ip route statement contains all zeroes for both the destination and mask. The gateway of last resort is now set, and any data that does not

have a match in the routing table will be sent to the next-hop address 172.12.123.3. The asterisk next to the S indicates that this is a default route. The ip route statement for a default route can also end with the local exit interface: R1(config)#ip route 0.0.0.0 0.0.0.0 serial0 R1#show ip route < code table removed for clarity > Gateway of last resort is 0.0.0.0 to network 0.0.0.0 172.12.0.0/16 is variably subnetted, 2

subnets, 2 masks R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:26, Serial0 [120/1] via 172.12.123.3, 00:00:08, Serial0 C 172.12.123.0/24 is directly connected, Serial0 10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Ethernet0 S* 0.0.0.0/0 is directly connected, Serial0 R1#

While the gateway is now set to 0.0.0.0 rather than 172.12.123.3, the net effect is the same. I personally like to configure a default static route with a specified next-hop address, but it’s up to the individual.

Floating Static Routes In Action In this lab and all others in the course, all IP addresses end with the router’s number. For example, R1’s Serial0 interface on the 172.12.123.0 /24 network has an IP address of 172.12.123.1. Note that RIP is not running over the entire network -- it’s not running over the serial link connecting R1 and R3’s serial1 interfaces. R1/R2/R3

Frame

Network:

172.12.123.0 /24 R1 / R3 Serial 210.1.1.0 /24 R2 / R3 Ethernet 172.12.23.0 /27

Connection: Network:

You might be wondering if there will ever actually be a situation where you wouldn’t run a dynamic protocol over that link. If you’re

like me, you’re thinking “Why wouldn’t I just run RIP over the link and let the protocol figure all of this out?” Ordinarily we’d be happy to do that, but in this case we’re being asked not to use the S1 link unless the S0 link goes down. That happens more often than you might think, for these reasons… Bandwidth availability through the S0 link is much higher than that of the S1 link, but RIP will see them as equal

Perhaps the S1 link flaps on occasion and the S0 link is considered to be much more stable Perhaps the client just doesn’t want to listen to reason and just doesn’t want to use that link and just doesn’t want to hear anything about it (this happens on occasion, too) Now let’s hit this lab! R1 has two next-hop addresses for the 172.12.23.0 /27 network:

R1#show ip route rip 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:04, Serial0 [120/1] via 172.12.123.3, 00:00:04, Serial0

We need a static route that will appear in the routing table only if those RIP links are gone, but we also know the AD of a static route is much lower than that of a RIPdiscovered route. Here’s how we fix that: R1(config)#ip route 255.255.255.224 210.1.1.3 ?

172.12.23.0



name permanent tag

R1(config)#ip route 255.255.255.224 210.1.1.3 200

Distance metric for th route Specify name of the next hop permane route Set tag fo this route 172.12.23.0

Using the option to change the static route’s administrative distance (that’s what “distance metric for

this route” refers to) creates the static route with an AD of 200. In this case, anything higher than 120 will do. We hope. Let’s check it out…. R1#show ip route < code table removed for clarity > 172.12.0.0/16 is variably subnetted, 3 subnets, 2 masks C 172.12.13.0/24 is directly connected, Serial1 R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:21, Serial0 [120/1] via 172.12.123.3, 00:00:05, Serial0 C 172.12.123.0/24 is directly connected, Serial0 10.0.0.0/24 is subnetted, 1 subnets

C Ethernet0

10.1.1.0 is directly connected,

Now we need to test the config, and since we’re in a lab environment, we’ll close S0 and cut off the RIP updates. The result: R1#show ip route < code table removed for clarity > 172.12.0.0/27 is subnetted, 1 subnets 172.12.23.0 [200/0] via 210.1.1.3 10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Ethernet0 C 210.1.1.0/24 is directly connected, Serial1 S

R1#ping 172.12.23.3 Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.12.23.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

When we reopen R1’s S0 interface, the RIP updates will again be received by R1 and the floating static route will be removed from the table due to its higher AD. R1(config)#int s0 R1(config-if)#no shutdown

R1#show ip route < code table removed for clarity > 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks R 172.12.23.0/27 [120/1] via

172.12.123.2, 00:00:17, Serial0 [120/1] via 172.12.123.3, 00:00:00, Serial0 C 172.12.123.0/24 is directly connected, Serial0 10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Ethernet0 C 210.1.1.0/24 is directly connected, Serial1

On-Demand Routing (ODR) In today’s world, the phrase “OnDemand” brings to mind the latest in technology, where you can watch anything from my Cisco certification video training to the latest episode of Pawn Stars or Parking Wars anytime you like with

the push of a button or the click of a mouse. The latest and technology, right?

greatest

in

Right! Except for “On-Demand Routing” (ODR). ODR can come in handy for one major reason: Everything we do on a Cisco router or switch has a cost, in the form of CPU, bandwidth, and / or time. This is especially true of dynamic routing protocols, so in small

networks with routers that don’t have resources to spare, static routing can be beneficial. In a larger network, though, there is the need for a middle ground between static routing and running a dynamic routing protocol. In Cisco, this is ODR. Why just Cisco? Because ODR uses our old friend Cisco Discovery Protocol (CDP). As you well know, CDP is Cisco-proprietary, so if we have a multivendor environment, ODR is not a viable solution.

Make sure your ODR routers are running CDP with show cdp. On top of that, ODR is designed for use only in a hub-and-spoke network. If you have such a network and the bandwidth is limited, ODR may be an appropriate solution. ODR also supports VLSM. The spokes are going to use ODR to send directly connected network prefixes to the hub. The spoke will use the IP address of the hub on the common link as its default gateway. By using only a single default route, the spoke routers conserve their

resources. Propagating A Default Route With RIP, IGRP, And No IP Routing When it comes to default routing, you’ve got three choices: Use the ip route command with all zeroes for the destination address and subnet mask Use the ip default-network command Use the ip default-gateway

command You’ve got the ip route command down cold at this point, so let’s take a closer look at ip default-network. We’ll use the following network. The common subnet is 172.12.123.0 /24. We want R1 to advertise its directly connected network 100.1.1.0 /24 to R2 and R3 as a default route.

The ip default-network command is used to flag a network as a candidate default route. The routers are already running RIP over the

common subnet. R1 will now introduce 100.1.1.0 /24 as the default network. R1(config)#ip default-network 100.1.1.0

R2 and R3 will see this route as a default route discovered by RIP: R2#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 172.12.123.1 to network 0.0.0.0 2.0.0.0/32 is subnetted, 1 subnets C 2.2.2.2 is directly connected, Loopback0 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0 R* 0.0.0.0/0 [120/1] via 172.12.123.1, 00:02:20, Serial0

The default route named by ip default-network didn’t have to be manually redistributed into RIP. It’s placed there automatically by the

router when this command is used. Speaking of redistribution, we could have created a default static route on R1 and then redistributed it into RIP. We’ll remove the ip default-network command and do just that. R1(config)#no ip default-network 100.0.0.0 R1(config)#ip route 0.0.0.0 0.0.0.0 ethernet0 R1(config)#router rip R1(config-router)#redistribute static metric 1

R2 and R3 will both see the default route. R2#show ip route rip R* 0.0.0.0/0 [120/1] via 172.12.123.1,

00:00:12, Serial0 R3#show ip route rip R* 0.0.0.0/0 [120/1] via 172.12.123.1, 00:00:02, Serial0

Much more redistribution to come! IP Helper Addresses While routers accept and generate broadcasts, they do not forward them. That can present quite a problem with DHCP requests when a router is between the requesting host and the DHCP server. The initial step in the DHCP process has the host generating a

DHCPDiscover packet - and that packet is a broadcast.

If this PC attempts to locate a DHCP server with a broadcast, the broadcast will be stopped by the router and will never get to the DHCP server. By configuring the ip

helper-address command on the router, UDP broadcasts such as this will be translated into a unicast by the router, making the communication possible. The command should be configured on the interface that will be receiving the broadcasts -not the interface closest to the destination device. R1(config)#int e0 R1(config-if)#ip helper-address ? A.B.C.D IP destination address R1(config-if)#ip helper-address 100.1.12

DHCP messages are not the only broadcasts being relayed to the correct destination with this command -- there are nine of them. TIME, port 37 TACACS, port 49 DNS, port 53 BOOTP/DHCP Server, port 67 BOOTP/DHCP Client, port 68

TFTP, port 69 NetBIOS name service, port 137 NetBIOS datagram service, port 138 IEN-116 name service, port 42 That’s going to cover most scenarios where the ip helper-

address command will be useful, but what about those situations where the broadcast you need forwarded is not on this list? You can use the ip forward-protocol command to add any UDP port number to the list. To remove protocols from the list, use the no ip forward-protocol command. In the following example, we’ll add the Network Time Protocol port to the forwarding list while removing the NetBIOS ports. Remember, you can use IOS Help to get a list of commonly filtered ports!

forward-protocol udp ? Port number Biff (mail biff notification, comsat, 512) Bootstrap bootpc Protocol (BOOTP) client (68) Bootstrap bootps Protocol (BOOTP) server (67)

R1(config)#ip

discard

Discard (9) DNSIX security

dnsix

protocol auditing (195) Domain Name domain Service (DNS, 53) echo Echo (7) Internet Security isakmp Association and (500) Key Management Protocol Mobile IP mobile-ip registration (434) IEN116 name nameserver service (obsolete, 42) netbiosNetBios datagram dgm service (138)

NetBios name service (137) NetBios session netbios-ss service (139) Network Time ntp Protocol (123) pim-autoPIM Auto-RP rp (496) Routing Information rip Protocol (router, in.routed, 520) netbios-ns

snmp

Simple Network Management Protocol (161) SNMP Traps

snmptrap

sunrpc

tacacs talk tftp time who

(162) Sun Remote Procedure Call (111) syslog System Logger (514) TAC Access Control System (49) Talk (517) Trivial File Transfer Protocol (69) Time (37) Who service (rwho, 513) X Display

xdmcp

Manager Control Protocol (177)

R1(config)#ip forward-protocol udp 123 R1(config)#no ip forward-protocol udp 137 R1(config)#no ip forward-protocol udp 138

Recommended Video Viewing: Three-part Video Boot Camp on Floating Static Routes on TBA website: http://bit.ly/bxNIBh Three-part Video Boot Camp series

on Static Routes on TBA Website: http://bit.ly/dourQ2 Free CCNP ROUTE Video Boot Camp on route redistribution: http://bit.ly/Arnhjq My CCNP ROUTE Video Boot Camp - Exclusive Discount Link For My Ebook Readers Only!

Just click this link for a free hourlong preview AND $10 off the already low price! http://bit.ly/A7pLBu Available for immediate download

and on DVD!

Copyright © 2012 The Bryant Advantage. All Rights Reserved.

EIGRP Fundamentals

Introduction To EIGRP Link state protocols (OSPF) and distance vector protocols (RIP) have clear-cut differences in the way the best routes are determined and what is actually exchanged between routers. Just as a hybrid plant has characteristics of more than one plant, a hybrid routing protocol has characteristics of both link state and distance vector protocols. The hybrid protocol is

Enhanced Interior Gateway Routing Protocol – EIGRP. EIGRP has a lot going for it: Rapid convergence upon a change in the network, because backup routes (“Feasible Successors”) are calculated before they’re actually needed due to the loss of a primary route (“Successor”) Offers multiprotocol support (supports IP, IPX, and AppleTalk)

Supports Variable-Length Subnet Masking (VLSM) and Classless Inter-Domain Routing (CIDR) The one little problem with EIGRP is that it’s Cisco-proprietary, making it unsuitable for a multivendor environment. EIGRP is the enhanced version of the original Interior Gateway Routing Protocol (IGRP), which is no longer supported by new Cisco IOSes and is no longer a part of

Cisco certification exams. I’ll mention it occasionally in the EIGRP sections for comparison’s sake. EIGRP acts like a distance vector protocol in that EIGRP neighbors initially exchange full routing tables. Just about every other EIGRP behavior is more like a link state protocol. Hello Packets and RTP: The Heartbeat Of EIGRP EIGRP uses (multicast to

Hello packets 224.0.0.10) to

establish and maintain neighbor relationships. The Reliable Transport Protocol (RTP) is used to handle the transport of messages between EIGRP-enabled routers. EIGRP also acts like a link state protocol in that when network topology changes occur, updates containing only the change are sent, rather than another full routing table. EIGRP uses autonomous systems to identify routers that will belong to the same logical group. EIGRP routers that exist in separate autonomous systems will not

exchange routes. They won’t even become neighbors in the first place! For an EIGRP neighbor relationship to be established, the routers must receive Hello packets from the neighbor, the Autonomous System number must match, and the metric weights must match. The metric weights refer to the level of importance EIGRP gives to the bandwidth, delay, load, and reliability metrics. By default, EIGRP considers bandwidth and delay when calculating metrics, and does not consider the other metric

weights. Changing the metric weights is covered in the Advanced EIGRP section; for now, know that these metric weights must be the same on each router or the neighbor relationship will not be established. As with OSPF, once the neighbor relationship is present, it is the Hello packets that keep it alive. If the Hellos are no longer received by a router, the neighbor relationship will eventually be terminated.

The Successor Successor

and

Feasible

EIGRP keeps three tables - the route table, where the best route to each destination is kept; the topology table, where all feasible routes are kept; and the neighbor table, where the EIGRP neighbors and information about them are kept. As an EIGRP-enabled router learns about the network, the router will put the best route to a given destination in its routing table. EIGRP keeps the best routes along

with less-desirable but still valid routes in the topology table. EIGRP actually calculates these backup routes before a failure occurs, making convergence after a failure much faster than RIP. The EIGRP term for the best route is Successor. Any valid alternate route is referred to as the Feasible Successor. The decision process for whether a route can become a Feasible Successor can be summed up in one question…. The EIGRP Feasible Successor Question:

The router asks itself, “Is the neighboring router’s metric for this route lower than my metric?” If so, no loop is present, and that route is a Feasible Successor. If not, a loop may be present, and that route cannot be a Feasible Successor. That’s all well and good - but what if there is no Feasible Successor? EIGRP uses the Diffusing Update Algorithm (DUAL) to issue queries

to neighbors for a loop-free route to the destination. If the routers receiving the DUAL queries do not have a route, those routers will also send DUAL queries to their neighbors. This process continues until a route is found and the original router is informed of the route, or no valid route is found. More about those queries later in the two EIGRP sections. EIGRP’s Major Advantage Over RIP EIGRP is Cisco-proprietary, and

RIPv2 is not. Both support VLSM, so why not use RIPv2 over EIGRP? Consider the following:

If you or I were asked what the optimal path(s) are between R1 and

R2, we wouldn’t hesitate - T1 lines run at 1544 kbps, almost thirty times faster than a 56 kbps line, so the extra “hop” over the R1 paths will hardly matter. EIGRP would agree with us, but RIPv2 would not. RIPv2 does have its uses, but it only considers hop count as a metric. Therefore, RIPv2 would consider the path from R1R5-R2 the best path - and it’s nowhere near the best path! Since both EIGRP and OSPF consider the speed of a link in its calculations, we’re almost always

better off to use those two protocols for our WANs. OSPF is not Ciscoproprietary, so if we do have some non-Cisco routers (booooo!) in the WAN, we could still use that instead of RIPv2. Configuring EIGRP EIGRP uses Autonomous Systems to put EIGRP-enabled routers into logical groups. For two routers to become EIGRP neighbors, they must agree on the AS number. To enable EIGRP on a particular interface, we’ll use the network command. The use of wildcard

masks is optional, but you’ll see them in 99% of real-world EIGRP deployments. Just watch that on the exam - EIGRP and OSPF both use wildcard masks in their network statements, not subnet masks.

R1#conf t R1(config)#router eigrp 100 R1(config-router)#no auto-summary R1(config-router)#network 172.12.123.0 0.0.0.255 R2#conf t R2(config)#router eigrp router)#no auto-summary R2(config-router)#network 0.0.0.255

100

R3(config)#router eigrp 100 R3(config-router)#network 0.0.255.255 R3(config-router)#no auto-summ

R2(config172.12.123.0

172.12.0.0

Note that I disabled autosummarization on all three routers. EIGRP has autosummarization running by default, and usually you’re going to disable it even before you enter your network statements! You’ll see why - and what can happen if you don’t disable auto-summarization - later in this chapter. You can also enter the no auto-summary command after your network statements, as shown on R3. Wildcard masks are used when configuring network numbers in EIGRP. This mask type allows the

configuration to be more specific in what interfaces will be running EIGRP. With the above wildcard masks, any interfaces in the network 172.12.123.0 /24 will run EIGRP. Wildcard Masks Wildcard masks do look a little odd at first, but since we use them in access lists, EIGRP, and OSPF, we better know how to configure them! They’re really just “reverse subnet masks”. For instance, the network 172.12.123.0 255.255.255.0 means

that all hosts that begin with 172.12.123 are part of that network. When you write out the network number and the mask in binary and compare the two, the ones in the subnet mask are “care” bits and the zeroes are “don’t care” bits. 172.12.123.0 = 10101100 00001100 01111011 00000000 255.255.255.0 = 11111111 11111111 11111111 00000000 What do I mean by “care” and “don’t care”? For a host to be on

the 172.12.123.0 /24 network, the host’s address must match every bit where there is a 1 in the network mask. After that, I don’t care! Wildcard masks take the opposite approach. The zeroes are “I care”, and the ones are “I don’t care”. In this example, we want to enable EIGRP on all interfaces whose first three octets are 172.12.123, and after that, we don’t care! 10101100 00001100 01111011 00000000 = 172.12.123.0 00000000

00000000

00000000

11111111 = 0.0.0.255 Using wildcard masks takes some getting used to, and just make sure to be careful on your exam: Subnet masks begin with strings of consecutive 1s Wildcard masks begin with strings of consecutive 0s and are required in OSPF network statements, but not EIGRP network statements Now let’s get back to our EIGRP deployment!

A few seconds after configuring the three routers with EIGRP, this console message appears on R1:

The Diffusing Update Algorithm (DUAL) has run and two new neighbors, 172.12.123.2 and 172.12.123.3, have formed adjacencies with R1. Show ip eigrp neighbors gives the details:

The key values are the IP addresses of the EIGRP AS 100 neighbors, the interface on which they were discovered, and the Uptime, indicating how long the neighbor relationship has existed. The loopbacks on each router will now be added to EIGRP 100, as well as the Ethernet segment between R2 and R3. The ethernet segment’s network number is 172.23.23.0 /27, so we get a little more practice with our wildcard masks! The loopbacks all have their router number for each octet, and each loopback has been configured

with a host mask (255.255.255.255 or /32).

The additional configurations:

R1(config)#router eigrp 100 R1(config-router)#network 1.1.1.1 0.0.0.0 R2(config)#router eigrp 100 R2(config-router)#network 172.23.23.0 0.0.0.31 R2(config-router)#network 2.2.2.2 0.0.0.0 R3(config)#router eigrp 100 R3(config-router)#network 172.23.23.0 0.0.0.31 R3(config-router)#network 3.3.3.3 0.0.0.0

show ip route eigrp 100 is then run at each router to ensure each router is seeing the other routers’ loopbacks, and that R1 is seeing the Ethernet segment via EIGRP. R2 and R3 are both directly connected to the 172.23.23.0 /27 network, so

there will be no EIGRP route to that network in their EIGRP tables. The Successor routes appear in two of our three EIGRP tables. The EIGRP Route table, seen with show ip route eigrp, contains only the Successor routes. R1 has two Successor routes for 172.23.23.0 /27. R1#show ip route eigrp 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/2297856] via 172.12.123.2, 00:01:01, Serial0 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/2297856] via 172.12.123.3, 00:00:58, Serial0 172.23.0.0/27 is subnetted, 1 subnets

D 172.23.23.0 [90/2195456] via 172.12.123.2, 00:01:01, Serial0 [90/2195456] via 172.12.123.3, 00:01:01, Serial0 R2#show ip route eigrp 1.0.0.0/32 is subnetted, 1 subnets D 1.1.1.1 [90/2297856] via 172.12.123.1, 00:01:33, Serial0 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/409600] via 172.23.23.3, 00:01:35, Ethernet0 R3#show ip route eigrp 1.0.0.0/32 is subnetted, 1 subnets D 1.1.1.1 [90/2297856] 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.23.23.2, 00:01:49, Ethernet0

As always, the first number in the brackets is the protocol’s Administrative Distance. The second number is the EIGRP metric for that route. Each router sees the other routers’ loopbacks, and can ping them (ping results not shown). R1 can not only ping the Ethernet interfaces of R2 and R3, but has two routes to that subnet in its routing table. EIGRP is performing equal-cost load balancing. The metric for the route is 2195456 for both routes, so data flows going

from R1 to the 172.23.23.0 /27 network will be balanced over the two Frame Relay cloud links. To see the Successor and Feasible Successor routes in EIGRP, run show ip eigrp topology. On R1, two successors for the route 172.23.23.0/27 exist, so both are placed into the routing table as seen previously. There are also two routes for destinations 2.2.2.2/32 and 3.3.3.3/32, but those have not been placed into the EIGRP routing table. Why? R1#show ip eigrp topology IP-EIGRP Topology

Table

for

AS(100)/ID(1.1.1.1) Codes: P - Passive, A - Active, U - Update, Q Query, R - Reply, r - reply Status, s - sia Status 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 1.1.1.1/32, 1 successors, FD is 128256 via Connected, Loopback0 P 172.23.23.0/27, 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

R1 has two valid, loop-free routes to 2.2.2.2/32 and 3.3.3.3/32 in its Topology table… 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

…. but the metrics are unequal, so only the best path (the Successor) is placed into the EIGRP Route table.

R1#show ip route eigrp 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/2297856] 172.12.123.2, 00:12:54, Serial0 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/2297856] 172.12.123.3, 00:12:51, Serial0 172.23.0.0/27 is subnetted, 1 subnets D 172.23.23.0 [90/2195456] 172.12.123.2, 00:12:54, Serial0 [90/2195456] 172.12.123.3, 00:12:54, Serial0

via

via

via via

The metrics for those routes are very close, so close that it’s a good idea for us to use both of them for load balancing. We can use the variance command here to configure unequal-cost load balancing.

The variance Command The variance command is simply a multiplier. The router will multiply the Feasible Distance by this value. Any feasible successor with a metric less than that new value will be entered into the routing table. In print, that sounds a little confusing. In reality, it’s simple, as you’re about to see! Consider the path from R1 to R2’s loopback in the previous tables. The primary route has a metric of 2297856; the other route has a

metric of 2323456. By default, the second route will serve only as a backup and will not carry packets unless the primary goes down. By configuring variance 2 in R1’s EIGRP process, the process multiplies the metric of the best route (2297856) by the variance value: 2297856 x 2 = 4595712 Any feasible successor with a metric less than 4595712 will now participate in unequal-cost load sharing.

R1’s feasible successor to 2.2.2.2 has a metric of 2323456, so it qualifies! After changing the variance value to 2 (by default, it’s 1) and clearing the routing table, show ip route eigrp 100 verifies that two valid routes to both R2’s and R3’s loopbacks appear in the EIGRP routing table. R1(config)#router eigrp 100 R1(config-router)#variance ? Metric variance multiplier R1(config-router)#variance 2 R1#clear ip route * (clears the routing table of all dynamically learned routes)

R1#show ip route eigrp 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/2297856] via 172.12.123.2, 00:00:26, Serial0 [90/2323456] via 172.12.123.3, 00:00:26, Serial0 3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 [90/2297856] via 172.12.123.3, 00:00:26, Serial0 [90/2323456] via 172.12.123.2, 00:00:26, Serial0 172.23.0.0/27 is subnetted, 1 subnets D 172.23.23.0 [90/2195456] via 172.12.123.2, 00:00:26, Serial0 [90/2195456] via 172.12.123.3, 00:00:26, Serial0

The variance command does not actually change the metrics; it makes a higher metric acceptable

for load sharing. Autosummarization - One Default You’ll Want To Change EIGRP and RIP version 2 perform autosummarization by default, which is the act of summarizing network routes when those routes are sent across a network boundary; that is, when they are advertised via an interface that is not part of the network being summarized. In the earlier lab, I disabled autosummarization immediately, but

I will not do so here. To illustrate, we’ll use a hub-andspoke network where both spokes have subnets of 20.0.0.0/8. The Serial interfaces are all on the 172.12.123.0 /24 network, with the router number serving as the final octet. All interfaces will be placed into EIGRP AS 100.

Here are the current configurations. I did not configure the autosummary command -- it’s on by default and will appear in the router configuration. R1: router eigrp 100 network 172.12.123.0 0.0.0.255 auto-summary

R2: router eigrp 100 network 20.1.0.0 0.0.255.255

network 20.2.0.0 0.0.255.255 network 172.12.0.0 auto-summary

R3: router eigrp 100 network 20.3.0.0 0.0.255.255 network 20.4.0.0 0.0.255.255 network 172.12.0.0 auto-summary

Network 20.0.0.0 is discontiguous – there is no single path to all subnets of the major network number. That’s a problem for routing protocols such as RIPv1 that do not carry subnet mask

information. EIGRP and RIPv2 do carry subnet mask information, but the default autosummarization causes trouble with this network. R1 is now receiving the exact same update from both R2 and R3, and it’s for the classful network 20.0.0.0 /8.

Here’s R1’s EIGRP route table. None of the subnets are present in the routing table. R1#show ip route eigrp D 20.0.0.0/8 [90/2297856] via 172.12.123.3, 00:11:19, Serial0 [90/2297856] via 172.12.123.2, 00:11:19, Serial0

Since the metrics for both paths are exactly the same, equal-cost load balancing for the classful network 20.0.0.0 will be performed, ensuring that at least half of the packets destined for any particular subnet of 20.0.0.0 will be going to

the wrong router. If the metric were unequal, a single route for the classful network 20.0.0.0 would be placed into the routing table. All packets for the four subnets will go to the same router, and two of the four subnets will never receive any packets that were originally intended for them. I’ll ping each loopback IP address from R1 - as you’d guess from that routing table, we’re going to get some really interesting results. R1#ping 20.1.1.1

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.1.1.1, timeout is 2 seconds: !U!.! Success rate is 60 percent (3/5), round-trip min/avg/max = 68/68/68 ms R1#ping 20.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.2.2.2, timeout is 2 seconds: U!.!U Success rate is 40 percent (2/5), round-trip min/avg/max = 68/68/68 ms R1#ping 20.3.3.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.3.3.3, timeout is 2 seconds: U!.!U Success rate is 40 percent (2/5), round-trip

min/avg/max = 68/68/68 ms R1#ping 20.4.4.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.4.4.4, timeout is 2 seconds: !U!.! Success rate is 60 percent (3/5), round-trip min/avg/max = 68/68/68 ms

That is one ugly combination of successful pings, timeouts, and Unreachables - and an ugly success rate as well. This default behavior is easily removed with the no auto-summary command. When both of the routers sending updates add this command

to their EIGRP configuration, the routes will no longer be summarized at the network boundary. One often-ignored side effect of adding no auto-summary to an existing EIGRP configuration - the adjacencies will drop. R3(config)#router eigrp 100 R3(config-router)#no auto-summary R3(config-router)#^Z R3#wr 00:26:09: %DUAL-5-NBRCHANGE: IPEIGRP 100: Neighbor 172.12.123.1 (Serial0) is down: summary configured

After configuring no auto-summary on both R2 and R3 and waiting for the adjacencies to reform, R1 now has a much more accurate routing table. R1#show ip route eigrp 20.0.0.0/16 is subnetted, 4 subnets D 20.4.0.0 [90/2297856] 172.12.123.3, 00:00:11, Serial0 D 20.1.0.0 [90/2297856] 172.12.123.2, 00:03:47, Serial0 D 20.2.0.0 [90/2297856] 172.12.123.2, 00:03:47, Serial0 D 20.3.0.0 [90/2297856] 172.12.123.3, 00:00:20, Serial0

via via via via

Bottom line: If you’re running EIGRP and you’re not seeing the subnets or routes you expect, the first thing I’d check is to see if the no auto-summary command is in the configuration. If it’s not, I’d put it there.

router eigrp 100 network 20.3.0.0 0.0.255.255 network 20.4.0.0 0.0.255.255 network 172.12.0.0 auto-summary ” symbol -- that means “valid and best”.

Let’s use another network to illustrate what happens if the mask is just a bit off… R3(config)#int loopback33 R3(config-if)#ip address 255.255.255.0

33.33.33.33

R3(config)#router bgp 200 R3(config-router)#network 33.33.33.33 mask 255.255.255.255

Does R1 see the route?

Nope! Due to the mismatched mask, R3 doesn’t even see the route in its

own BGP table!

The BGP network mask must match the IP routing table’s mask exactly in order for the route to be successfully advertised via BGP. The loopback was configured with a /24 mask, but the BGP network command specified a /32 mask. Here’s how the route looks in the IP routing table: 33.0.0.0/24 is subnetted, 1 subnets C 33.33.33.0 is directly connected, Loopback33

Once we change the BGP network statement to reflect a /24 mask, the route will appear in R3’s BGP table and be successfully advertised to R1 via BGP. We’ll first remove the erroneous network statement and then enter the correct one. R3(config)#router bgp 200 R3(config-router)#no network 33.33.33.33 mask 255.255.255.255 R3(config-router)#network 33.33.33.0 mask 255.255.255.0

All is well! BGP Path Attributes There are two classes of BGP Path Attributes, well-known and optional. To truly understand BGP, you need to know exactly what these attributes are and how they affect BGP.

You must master the application and use of these attributes to pass the CCNP ROUTE exam. Using the network we’ve built to this point, we will now examine these attributes, how to view them, and their impact on BGP path selection. Here are the two categories of well-known attributes, both mandatory and discretionary: Well-known mandatory: AS_PATH, origin, next-hop

Well-known discretionary: local preference, atomic aggregate There are also optional attributes, both transitive and non-transitive. Optional transitive: aggregator, community Optional non-transitive: MED (multi-exit discriminator) Those three mandatory attributes – AS_PATH, origin, and next-hop –

will appear in all BGP update messages sent to neighbors. These are the only three attributes that all BGP speakers must understand. The optional attributes can be a bit of a pain for BGP operation, since not every BGP speaker is going to understand all optional attributes. The difference between “optional transitive” and “optional nontransitive” comes into play here. A BGP path carrying an unrecognized transitive optional attribute will be accepted; if this path is advertised to other routers,

the Partial bit will be set and the attribute advertised to the neighboring router. Basically, marking an attribute as partial is the equivalent of the advertising router saying “I didn’t understand this attribute, but here is it anyway.” An unrecognized non-transitive optional attribute will not be passed on to other BGP speakers. The Origin Attribute The source of the routing update

itself can be viewed with show ip bgp.

There are three possibilities for the Origin code: “i” -- path originated from an IGP via the network command “e” -- path originated from an Exterior Gateway Protocol (EGP) “?” -- Actual origin unclear; learned via route redistribution.

Those are shown in order of most preferred to least preferred, from top to bottom. The AS_PATH Attribute This attribute shows the autonomous systems along the path to the destination network, including the AS the destination network resides in. The shortest AS path is the preferred path. The AS_PATH attribute helps to prevent routing loops; if a router receives an update and sees its own AS number in the path to a

destination, that route will be discarded. In this example, the only AS shown in the path is the AS the network resides in, AS 200.

To see a longer AS_PATH attribute, we’ll add a few extra routers and some additional autonomous systems. Every router will be advertising its loopback address into BGP, and every router’s loopback is its own number in each

octet (R1’s loopback is 1.1.1.1, etc.) Just for fun, we’ll build some multiple BGP peerings between two routers; in production networks, we most likely would not do that.

The BGP configurations of the routers: R1(config)#router bgp 100 R1(config-router)#neighbor 10.1.1.5 remote-as

500 R1(config-router)#neighbor remote-as 100 R1(config-router)#neighbor remote-as 300 R1(config-router)#network 255.255.255.255 R2(config)#router bgp 100 R2(config-router)#neighbor remote-as 100 R2(config-router)#neighbor remote-as 300 R2(config-router)#neighbor remote-as 300 R2(config-router)#neighbor remote-as 400 R2(config-router)#network 255.255.255.255 R3(config)#router bgp 300

172.12.123.2 172.12.123.3 1.1.1.1

mask

172.12.123.1

172.12.123.3 172.12.234.3 172.12.234.4 2.2.2.2

mask

R3(config-router)#neighbor 172.12.123.1 remote-as 100 R3(config-router)#neighbor 172.12.123.2 remote-as 100 R3(config-router)#neighbor 172.12.234.2 remote-as 100 R3(config-router)#neighbor 172.12.234.4 remote-as 400 R3(config-router)#neighbor 172.12.34.4 remoteas 400 R3(config-router)#network 3.3.3.3 mask 255.255.255.255 R4(config)#router bgp 400 R4(config-router)#neighbor 172.12.234.3 remote-as 300 R4(config-router)#neighbor 172.12.234.2 remote-as 100 R4(config-router)#neighbor 172.12.34.3 remoteas 300 R4(config-router)#network 4.4.4.4 mask 255.255.255.255

R5(config)#router bgp 500 R5(config-router)#neighbor 10.1.1.1 remote-as 100 R5(config-router)#network 5.5.5.5 mask 255.255.255.255

Here are the peerings: R1: eBGP to R5, iBGP to R2, eBGP to R3. R2: eBGP to R4, eBGP to R3, iBGP to R1 R3: eBGP to R1, eBGP to R2 via the Serial network, eBGP to R2 via the Ethernet segment,

eBGP to R4 via the Ethernet segment, eBGP to R4 via the Serial interface R4: eBGP to R3 via the Ethernet segment, eBGP to R3 via the Serial connection, eBGP to R2 via the Ethernet segment. R5: eBGP to R1 via the Ethernet segment. R1’s BGP table has at least one entry for every loopback in the network, and multiple paths for

most of them.

The “>” symbol indicates the best path, and therefore the path that will be used. From top to bottom, here’s how BGP selects a best path between multiple valid paths: Highest weight (Ciscoproprietary attribute) Highest local preference (1st

if non-Cisco routers are involved) Locally originated path preferred Shortest AS_PATH Best origin code ( i, then e, then ?) Lowest MED

eBGP over iBGP path lowest IGP metric to BGP next-hop oldest path path from BGP router with lowest BGP RID You really need to know this order to master BGP for the workplace and for your CCNP ROUTE and CCIE exams.

Let’s look at the BGP table from R1 again.

Again, the “>” indicates the path that will be used to reach that particular network. For more detailed information on any particular path, use the show ip bgp command followed by the destination. Before we use that command, though, did you notice that there

seems to be something odd with R1’s path selection for the network 3.3.3.3 and 4.4.4.4? Let’s take a look at the paths to 3.3.3.3 first.

BGP has identified both paths as being valid and loop-free, as indicated by the asterisk. The “>” indicating the best path is next to the path with the next-hop of 172.12.123.3. The first criteria for BGP best path selection is weight, and both paths have a weight of 0. The next criteria is local preference. If the path with the next-

hop of 172.12.234.3 has a local preference of 100, and the other path a local preference of zero, why is the path with the lowest local preference being selected by BGP? Before we answer that, let’s look at R1’s paths for 4.4.4.4:

There are two valid loop-free paths to 4.4.4.4, so BGP must choose the best path. The weights are the same, but again the local preferences seem to favor the next-hop of 172.12.234.4. Even if the local prefs were the same, the AS_PATH

of the path with the next-hop of 172.12.234.4 is shorter than the other path. Then why is the path with the next-hop of 172.12.123.3 being selected? Learn the following command – it will serve you well in the exam room and on the job! R1#show ip bgp 3.3.3.3 BGP routing table entry for 3.3.3.3/32, version 3 Paths: (2 available, best #1, table Default-IPRouting-Table) Advertised to non peer-group peers: 10.1.1.5 172.12.123.2 300 172.12.123.3 from 172.12.123.3 (3.3.3.3) Origin IGP, metric 0, localpref 100, valid, external, best

300 172.12.234.3 (inaccessible) from 172.12.123.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal R1#show ip bgp 4.4.4.4 BGP routing table entry for 4.4.4.4/32, version 7 Paths: (2 available, best #1, table Default-IPRouting-Table) Advertised to non peer-group peers: 10.1.1.5 172.12.123.2 300 400 172.12.123.3 from 172.12.123.3 (3.3.3.3) Origin IGP, localpref 100, valid, external, best 400 172.12.234.4 (inaccessible) from 172.12.123.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal

The show ip bgp command shows us that the paths with a nexthop IP address on the 172.12.234.0 network are shown as valid, and all paths involved have a local pref of 100. Never trust the local prefs you see in the basic show ip bgp command if something looks strange – run this more network-specific version of the command. Two of the routes can’t be used, though, because R1 has no IP connectivity to any host on the

172.12.234.0 segment. R1#ping 172.12.234.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos 172.12.234.3, timeout is 2 seconds: ….. Success rate is 0 percent (0/5)

to

R1#ping 172.12.234.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos 172.12.234.4, timeout is 2 seconds: ….. Success rate is 0 percent (0/5)

to

If a router cannot reach the address listed as the BGP next-hop, the path

cannot be used. To get around this rule, we can use the bgp next-hop-self command on R2. This will force R2 to announce itself as the next hop of all paths advertised to the specified neighbor, in this case R1. R2(config)#router bgp 100 R2(config-router)#neighbor 172.12.123.1 nexthop-self

R1’s BGP table now shows 172.12.123.2 as the next hop for all paths that formerly had 172.12.234.3 or .4 for that value.

Since R1 can reach 172.12.123.2, these paths can now be used by BGP. The route to 4.4.4.4 now has a next-hop of 172.12.123.2. The best route to 3.3.3.3 still has a next-hop of 172.12.123.3, but the next-hop address for the other route to 3.3.3.3 is now 172.12.123.2. Note in the show ip bgp x.x.x.x command output below that there is no inaccessible comment and the next-hop IP addresses have changed there as well.

R1#show ip bgp 3.3.3.3 BGP routing table entry for 3.3.3.3/32, version 3 Paths: (2 available, best #1, table Default-IPRouting-Table) Advertised to non peer-group peers: 10.1.1.5 172.12.123.2 300 172.12.123.3 from 172.12.123.3 (3.3.3.3) Origin IGP, metric 0, localpref 100, valid, external, best 300 172.12.123.2 from 172.12.123.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal 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-IPRouting-Table) Advertised to non peer-group peers: 10.1.1.5 172.12.123.3 300 400 172.12.123.3 from 172.12.123.3 (3.3.3.3) Origin IGP, localpref 100, valid, external 400 172.12.123.2 from 172.12.123.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal, best

For the network 4.4.4.4, the path now in use is the one with the next hop of 172.12.123.2, since its AS_PATH is shorter than the other valid path. The path for the destination 3.3.3.3 is still the path with the next hop of 172.12.123.3.

Since the weights and local prefs are the same, none of the routes originated on R1, the AS_PATH length is the same, the origin code is the same (IGP), and the MED is the same, the next criteria in line is eBGP routes being used over iBGP routes. The path with the next hop of 172.12.123.3 is an eBGP route where the path with the next hop of 172.12.123.2 is an iBGP route. I know that list of BGP best-path selection criteria is long, but sometimes it really does come down to the eighth or ninth tiebreaker. It’s important to know

this list for any real-world job involving BGP - but it won’t hurt on exam day, either. The Next-Hop Attribute We just spent quite a bit of time examining this attribute, but let’s look at the rules for determining the default next-hop. When a BGP speaker sends a route to an eBGP neighbor, the next-hop address is set to the transmitting interface of the router that originated the route. In this example, with R3 advertising its

loopback address to its eBGP neighbor R1, the next-hop will be the IP address of R3’s serial interface.

Makes sense, right? Right! Now here’s the interesting part…. Regarding iBGP routes, for routes originated outside the AS, the next-

hop address will still be the source address of the router in the remote AS that originally sent the route advertisement. When the BGP route arrives at R2, the next-hop address is still that of R3 -- and when there’s no full mesh involved, that can lead to trouble. If R2 does not have an entry in its routing table for the R1-R3 serial network, R1 should announce itself to R2 as the BGP next hop. Otherwise, as you saw in the previous example, the route won’t be entered into the BGP table.

The Multi-Exit (MED)

Discriminator

The MED is an optional attribute that comes in handy when there are multiple entrance paths to an AS. The remote AS sets MED values to tell the other AS which path to use.

The MED is passed between the two autonomous systems, but the value is not passed to any other ASes. The path with the lowest MED is the preferred path. Here, R3 has two possible entry points into AS 100, and therefore two paths to R4. For varying reasons (one of the paths has greater bandwidth available, one of the paths involves a particularly slow or fast router), you may want to influence R3’s path selection from R1 and R2. By sending a MED of 100 from R2

and a MED of 200 from R1, you are actually telling R3 that the path into AS 100 via R2 is more desirable than the path via R1. When you write route-maps to set the MED, there is no “set MED” option. Instead, you are setting the metric value. R1(config)#route-map SET_MED permit 10 R1(config-route-map)#match ip address 1 R1(config-route-map)#set metric 200

To change the MED for all routes sent by that router, use the defaultmetric command in the BGP config.

R1(config)#router bgp 100 R1(config-router)#? Router configuration commands: address-family Enter Address Family command mode aggregate-address Configure BGP aggregate entries auto-summary Enable automatic network number summarizati bgp BGP specific commands default Set a command to its defaults default-information Control distribution of default information default-metric Set metric of redistributed routes

To enable the comparison of the MEDs of routes received from

multiple autonomous systems, use the bgp always-compare-med command. R3(config)#router bgp 200 R3(config-router)#bgp ? always-compare-med Allow comparing MED from different neighbors

The Local Preference Attribute (LOCAL_PREF) LOCAL_PREF is a well-known attribute that is also used when multiple paths between autonomous systems exist. The LOCAL_PREF attribute is just that… local.

Routers within the local AS are told what path to use to exit that AS. The local preference value is passed only among iBGP peers, and this value never leaves the local AS. In the following network, there are two exit paths for routers in AS 100 to reach AS 200. The LOCAL_PREF attribute will be set in AS 100, and it will not leave that AS. The LOCAL_PREF attribute indicates to the routers in AS 100 what path should be taken to AS 200. The path with the highest LOCAL_PREF is chosen.

Changing The Local Preference Attribute

Both R1 and R2 have two paths to the 172.12.34.0/24 network. Examining their BGP tables reveals that R1 will use R3 as a next-hop to reach this network, and R2 will use R4 to reach it.

If we wanted R2 to use R3 as a next-hop instead, the most efficient way to do so is to change the local preference value, shown as “LocPrf” in the BGP table. When the local preference of a path is changed, all routers in the AS will learn about it. Always run show ip bgp followed by the network number when you want to examine local preferences:

R2#show ip bgp 172.12.34.0 BGP routing table entry for 172.12.34.0/24, version 4 Paths: (2 available, best #1, table Default-IPRouting-Table) Advertised to non peer-group peers: 10.1.1.1 34 10.1.1.4 from 10.1.1.4 (4.4.4.4) Origin IGP, metric 0, localpref 100, valid, external, best 34 10.1.1.3 from 10.1.1.1 (172.12.123.1) Origin IGP, metric 0, localpref 100, valid, internal

Since both routes have a local preference of 100, the local preference for the path with the next-hop of 10.1.1.3 will have to be

changed to a higher value. There are two approaches for this. The first is to change the default local preference for a router as a whole, which means that every update the router sends out to other devices in the same AS will carry this new local preference value. Here, we’ll double the default local preference on R1. R1(config)#router bgp 12 R1(config-router)#bgp default ? ipv4-unicast Activate ipv4-unicast for a peer by default local-preference local preference (higher=more preferred) route-target Control behavior based on

Route-Target attributes R1(config-router)#bgp default local-preference 200

Keep using IOS Help, you never know what you may learn! The router is even reminding us that a higher local preference is preferred. (I wouldn’t expect the exam to remind you, though.) Let’s take a look at R2’s BGP table now:

Now the path with the next-hop of 10.1.1.3 is preferred, due to the higher local preference. R2#show ip bgp 172.12.34.0 BGP routing table entry for 172.12.34.0/24, version 5 Paths: (2 available, best #1, table Default-IPRouting-Table) Advertised to non peer-group peers: 10.1.1.4 34 10.1.1.3 from 10.1.1.1 (172.12.123.1) Origin IGP, metric 0, localpref 200, valid, internal, best 34 10.1.1.4 from 10.1.1.4 (4.4.4.4) Origin IGP, metric 0, localpref 100, valid, external

You can also assign new local

preferences to individual prefixes with a route map. Route maps allow you to change attribute values, or assign attributes in the first place, on a route-by-route basis rather than the “all-ornothing” approach other methods offer. For the CCNP ROUTE exam and especially for real-world BGP routers that can contain hundreds of routes, I’d become very comfortable with route maps. We will now remove the bgp default local-preference command

from R1, and add another segment connecting R3 and R4. This segment, 210.1.1.0 /24, will also be advertised into BGP on R3 and R4.

R1(config)#router bgp 12 R1(config-router)#no bgp preference 200

default

local-

R3(config)#router bgp 34 R3(config-router)#network 255.255.255.0

210.1.1.0

mask

R4(config)#router bgp 34 R4(config-router)#network 255.255.255.0

210.1.1.0

mask

Let’s take a look at the BGP tables of R1 and R2 and see what next-hop address each router is preferring for each of our two BGP paths.

If we use the bgp default localpreference command here, it will affect both paths. What if we needed R2 to use 10.1.1.3 as the next hop for data traveling to 172.12.34.0/24, but to continue using 10.1.1.4 as the next hop for 210.1.1.0/24? You see the weakness of the “default” approach. Setting a default local preference somewhere in AS 12 won’t give us what we need, but configuring a route map will. The prefixes that need the higher

local preference first need to be identified by an access-list. I know you know this – but don’t forget that access lists use wildcard masks! R1(config)#access-list 18 permit 172.12.34.0 0.0.0.255

This ACL will match only this particular prefix, with all others being denied by the implicit deny. We’re not denying traffic with this config, though - we’re identifying traffic that should have its local preference doubled. The following route map will

assign a local preference of 200 to all routes matching access-list 18, with all other routes unaffected. R1(config)#route-map PREFER_R3_FOR_172 permit 10 R1(config-route-map)#match ip address 18 R1(config-route-map)#set local-pref 200 R1(config-route-map)#route-map PREFER_R3_FOR_172 permit 20 R1(config-route-map)#set local-pref 100

The route map will be applied to all routes coming in from R3 via the neighbor command. The word “in” at the end of the command indicates the direction of the updates that will be affected by

the route map. R1(config)#router bgp 12 R1(config-router)#neighbor 10.1.1.3 route-map PREFER_R3_FOR_172 ? in Apply map to incoming routes out Apply map to outbound routes R1(config-router)#neighbor 10.1.1.3 route-map PREFER_R3_FOR_172 in

After clearing R1’s TCP connections, R2 now has this BGP table:

R2 still uses the next hop 10.1.1.4 to reach 210.1.1.0/24, but now uses

10.1.1.3 for the next hop to reach 172.12.34.0/24 due to the higher local preference. IOS Help shows us that route maps can be used to set almost any BGP attribute: R1(config-route-map)#set ?

as-path

automatic-tag

Prepend string fo BGP AS attribute Automa comput value set BGP

comm-list

community

dampening

default

extcommunity

commun list (for deletion BGP commun attribute Set BG route fl dampen parame Set defa informa BGP extende commun attribute Output

interface ip level localpreference

metric

metric-type

interfac

IP spec informa Where import BGP lo prefere path att Metric for destinat routing protoco Type of metric f destinat

origin

tag

weight

routing protoco BGP or code Tag val destinat routing protoco BGP w for rout table

Whatever value you need to change in BGP, a route map is most likely the best way to do it, both on the exam and in real life.

Third-Party Next-Hop On occasion, you may see a nexthop address that you don’t expect, particularly in a situation like the next diagram.

R1, R2, and R3 share a broadcast segment. R1 has an eBGP peering with R2, and R2 has an iBGP peering with R3. (Always doublecheck your network documentation or exam exhibit; never assume a full mesh.) R3 will advertise its loopback network, 3.3.3.3/32, to R2 via iBGP. R2 will then advertise the route to R1. R1: router bgp 1500 neighbor 100.1.1.2 remote-as 2000 interface Ethernet0 ip address 100.1.1.1 255.255.255.0

R2: router bgp 2000 neighbor 100.1.1.1 remote-as 1500 neighbor 100.1.1.3 remote-as 2000 interface Ethernet0 ip address 100.1.1.2 255.255.255.0 R3: router bgp 2000 network 3.3.3.3 mask 255.255.255.255 neighbor 100.1.1.2 remote-as 2000 interface Ethernet0 ip address 100.1.1.3 255.255.255.0

As expected, R2’s BGP table shows

100.1.1.3 as the next-hop address to reach 3.3.3.3 /32.

There is no peering between R1 and R3, but R1 should get this route from R2. Since this is an eBGP peering, the route is expected to have a next-hop address of 100.1.1.2….. right?

Wrong! :)

The next-hop is 100.1.1.3. This is due to third-party next-hop, and outside of RFCs, you don’t hear much about this rule. A BGP speaker is allowed to advertise the IP address of an internal peer as the next-hop address IF the external peer receiving the route has a subnet in common with the internal peer. Howzat for an “if”? Since R1 and R3 share a subnet, R2 is allowed to send the IP address of the internal peer, 100.1.1.3, as the next-hop address.

This built-in feature is designed to bring about the most accurate routing possible, and in this example it does just that. R2 is advertising the route to an external peer, but R2 also knows that the external peer (R1) shares a subnet with the internal peer (R3). R2 then advertises the route with a next-hop of 100.1.1.3, resulting in R1 having the most direct path to 3.3.3.3/32. The Weight Attribute Weight is the first value considered in BGP path selection among multiple paths.

There are three other major points to remember about this BGP attribute: Cisco-proprietary value locally significant to a router is never advertised to other routers The path with the largest weight is preferred. The default weight for a route originated on the local router is 32768, and it’s zero for all other

routes. Adjusting The Weight Attribute The R1-R2-R3 network is 172.12.123.0 /24, and the R2-R3R4 segment is 10.1.1.0 /24. All final octets are the router’s number. There is no iBGP peering between R2 and R3. R4 is advertising its loopback address of 4.4.4.4/32 into BGP. All peerings, both iBGP and eBGP, are shown with dotted lines.

R1(config)#router bgp 123 R1(config-router)#neighbor remote-as 123 R1(config-router)#neighbor remote-as 123

172.12.123.2 172.12.123.3

R2(config)#router bgp 123 R2(config-router)#neighbor 172.12.123.1 remote-as 123 R2(config-router)#neighbor 10.1.1.4 remote-as 4 R2(config-router)#neighbor 172.12.123.1 next-

hop-self R3(config)#router bgp 123 R3(config-router)#neighbor 172.12.123.1 remote-as 123 R3(config-router)#neighbor 10.1.1.4 remote-as 4 R3(config-router)#neighbor 172.12.123.1 nexthop-self R4(config)#router bgp 4 R4(config-router)#neighbor 10.1.1.2 remote-as 123 R4(config-router)#neighbor 10.1.1.3 remote-as 123 R4(config-router)#network 4.4.4.4 mask 255.255.255.255

R1 has two paths to 4.4.4.4/32. The path with the next hop 172.12.123.2

is in use, as indicated by the “>” symbol indicating the best route.

That particular path was chosen by the BGP route selection process, and just to review, here’s that process again: Highest weight Highest local pref Locally originated path (next

hop of 0.0.0.0 in show ip bgp) Shortest AS_PATH Lowest origin code ( i, e, ?) Lowest MED (if remote AS is same for all routes) External BGP over Internal BGP Lowest IGP metric to next-hop

address Oldest route Lowest BGP RID Lowest neighbor IP address (if there’s a tie here, you have a problem!) We went all the way down to the final tiebreaker in this scenario, because all of the preceding criteria were the same. If you’re in an all-

Cisco environment, it makes sense to change the weight of a route to make it the preferred route, since that is the first criteria checked. The weight for both routes is 0, so we’ll use the neighbor command to set the weight for all routes learned from 172.12.123.3 to 200.

The weight for the route with a next-hop of 172.12.123.3 is now 200, making it the preferred path.

The weight attribute is Ciscoproprietary, so in a multi-vendor environment we’d change the local pref to get a similar result. This change to a route’s weight is locally significant only -- R1 will not advertise this route with a weight of 200. The Atomic Aggregate Attribute You should get 20 exam points just for saying that fast. But you won’t, so let’s take a quick look…

When BGP paths are aggregated, this well-known attribute indicates the router that performed the aggregation. This attribute gives notice to downstream routers that more-specific BGP routing information was lost at the point of aggregation. That’s all fine - but what’s “aggregation”? It’s just another term for summarization. You’ll perform this summarization the same way you did for EIGRP and OSPF routes - but BGP has an interesting default that those two protocols do not have. Stay tuned.

The Aggregator Attribute This optional attribute gives the BGP Router ID and AS number of the router that performed the aggregation. The aggregator attribute will also include a list of all the AS numbers that these aggregated routes passed through. The Community Attribute This attribute allows us to logically group routers that have a common configuration, making them members of a community. Creating BGP communities can save you a

lot of work, as you’ll see later in this section. And who doesn’t like less work? The Originator ID and Cluster ID Attributes Both these optional attributes can be put into effect when route reflectors are used. We’ll examine these attributes during the route reflector discussion. BGP Route Aggregation (Not AggreVation) In your CCNA studies, you learned

how to perform manual route summarization in both RIPv2 and EIGRP. BGP Route Aggregation works much the same way – the routes to be summarized, or aggregated, should be written out in binary and the common bits identified. These common bits yield both the aggregate route and the subnet mask, and we need both of those to get the desired result. BGP route aggregation gives us choices that RIPv2 and EIGRP did not. You’ll remember that when manual summarization was configured with those two

protocols, the interface would send out only the summary route and mask. With BGP, we can send out only the aggregate route and mask, or the aggregate route along with the more-specific routes. The following network will be used to illustrate route aggregation.

On R5, additional loopback addresses have been configured: 16.1.1.1, 17.1.1.1, 18.1.1.1, and 19.1.1.1, all with /8 masks. They will now be advertised via BGP. R5(config-if)#router bgp 500 R5(config-router)#network 255.0.0.0 R5(config-router)#network 255.0.0.0 R5(config-router)#network 255.0.0.0 R5(config-router)#network 255.0.0.0

16.0.0.0

mask

17.0.0.0

mask

18.0.0.0

mask

19.0.0.0

mask

The downstream router, R1, has all

four of these routes in its BGP table.

This is fine, but we know it’s a good idea to keep all routing tables as concise as possible while also keeping them complete. We can aggregate these four routes and advertise them as one aggregate route. First, it’s time for our old friend binary math! Since these networks all have “0” for the last three octets,

we’ll only convert the first octet here. Common bits are highlighted. 16 17 18 19

00010000 00010001 00010010 00010011

Working from left to right, we see that the four networks have the first six bits in common. The value of the first six bits is 16, and the first six bits will be the bits that are set to “1” in the aggregate mask. This

binary string of 11111100 yields a mask of 252.0.0.0. We’ll inject the aggregate route into BGP via the aggregate-address command.

R1 sees the aggregate and places it into its BGP table. Note that by default, the more-specific routes are not removed from the BGP table. With EIGRP, RIP, and OSPF summarization, those routes were gone.

To suppress the advertisement of the more-specific routes, use the summary-only option with the aggregate-address command. It’s common to have an “oh, yeah, now I remember that” moment (OYNIRTM) at that point in your config. If that happens to you, I recommend you remove the first aggregate-address command before writing the one with the summary-only option.

There’s one more option with the aggregate-address command you should know about. Actually, there are several other options, but one more big one for the CCNP ROUTE exam. You can learn the others when you go after your CCIE! R5(config-router)#aggregate-address 252.0.0.0 summary-only ?

advertise-

16.0.0.0

Set conditi

map

as-set attributemap

route-map

summaryonly

to advertise attribute Generate A set path information Set attribut of aggregat

Set parameters aggregate Filter more specific routes from updates Conditiona filter more

suppressmap

specific routes from updates

If you use the as-set option, the path advertised for this route will be an AS_PATH that was traveled by all of the more-specific paths being aggregated. Cisco recommends that you do not use this option when a great number of paths are being aggregated, since the aggregate may be removed, updated, and replaced as AS-path reachability changes. Why aggregate routes in the first place? For the same reason we did

so with other protocols – route aggregation lessens the load on router resources by making the routing tables smaller while still being complete and accurate. T-shooting hint: If your aggregate route isn’t being advertised, be sure your BGP table actually has the routes being summarized. Resetting and Clearing The BGP Peer Connections Sometimes you’ll find it necessary to reset the TCP session between

BGP speakers. Not all changes require this. For example, the route aggregation we just performed required no such reset. There is a “hard reset” and a “soft reset” -- The clear ip bgp * command performs a hard reset where the TCP session itself is reset: R1#clear ip bgp * R1# 09:18:36: %BGP-5-ADJCHANGE: neighbor 10.1.1.5 Down User reset 09:18:36: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Down User reset 09:18:36: %BGP-5-ADJCHANGE: neighbor

172.12.123.3 Down User reset

With this command, the BGP sessions themselves are reset and the neighbor adjacencies are lost. The adjacencies you see here came back within 20 – 40 seconds, but BGP reachability was lost during that time. To clear the sessions without resetting the sessions, use the soft option, as shown here: R1#clear ip bgp * soft

Internal BGP: Synchronization,

Full Meshes, Reflectors

and

Route

We know all about eBGP and iBGP at this point. Now we need to learn the important operational differences between the two. These are vital to success on the ROUTE exam and working with BGP in real-world networks. Here are some basic rules and guidelines in working with iBGP networks… iBGP neighbors do not have to be directly connected. The connection between iBGP

routers is on TCP port 179. It’s common practice to use a remote router’s loopback address in the neighbor statement, rather than the closest physical address. This allows us to keep our BGP adjacencies in situations where losing the physical address would result in losing that adjacency. iBGP routers do not send updates to every single

neighbor. The only way an iBGP router will advertise a route to its neighbors is if the route was created by the transmitting router via the network command, by static route redistribution, IGP route redistribution, or if the advertised route is a connected route in the first place. This means that when a iBGP speaker learns about a route from an iBGP peer, the only kind of BGP router that route can then be advertised to is an eBGP router.

iBGP routers do not advertise routes received from one iBGP neighbor to other iBGP neighbors. In theory, this would mean that every AS would have to be fully meshed in order for routes to be properly advertised. In the real world, this would create a great deal of overhead. Thankfully, this is unnecessary overhead, because BGP gives us a way around having to create such a logical nightmare. Before we take a look at this solution, let’s examine BGP’s rule of synchronization.

The BGP rule of synchronization only matters when an AS is going to serve as a transit area, and if there are non-BGP speakers in the transit area.

In the illustration, AS 200 is serving as a transit area between AS 100 and AS 500. The issue is that the only iBGP neighbor

relationship is between R2 and R4. This is a logical relationship only; when R4 wants to send data to 200.20.0.0, it has to physically go through R3. Since R3 is not running BGP, it can’t possibly know about this network, so R3 will drop packets destined for 200.20.0.0. Without the synchronization rule, R4 would advertise a path to 200.20.0.0 over its eBGP connection to R5. Of course, R5’s packets destined for this network would be dropped at R3 as well.

The BGP Rule Of Synchronization states that a transit AS will not advertise a route until every router in the transit AS has the route in its IGP routing table. R4 will not send an advertisement for network 200.20.0.0 to R5 until R4 hears an advertisement for that network from R3 via an IGP; that indicates that the non-BGP speaking R3 has a route for that network. BGP Synchronization’s major benefit is that packets that can’t possibly reach the desired remote network will not even be sent,

reducing both the amount of unnecessary traffic and the unnecessary strain on router resources. After all, why send those packets if they can’t reach the destination? BGP Synchronization is turned off in many deployments, though, and as of IOS version 12.2(8) it’s turned off by default. There are three scenarios under which it’s safe to turn synchronization off: 1. If all the routers in the AS are running BGP. 2. If a full mesh exists in the

AS. 3. If the AS is not a transit AS to begin with. To do so, simply run the BGP command no synchronization. R1(config)#router bgp 100 R1(config-router)#no synchronization

The Problem With BGP Full Mesh Deployments BGP’s rule of Split Horizon is much different than the Split Horizon rules you learned in your CCNA studies.

BGP Split Horizon states that one iBGP peer can’t learn about a path from one iBGP peer and then advertise it to another iBGP peer. Therefore, we would need a logical full mesh among all iBGP speakers in an autonomous system. You know how we see very few full meshes in Frame Relay? There’s a reason - and it’s the same reason we don’t see many BGP full meshes. Any full-mesh deployment of BGP is going to have a large cost on the router’s resources (memory, CPU).

A full mesh is going to require a large number of TCP connections, and the more routers you have, the more connections you’ll need. Take an AS with 20 routers. The formula for determining the number of connections needed for a full mesh is: X (x – 1) / 2, with “x” being the number of routers This formula for 20 routers: 20 (20 – 1) / 2. That’s 20 x 19, which is 380, divided by 2, which is 190. BGP requires 190 separate TCP

connections for a 20-router AS! Add this to the administrative nightmare you’ll have in creating this full mesh, along with the additional configurations that will be needed when routers are added or removed from the AS, and you’ve got quite a labor-intensive situation. Three good reasons to avoid fullmesh iBGP deployments: An unnecessarily large number of TCP sessions are created.

These sessions use a lot of bandwidth. You’re going to spend a lot of time configuring all these peer connections, and sooner or later, you’re going to miss one (especially in a large AS). Then you get to spend even more time troubleshooting your network! Luckily, there’s a way around the BGP Split Horizon rule – route reflectors.

Route Reflectors BGP route reflectors are the exception to the BGP Split Horizon rule. A router configured as a BGP route reflector can take a route learned from one iBGP peer and advertise it to another iBGP peer. The iBGP peers that will be sending routes to the route reflector are referred to as clients. When one client sends a route to the route reflector, the RR does just that – it reflects the route to the other clients.

To the clients, this is a totally transparent process. The clients don’t even know they are clients, and they require no additional configuration. All clients must peer with the RR. Clients will not have a peer relationship with other clients. This allows us to have BGP work with a partial mesh rather than a full mesh. Remember how we would need 190 separate TCP connections in a 20router AS? If you have a single router act as an RR in the same 20router AS, we’d need the RR to

have a peering with each of the clients, and each of the other 19 BGP speakers (clients) would have a single BGP peer relationship back to the RR. This would result in only 38 total TCP connections being needed. That’s a huge reduction in the overhead caused by all those TCP connections, not to mention the hours of configuration and troubleshooting you’ll save. A BGP speaker that has a peer relationship to an RR does not have to be a client; these speakers are

called nonclients. Nonclients do have to have a TCP connection to every other router in the AS. Let’s take a look at how route reflectors impact a network. The following BGP peer relationships are in place and are indicated with dotted lines. Synchronization has been disabled. All interface IP addresses end with the router’s number. R1 / R2 / R3 are on a frame network, 172.12.123.0 /24. R2 / R3 / R4 are on an ethernet

segment, 10.1.1.0 /24. Each router has a loopback with its own number for each octet (1.1.1.1, etc.). Peers: R1: Peering with R2 and R3. R2: Peering with R1. R3: Peering with R1 and R4. R4: Peering with R3.

R4 is in AS 4, and will advertise its loopback (4.4.4.4 /32) into BGP. R3 has R4’s loopback in its BGP table:

What about the other routers in AS

1235? Will they have this route in their BGP tables? Let’s first look at R3’s iBGP peer, R1:

The route is there… but there is no “>” next to the route, so this is not a “valid and best” route. Here’s a good three-step t-shooting process for BGP - and for just about anything else in Ciscoworld: What is the problem?

If we don’t immediately know what the issue is, what command will show us what the problem is? Once we’ve identified the issue, how can we solve it? The problem: The next-hop address for this route, 10.1.1.4, is unreachable from R1. Never assume IP connectivity! The command that verifies this: show ip bgp 4.4.4.4.

The solutions: Use dynamic or static routing to get a route to 4.4.4.4 in R1’s IP routing table, or configure next-hop-self on R3. Let’s get some practice with nexthop-self: R3(config)#router bgp 1235 R3(config-router)#neighbor 172.12.123.1 nexthop-self R3#clear ip bgp * soft

The result is a next-hop address that R1 can reach, so the BGP route is

now valid and best.

What about R1’s iBGP peer, R2? R2#show ip bgp R2#

When you run a show command on a Cisco router and are immediately back at the enable prompt, that means there is nothing to show you. R2 does not have the route in its BGP table due to BGP’s Split Horizon rule. R1 learned about the

route from an iBGP peer, and therefore cannot advertise that route to other iBGP peers. The same thing happens if R2 advertises its loopback to R1. R1 can put the route in its BGP table, but cannot advertise the routes to its other iBGP peer, R3. R2(config)#router bgp 1235 R2(config-router)#network 255.255.255.255

2.2.2.2

mask

R1 will see the new route as valid and best….

… but will be unable to advertise it to R3.

R3 doesn’t have the route to R2’s network, since it was learned by R1 via an iBGP peer (R2) and can’t be advertised to another iBGP peer (R3). There are two solutions to this issue. The first is to create a full mesh in AS 1235. Using the formula

mentioned earlier, this solution would require 4 x (4-1) /2 connections, or 6 separate TCP connections. This solution requires more of a router’s resources, and will take additional time to configure and possibly troubleshoot -- and it’s a horribly non-scalable solution. We always have to plan for future growth, and the more growth we have with a full mesh, the more administrative and logical overhead we have.

A much more scalable solution is to configure R1 as a route reflector. R2 and R3 will be the route reflector clients. These routers will require no additional configuration. R1 will identify these two neighbors as route reflector clients, allowing R1 to advertise routes learned via iBGP peers to other iBGP peers. R1(config)#router bgp 1235 R1(config-router)#neighbor 172.12.123.2 routereflector-client

00:34:00: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Down RR client config change R1(config-router)#neighbor 172.12.123.3 routereflector-client 00:34:12: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Down RR client config change 00:34:27: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Up 00:34:38: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Up

The results here may be different than those you’ve seen elsewhere. Configuring a BGP peer as a route reflector client will bring down the peer connection. As you can see from the timestamps, they were only down for 25 to 30 seconds, but it’s

an important point to remember. Especially on production networks! :) Let’s look at the BGP tables of the route reflector clients after the adjacency reforms.

The route reflector is working perfectly. Route reflectors serve two major

purposes. First, they reduce the number of TCP connections needed in an iBGP deployment. Just as importantly, route reflectors allow us to get around the rule of BGP Split Horizon – because unlike other protocols you studied to get your CCNA, you can’t turn BGP Split Horizon off at the interface level. So if BGP Split Horizon is there to prevent routing loops, why don’t we have routing loops form when using route reflectors and effectively disabling Split Horizon? We’re going to answer that in just a

moment. First, let’s do a little verification. To verify that a router is seen as a route reflector client, run show ip bgp neighbor x.x.x.x. This is an excellent command for overall BGP troubleshooting. This is a verbose command to say the least, but there’s some great information here. Below you can see that 172.12.123.2 is seen as a route reflector client. I’m only showing you about half of this command’s output since the second half is more for Cisco TAC (Technical

Assistance Center) calls, but at the bottom of this output you can see the number of adjacency resets and the reason for the last one. Pretty cool! R1#show ip bgp neighbor 172.12.123.2 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:00:41 Last read 00:00:41, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised Address family IPv4 Unicast: advertised and received Received 881 messages, 0 notifications, 0 in queue Sent 890 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0

Default minimum time between advertisement runs is 5 seconds For address family: IPv4 Unicast BGP table version 6, neighbor version 6 Index 1, Offset 0, Mask 0x2 Route-Reflector Client NEXT_HOP is always this router Outgoing update prefix filter list is NO16THROUGH19 0 accepted prefixes consume 0 bytes Prefix advertised 17, suppressed 0, withdrawn 0 Number of NLRIs in the update sent: max 5, min 0 Connections established 4; dropped 3 Last reset 00:01:09, due to RR client config change

Clusters And The Originator-ID

Attribute BGP Clusters are a combination of route reflectors and clients that are sharing information. Note that I said “reflectors”, not “reflector”. There can be more than one route reflector in a cluster. When deciding on the routers that will be the route reflectors in a cluster, you should consider both the peering relationships in place (and the ones that would need to be added to make the route reflector work) and the impact on router resources that being an RR creates.

Make sure the routers that will serve as the route reflectors in your network possess the resources to get the job done. If BGP Split Horizon is intended to stop routing loops, why is Split Horizon not an issue with clusters? Because the Originator-ID identifies the router that originated the path. This attribute is set by the route reflector and effectively eliminates the chance of a routing loop. If the router that originated the route receives the route in an update, the update will be discarded.

Where Do Route Reflectors Send Routes? Route reflectors have three possible types of peers – clients, nonclients, and eBGP peers. How a route reflector handles the update depends on the device that sent the update: Updates from RR clients are sent to all client and nonclient peers. Updates from eBGP peers are sent to all client and nonclient

peers. Updates from nonclient peers are sent to all clients in the cluster.

Prefix Lists Once you’ve got the basic BGP configuration up and running, it’s time to fine-tune the routes being advertised… … or maybe the routes you don’t want advertised.

BGP gives us several tools with which to control the flow of network advertisements, and the first of these is the prefix list. Cisco states several reasons for the use of prefix lists…. support for incremental updates their high flexibility writing BGP prefix lists is much easier than writing access-lists that filter BGP

updates. (Trust me, they’re right.) The major reason for using BGP prefix lists is that filtering BGP with prefix lists is much faster and efficient than other methods. Why? BGP tables can be huge, and since prefix lists are going to match only on the prefix of the address, the entire process is much faster than using ACLs. It’s also easy to go back and insert lines in the middle of a pre-existing

prefix list, which is great when you’ve written a 20-line list and suddenly have the need to put a line at position 12. Before we look at the actual configuration, let’s look at the theory of how a BGP prefix-list operates. It’s quite similar to an ACL. First, if a route is expressly permitted, it’s used; if it’s denied, it’s not used. (Makes sense!) Also lurking at the bottom of every prefix list is our old friend, the implicit deny. The implicit deny here works the same as it does in an

ACL. Remember that if a prefix is not expressly permitted, it’s implicitly denied, and any explicit deny statements do NOT override the implicit deny. Prefix lists work from top to bottom, just like ACLs, and when a match is found, the list stops running. Prefix list statements are all numbered, with the lowest numbers at the top, so the line with the smallest sequence number that matches the prefix will be the one that matches. Even if you don’t actually number

the statements as you write the prefix list, they’re numbered by default – each line you write is numbered with the sequence number incrementing by 5 for every line you write. This makes it easy for you to go back and add lines that you might have forgotten to put in, or when the need arises later to add lines. To see prefix lists in action, we’ll use this network:

The R1/R2/R3 network is our old friend 172.12.123.0/24, and the R1R5 segment is 15.1.1.0/24. Dotted lines indicate BGP peers. In this example, R5 has four additional loopbacks that will be advertised into BGP in addition to

5.5.5.5/32. 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 ! R5(config)#router bgp 5 R5(config-router)#network 255.255.255.255 R5(config-router)#network 255.0.0.0 R5(config-router)#network

5.5.5.5

mask

16.0.0.0

mask

17.0.0.0

mask

255.0.0.0 R5(config-router)#network 255.0.0.0 R5(config-router)#network 255.0.0.0

18.0.0.0

mask

19.0.0.0

mask

The downstream routers R1, R2, and R3 all see the routes. Will they be valid and best on all routers?

The unreachable next-hop address rears its ugly head again, as neither R2 nor R3 have a route for 15.1.1.5. We’ll remedy that with the appropriate next-hop-self commands on R1. R1(config)#router bgp 123 R1(config-router)#neighbor 172.12.123.2 nexthop-self R1(config-router)#neighbor 172.12.123.3 nexthop-self

Let’s verify that command’s effect by checking the BGP tables on R2

and R3.

Now both R2 and R3 have all five routes in their BGP tables, and they are “valid and best”. Sometimes, though, you don’t want every router in a network to have every available route.

Let’s say that you want R1 to know about all five networks, but R2 and R3 should not. We do want R2 and R3 to keep the route to 5.5.5.5/32, though. A prefix list written on R1 and applied to neighbors R2 and R3 will do this. Let’s write and examine the prefix list first: R1(config)#ip prefix-list deny 16.0.0.0/8 R1(config)#ip prefix-list deny 17.0.0.0/8 R1(config)#ip prefix-list deny 18.0.0.0/8 R1(config)#ip prefix-list deny 19.0.0.0/8 R1(config)#ip prefix-list permit 0.0.0.0/0 le 32

NO16THROUGH19 NO16THROUGH19 NO16THROUGH19 NO16THROUGH19 NO16THROUGH19

Don’t forget your up arrow when writing prefix lists. That will save you a lot of typing. Also, give your prefix list an intuitive name where those who follow behind you can tell what the purpose of the prefix list is in the first place. that also helps you remember why you wrote it in the first place! That last line looks a little strange, doesn’t it? This is the prefix list equivalent of an ACL’s “permit any” statement. Remember, the four explicit deny statements do NOT override the unseen implicit deny.

The only way to avoid the implicit deny is to write an explicit statement that permits all prefixes. Before we apply the prefix list, let’s use IOS Help to illustrate what “le” means. R3(config)#ip prefix-list NO16THROUGH19 permit 0.0.0.0/0 ? ge Minimum prefix length to be matched le Maximum prefix length to be matched R3(config)#ip prefix-list NO16THROUGH19 permit 0.0.0.0/0 le 32

“le” means “less than or equal to”; “ge” means “greater than or equal

to”. Now to apply this prefix list to the neighbors R2 and R3. R1(config)#router bgp 123 R1(config-router)#neighbor 172.12.123.2 prefixlist NO16THROUGH19 out R1(config-router)#neighbor 172.12.123.3 prefixlist NO16THROUGH19 out

After resetting the connections to R2 and R3, those two routers no longer see the networks 16 – 19.0.0.0/8, but still see the route for 5.5.5.5 /32.

As with ACLs, you’ve got a few options when it comes to viewing prefix lists and their contents. The basic command is show ip prefixlist. R1#show ip prefix-list ip prefix-list NO16THROUGH19: 5 entries seq 5 deny 16.0.0.0/8 seq 10 deny 17.0.0.0/8 seq 15 deny 18.0.0.0/8 seq 20 deny 19.0.0.0/8 seq 25 permit 0.0.0.0/0 le 32

Notice that the first line of the

prefix list was numbered “5”, and each line increments by five, even though we entered no sequence numbers while writing the list. These numbers do make it very easy to go back and add lines exactly where you want them. Let’s say that after writing this list and applying it, you realize you want the network 16.1.0.0 /16 to be allowed while denying all other networks with the prefix 16.0.0.0/8. Using the sequence numbers, we can add such a line so that it is read before the line that denies all networks with the prefix 16.0.0.0/8.

R1(config)#ip prefix-list NO16THROUGH19 ? deny Specify packets to reject description Prefix-list specific descriptin permit Specify packets to forward seq sequence number of an entry R1(config)#ip prefix-list NO16THROUGH19 seq 2 permit 16.1.0.0/16

R1#show ip prefix-list ip prefix-list NO16THROUGH19: 6 entries seq 2 permit 16.1.0.0/16 seq 5 deny 16.0.0.0/8 seq 10 deny 17.0.0.0/8 seq 15 deny 18.0.0.0/8 seq 20 deny 19.0.0.0/8 seq 25 permit 0.0.0.0/0 le 32

The line we added with the sequence number “2” was put just

where we wanted it – at the top of the prefix list. In this order, an update for the network 16.1.0.0/16 would be permitted while all other networks matching 16.0.0.0/8 will be denied. Peer Groups BGP Peer Groups help to lower the impact of routing on the router’s resources, as well as lowering the amount of actual configuration needed for multiple peerings in BGP.

Anything that lessens both our workload and the CPU workload is fine with me! This is a very powerful concept and you’ll definitely see this anywhere you work with BGP. Peer group members inherit the settings applied to the peer group, which is really the whole point of creating peer groups.

R1 will peer with R2, R3, and R5. R1 will have the same outbound policy for all three routers. This allows the configuration of a BGP Peer Group. (Peer group members can have separate inbound policies.) In the config below, the second line names the peer group, the third line identifies the AS number, and the fourth line applies the same routemap to all members of this peer group. Finally, the members of the

peer group are identified with neighbor statements. R1(config)#router bgp 1235 R1(config-router)#neighbor AS1235GROUP peer-group R1(config-router)#neighbor AS1235GROUP remote-as 1235 R1(config-router)#neighbor AS1235GROUP route-map AS_POLICY out R1(config-router)#neighbor 2.2.2.2 peer-group AS1235GROUP R1(config-router)#neighbor 3.3.3.3 peer-group AS1235GROUP R1(config-router)#neighbor 5.5.5.5 peer-group AS1235GROUP

As you add neighbors in AS1235, you only have to type one line per new neighbor - the neighbor

command followed by the IP address of the neighbor used for the peer relationship and the name of the peer group. Note the direction of the route-map shown above - it’s outbound. To repeat, peer group members are required to share the same outbound policies. They can share the same inbound policies, but they don’t have to. Peer group names are locally significant only - the name of the group isn’t passed to other routers. This means you can reuse the name

throughout the network, but I’d be careful about that - it can get a little confusing to the network admins. Peer groups take a little getting used to, but they’re a very efficient way of configuring routers. Not to mention saving you a lot of typing! :) BGP Confederations BGP Confederations are a logical grouping of autonomous systems that appear to outside BGP speakers as a totally separate AS.

In other words, a BGP Confederation is a logical grouping of logical groups. Yeah, I know. It makes more sense when you see a picture… The internal AS numbers are not known to any BGP speaker outside the Confederation. Using BGP Confederations also limits the number of iBGP peer connections just as with route reflectors, a full mesh is not needed. In the following example, R9 is totally unaware that there is a confederation, and knows only of the existence of AS 321. R9

has no idea that AS 321 actually contains three other autonomous systems.

R1’s configuration will look like this: R1(config)#router bgp 123 R1(config-router)#bgp confederation identifier

321 (assigns number 321 to the confederation; this will be the AS number seen by R9) R1(config-router)#bgp confederation peers 7 671 (identifies the other AS numbers that are part of the confederation) R1(config-router)#neighbor 9.9.9.9 remote-as 9 R1(config-router)#neighbor 2.2.2.2 remote-as 123 R1(config-router)#neighbor 3.3.3.3 remote-as 123 R1(config-router)#neighbor 5.5.5.5 remote-as 7 R1(config-router)#neighbor 6.6.6.6 remote-as 671 R9’s neighbor statement for R1 will refer to AS 321, the confederation number. R9(config)#router bgp 9 R9(config-router)#neighbor 1.1.1.1 remote-as 321

Communities BGP communities allow us to tag a route or group of routes with a common value that will follow it throughout the rest of the network. (A good way to remember this is the simple phrase “Communities equal consistency.”) Communities are transitive optional attributes. Some common community values: NO-EXPORT: Marking a route with this community attribute prevents it from being advertised to an eBGP peer.

NO-ADVERTISE: Taking the previous community one step further, this community attribute prevents the route from being advertised to ANY other router. The available communities change often, with new ones added, so I recommend you check Cisco’s website for the available communities for your IOS. You’ll have to master them to become a CCIE. Internet Connections And BGP

Four little words, so much potential for trouble. Working with BGP can become quite a complex endeavor, and trying to tell you everything about BGP and internet connectivity here is, well, impossible. We’re going to take a few minutes here and look at some basic design guidelines and some introductory terminology. The first term is multihoming. This is a BGP configuration where multiple connections to the internet exist. This allows for load balancing as well as redundancy – you don’t want to have internet

connectivity cut off if one path goes down. Single points of failure are never good, but can be positively crippling with BGP. From the ISP’s point of view, there are three ways to handle sending routes to the BGP AS: Send default routes only into the AS. (Low resource usage uses the least memory of these three options.) Send default routes and selected more-specific routes

into the AS. Send all routes into the AS. (High resource usage - uses the most memory of these three options.) If the ISP sends only default routes into the AS, the non-BGP speakers in the AS will naturally use the path with the best metric to reach external destinations. With the other two choices, BGP will generally use the AS_PATH value to decide how routers in the AS should reach

external destinations. The ISP has to walk a line between having morespecific routing tables and overtaxing router resources. Communications Between Your Router And ISP

Having more than one connection to an ISP, or having connections to multiple ISPs, is great for redundancy but can be tough on the router. Hopefully you’ve got a brand-new top-of-the-line router for R6 here, but that isn’t always the case. The amount of CPU and memory on this router is especially critical, and can impact the type of routes you should be receiving from your ISP. If R6 has plenty of memory and CPU (and yes, “plenty” is an

arbitrary term), you should be okay getting specific routes from the ISPs. If memory and CPU are a concern, you should consider receiving only a default route from the ISPs. Receiving only default routes causes the least stress on your router resources. You can opt for a combination of default and more-specific routes, but in the real world, you’ve usually got a router that can handle the load of specific routes or a router that can only handle default routes.

IGP < > BGP Redistribution Warning: Don’t ever, ever, ever perform redistribution between IGP and BGP unless you really know what you’re doing. And I mean really know what you’re doing. That’s what practice labs are for! Route redistribution isn’t always bidirectional. You can redistribute RIP routes into an EIGRP AS without taking the EIGRP routes and placing them into RIP. What’s all this got to do with BGP, you ask? At times, it may be

necessary for you to place IGP routes into the BGP routing table. There are three ways to do this: the network command, redistribution of static routes, and redistribution of dynamically learned IGP routes. Cisco recommends you avoid the last choice whenever possible, and so do I. That form of redistribution can easily lead to routing loops. The network command is generally your best bet. We have the ability to redistribute BGP routes into an IGP, but there is rarely good reason to do so. The

basic reason this is usually a bad idea is simple; the Internet has a LOT of routes, many more routes than your network is going to be equipped to handle. A full BGP routing table can have over 90,000 routes. Another danger to avoid – routes learned via an IGP in one AS should never be redistributed to other autonomous systems via BGP. You’re begging for a routing loop. Private AS Numbers

BGP allows you quite a bit of range when it comes to selecting an AS number: R1(config)#router bgp ? Autonomous system number

Just as there are private IP addresses, there are private AS numbers. The AS numbers 64512 65535 are considered “private” AS, and just as private IP addresses should not be advertised to external networks, neither should private AS numbers. Public or private, you can’t assign AS number zero with BGP, just as

you couldn’t with EIGRP. show ip bgp neighbor vs. show ip bgp summary For OSPF and EIGRP, the show ip ospf neighbor and show ip eigrp neighbor commands are the way to check on adjacencies. For BGP, while show ip bgp neighbor will certainly give you information on the router’s BGP neighbors, it may well be too much information. Here’s the output of show ip bgp neighbor on a BGP

speaker that has only one neighbor! R3#show ip bgp neighbor BGP neighbor is 172.12.23.2, remote AS 23, internal link BGP version 4, remote router ID 172.12.23.2 BGP state = Established, up for 00:01:24 Last read 00:00:23, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received(new) Address family IPv4 Unicast: advertised and received Received 5 messages, 0 notifications, 0 in queue Sent 5 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Default minimum time between advertisement runs is 5 seconds For address family: IPv4 Unicast

BGP table version 1, neighbor version 1 Index 1, Offset 0, Mask 0x2 0 accepted prefixes consume 0 bytes Prefix advertised 0, suppressed 0, withdrawn 0 Number of NLRIs in the update sent: max 0, min 0 Connections established 1; dropped 0 Last reset never Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 172.12.23.3, Local port: 11000 Foreign host: 172.12.23.2, Foreign port: 179 Enqueued packets for retransmit: 0, input: 0 misordered: 0 (0 bytes)

SRTT: 165 ms, RTTO: 1172 ms, RTV: 1007 ms, KRTT: 0 ms minRTT: 8 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: higher precedence, nagle Datagrams (max data segment is 1460 bytes): Rcvd: 8 (out of order: 0), with data: 5, total data bytes: 121 Sent: 8 (retransmit: 0), with data: 5, total data bytes: 121

That’s a lot of information! To get a brief summary of BGP neighbor status, use… you guessed it … show ip bgp summary!

R3#show ip bgp summary BGP router identifier 5.5.5.5, local AS number 23 BGP table version is 1, main routing table version 1

There’s no “right” or “wrong” way to view BGP neighbors.. it all depends on how much or how little information you need! A Little Of This ‘n’ That BGP Message Types, The Peering Process, And The BGP RID Once

the

TCP

connection

is

complete, the Open packet is the first one to go out. If the values in that packet sent by “Router A” are acceptable to “Router B”, then a keepalive is returned by “B” and the BGP connection can then be built. The Open message contains the BGP RID that we’ve seen in a couple of show commands, and the rules for the BGP RID are (thankfully) the same as they are for the OSPF RID. You can hardcode the BGP RID as well, with the bgp router-id

command. R1(config)#router bgp 1235 R1(config-router)#bgp ?

alwayscompare-med

bestpath

client-toclient

Allow compar MED fr differen neighbo Change default bestpat selectio

Configu client to client r reflecti

cluster-id

confederation

dampening default

deterministicmed

Configu RouteReflect Cluster AS confede parame Enable flap dampen Configu BGP de Pick the MED p among adverti the

fast-externalfallover

log-neighborchanges

redistributeinternal

neighbo AS Immedi reset se if a link direct connec externa goes do Log nei up/dow reset re Allow redistri of iBGP IGPs (danger

router-id

scan-time

Overri configu router identifi Configu backgro scanner interva

R1(config-router)#bgp router-id ? A.B.C.D Manually configured router identifier R1(config-router)#bgp router-id 11.11.11.11 R1(config-router)#^Z R1#show ipbgp 19:50:28: %BGP-5-ADJCHANGE: neighbor 15.1.1.5 Down Router ID changed 19:50:28: %BGP-5-ADJCHANGE: neighbor

172.12.123.2 Down Router ID changed 19:50:28: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Down Router ID changed 19:50:28: %SYS-5-CONFIG_I: Configured from console by console

Oh, yeah -- your adjacencies will come down when you do that. show ip bgp verifies the change (table removed from output) R1#show ip bgp BGP table version is 6, local router ID is 11.11.11.1

Back to the packet types… The BGP Update packet is unique in that unlike RIP and EIGRP updates

that contain multiple routes, a BGP Update packet will contain info on one route and one route only. Having seen BGP in action, you know there can be much more information to carry about a BGP route than a RIP or EIGRP route. A couple of times during the course, we saw a BGP Notification message - that’s going to be sent any time a connection goes down. BGP keepalives are sent every 60 seconds by default; the BGP default hold time is 180 seconds.

Watch your iBGP vs. eBGP neighbors. If you’re looking at a potential eBGP neighbor and that neighbor isn’t directly connected, you need a static route pointing to that neighbor and the ebgpmultihop command. In some cases with synchronization on, you can use a static route to null0 - the “bit bucket” - to allow a BGP route to be used. It’s doubtful that’ll appear on the CCNP ROUTE exam, but I mention it to let you know that a static route to null0 does not help with eBGP neighbor relationships.

With iBGP neighbors, since they’re in the same autonomous system, it’s likely that the route to the neighbor exists via an IGP. If not, you can use a static route there as well. The key is that an IGP will not be running between ASes, so with eBGP neighbors we have only the static route - not dynamically learned routes. We saw the result of clear ip bgp * -- that’s a hard BGP reset and it brings the adjacencies down. We go to a lot of trouble to build those suckers, so let’s not do that unless

absolutely necessary. R1#clear ip bgp * ?

in ipv4 out soft vpnv4

Soft reconfig inbound update Address family Soft reconfig outbound update Soft reconfig Address family

Running the soft option shown

above is the same as running out -both result in a soft outbound reset. Now if you’re like me - and I mean no insult by that - you’d wonder why the “soft” option by itself doesn’t perform both an inbound and outbound update. Simply put, the outbound update is easy on the router memory, and the inbound update is a memory hog. The soft inbound reset is fine for updating the BGP tables without tearing the adjacencies down, but it’s still a bit of a memory hog.

We have a relatively new method of performing this reset that’s even easier on everyone involved - and you may have seen it mentioned in the rather verbose output of show ip bgp neighbor: R1#show ip bgp neighbors BGP neighbor is 15.1.1.5, remote AS 1235, internal link Member of peer-group POLICYOUT for session parameters BGP version 4, remote router ID 19.1.1.1 BGP state = Established, up for 00:01:26 Last read 00:00:25, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received(new)

If you need to run a route refresh to make a BGP command take effect, you can run it with the clear ip bgp in command. The actual words “route refresh” aren’t mentioned in the command. R1#clear ip bgp * ?

in ipv4 out soft

Soft reconfig inbound update Address family Soft reconfig outbound update Soft reconfig

vpnv4

Address family

R1#clear ip bgp * in ?

We’ve run a lot of show commands in this section, but not much debugging. Let me show you a few basic debugs… R1#debug ip bgp ?

A.B.C.D

BGP neighbor address BGP

dampening events in keepalives out updates

vpnv4

dampening

BGP events BGP Inbound informatio BGP keepalives BGP Outbound informatio BGP updates VPNv4 NLRI

informatio R1#debug ip bgp keepalives BGP keepalives debugging is on R1# 20:30:48: BGP: 172.12.123.3 sending KEEPALIVE (io) 20:30:48: BGP: 172.12.123.3 KEEPALIVE rcvd 20:30:49: BGP: 172.12.123.2 sending KEEPALIVE (io) R1#debug ip bgp events BGP events debugging is on

R1#clear ip bgp * soft R1# 20:32:12: BGP(0): 1 updates (average = 56, maximum = 56) 20:32:12: BGP(0): 15.1.1.5 updates replicated

for neighbors: 172.12.123.2 172.12.123.3 20:32:12: BGP: Import timer expired. Walking from 1 to 1 R1# R1#clear ip bgp * in R1# 20:32:27: BGP: Import timer expired. Walking from 1 to 1 R1# R1# R1#clear ip bgp * R1# 20:32:34: BGP: reset all neighbors due to User reset 20:32:34: BGP: 15.1.1.5 reset due to User reset 20:32:34: %BGP-5-ADJCHANGE: neighbor 15.1.1.5 Down User reset 20:32:34: BGP: 172.12.123.2 reset due to User reset 20:32:34: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Down User reset 20:32:34: BGP: 172.12.123.3 reset due to User reset

R1# 20:32:34: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Down User reset R1# 20:32:42: BGP: Import timer expired. Walking from 1 to 1 R1#u all All possible debugging has been turned off

Recommended Video Viewing: Troubleshooting advertisements:

BGP

route

http://www.youtube.com/watch? v=6d1P3GWLo_w Configuring and

troubleshooting

BGP route summarization: http://www.youtube.com/watch? v=qKrJ14Hbdts More BGP route aggregation: http://www.youtube.com/watch? v=80fGaebifHo Video Practice Exam on BGP attributes: http://www.youtube.com/watch? v=gMApy_pVctU

Video Practice Exam on BGP fundamentals: http://www.youtube.com/watch? v=hkG2ZOvos8c Free CCNP ROUTE Video Boot Camp on route redistribution: http://bit.ly/Arnhjq My CCNP ROUTE Video Boot Camp - Exclusive Discount Link For My Ebook Readers Only!

Just click this link for a free hourlong preview AND $10 off the already low price! http://bit.ly/A7pLBu Available for immediate download and on DVD!

Copyright © 2012 The Bryant Advantage. All Rights Reserved.

The Remote Workplace, Part I: VPNs And IPSec

These days, it’s not enough to have communication - we need secure communication. Virtual Private Networks (VPNs) are a great way to secure these transmissions. It’s the “private” part of VPNs that brings us that security. Configuring VPNs gives us the opportunity to apply security to a connection that is using a shared technology such as Frame Relay - in other words, to

treat this connection as though it were on a private network. What’s A VPN? VPNs are often referred to as tunnels. We can apply security rules and policies to this tunnel without applying them to other WAN communications. For example, when we configure commands directly on the Serial0 interface, all communications using that interface are subject to those commands.

When we create a VPN, it’s actually seen as a separate interface - you’ll see this when we configure one - and we can apply rules to the VPN that are not applied to other communications using Serial0. In the following exhibit, a VPN has been created between two routers. Security policies can be enforced on the VPN between those two routers without affecting any WAN communications involving the bottom router.

There are some VPN terms that are sometimes used interchangeably, but they don’t refer to the same feature. Let’s take a close look at these terms. VPNs offer three vital functions. Note that two of these occur at the

receiver, and one at the sender. Data origin authentication allows the receiver to guarantee the source of the packet.

Encryption is just that - the sender encrypts the packets before sending them. If an intruder picks them off the wire, they will have no meaning.

Integrity is the receiver’s ability to ensure that the data was not affected or altered in any fashion as it traveled across the VPN.

There are three different protocols we can use to create this tunnel. Originally defined in RFC 1701, Generic Routing Encapsulation enables a Cisco router to encapsulate a packet in an IP header. When the packet reaches the remote router, the header is stripped off. GRE’s drawback is that there’s no encryption scheme, and that’s a pretty big drawback. Defined in RFC 2661, The Layer 2 Tunneling Protocol (L2TP) is

actually a hybrid of Microsoft’s Point-to-Point Tunneling Protocol (PPTP) and Cisco’s own Layer 2 Forwarding (L2F). Again, the major drawback is that L2TP doesn’t have an encryption scheme. This giant flaw is corrected by IP Security, generally referred to as IPSec. IPSec does offer encryption along with authentication, and that’s why you’ll see more IPSec in today’s networks than L2TP or GRE. That’s also why we’re going to spend the majority of this section working with IPSec.

VPN Terminology Before we get to a more specific discussion of VPNs, there are some general terms you should know. We’ll review the terms from the beginning of this section as well. Data Confidentiality means that only the devices that should see the data in an unencrypted form will see the data that way. Generally, this is achieved by one endpoint encrypting the data and sending it across the link in that fashion, with the second endpoint unencrypting the data.

Data Integrity means that the recipient of the data can guarantee that the received data is the same as the transmitted data - in short, that the data was not altered during transport. Data Origin Authentication guarantees that the data originated from a specific endpoint. Anti-replay protection (sometimes just called “replay protection”) protects against replay attacks, a malicious repeat and/or delay of a valid transmission.

Replay attacks can begin innocently enough. In this example, Router C requests proof of identity from Router A. Router A responds with proof of identity.

The problem is, an Intruder is listening to the conversation and copies Router A’s proof of identity.

After A and C are done with their conversation, the Intruder starts a conversation with C, pretending to be A. When C asks for proof of identity, the Intruder submits A’s ID, and C will accept it.

Anti-replay protection can use several different methods of defeating such an attack, including the one-time use of tokens for the proof of identity or by using sequence numbers; a repeated sequence number will be rejected. Data Encryption Technologies For data to be encrypted, it follows

that something’s got to perform this encryption! One such encryption tool is the Data Encryption Standard (DES). DES was developed in 1976, and just a few security issues with networking have popped up since then! The main issue is that the key used by DES to encrypt data is only 56 bits in size. (A key is a random string of binary digits.) Thirty years ago, that was fine, but then again floppy disks used to be the largest storage unit any of us needed! Depending on which documentation you read, DES keys can be broken

in any time frame from 24 hours to ten minutes. Triple DES (3DES) is just what it sounds like - the DES encryption procedure is run three times, with three different 56-bit DES keys. That’s a total of 168 bits, but the effective security provided is considered to be only 112 bits. The Advanced Encryption Standard (AES) is being rapidly adopted by governments and organizations around the world. AES can run on any Cisco router that has IPSec DES/3DES

capability. The actual function of AES is far beyond the scope of this exam, but it really is quite fascinating. To me, anyway. If you’d like to take a peek at how it works ….

http://en.wikipedia.org/wiki/Advance Key Encryption Schemes Symmetric encryption is an algorithm where the key that is used for encryption is also used for decryption. Symmetric encryption is sometimes called secret key

encryption. Variations of symmetric encryption include stream algorithms, where one bit or byte is encrypted/decrypted at a time, and block algorithms, where blocks of data are encrypted/decrypted as a whole. These data blocks are usually 64 bits in size. Both DES and 3DES use symmetric encryption. The drawback to symmetric encryption is that the key is used for two purposes, making it that much easier for an intruder to discover

the key. In contrast, asymmetric encryption involves two keys for both the sender and receiver. This public key encryption scheme involves a public and private key for each user. Before starting the actual encryption process, the public key should be certified by a third party called a Certificate Authority (CA). If “Dan” has a public key, the CA will make sure Dan is who he says he is, and the CA will then issue a digital certificate saying just that. The digital certificate is a

combination of Dan’s public key and the CA’s private root key. The CA may be global, such as www.verisign.com, or it may be a CA in your very own organization. The key here (no pun intended) is that you better trust your CA, because the entire public key encryption process is built around the CA verifying users and their public keys.

Now that the CA has verified Dan and Bob, public key encryption can be put into use. In this example, Dan will send an email to Bob using PKE. Dan will actually use Bob’s public key to encrypt the message. The email is then sent to Bob, who will use his private key to deencrypt the email.

Exchanging Secret Keys Over A Non-Secure Connection It seems like quite a Catch-22; to create the VPN, we need the endpoints to exchange secret keys, but since the VPN doesn’t exist yet, the secret keys must be exchanged over a non-secure connection! The Diffie-Hellman algorithm allows the exchange of secret keys over a non-secure communications channel. Referred to in some documentation as exponential key agreement, this protocol was also designed in 1976

- but it’s still in use today in networks around the world. The IPSec Architecture IPSec is a combination of three protocols: Authentication Header (AH), which defines a method for authentication and securing data Encapsulating Security Payload (ESP), which defines a method for authenticating, securing, and encrypting data

Internet Key Exchange (IKE), which negotiates the security parameters and authentication keys

Defined in RFC 2402, Authentication Header (AH) offers solid security -- it provides data origin authentication as well as offering optional anti-replay

protection. The drawback with AH is that the authentication it provides for the IP Header is not complete. That’s because some of the IP fields can’t be correctly predicted by the receiver - these are mutable fields which may change during transmission. AH will successfully protect the IP packet’s payload, though, which is really what we’re interested in. To sum it up, AH does offer: data origin authentication

data integrity anti-replay (optional) AH does not confidentiality.

protection offer

data

The Encapsulating Security Payload (ESP) does just that - as you can see from the IPSec packet illustration, there is an ESP Header and ESP Trailer surrounding, or encapsulating, the data. ESP offers all of the following: data origin authentication

anti-replay protection data confidentiality Comparing AH and ESP, you might be wondering why you’d ever choose AH over ESP. Here are a few things to consider: ESP is more processorintensive than AH. If your data does not require data confidentiality, AH may meet all your requirements. ESP requires strong cryptography, which isn’t

available and/or allowed everywhere. AH has no such requirement. Both ESP and AH can be run in one of two modes - Tunnel Mode and Transport Mode. In Tunnel mode, the entire IPSec process is transparent to the end hosts; specialized IPSec gateway devices handle the IPSec workload. The tunnel mode process encrypts the entire IP packet, and then that encrypted packet is placed into another IP packet. That

encapsulating packet will have the IP addresses configured on the tunnel endpoints, and it’s those tunnel IP addresses that will be used to route the packet. Transport mode encrypts the IP payload, but the IPSec header is inserted directly after the IP header in the packet. As a result: There is no protection for the original IP address The original IP address will be used for routing Only data from the Transport

layer up is protected by IPSec (easy enough to remember!) Configuring Site-to-Site IPSec VPNs Configuring a site-to-site VPN is basically a five-step process. Process Initialization via “interesting traffic” (as opposed to the usual, uninteresting kind) IKE Phase 1 (IKE SA negotiation) IKE Phase 2 (IPSec SA

negotiation) Data Transfer Tunnel Termination IPSec doesn’t just start working by itself - it requires interesting traffic to be sent by a host. This interesting traffic initializes the IPSec process. A crypto access-list will define interesting traffic for our VPN. We’ll configure one later in this section.

The routers will now enter IKE Phase I. Assuming we’re running Main mode, there will be six messages overall. The initiator will first transmit proposals for the encryption and authentication schemes to be used. At this point, IKE’s looking for an ISAKMP policy that’s a match at both endpoints.

In the second exchange of IKE Phase I, the devices will exchange Diffie-Hellman public keys; from this point on, the rest of the negotiation is encrypted.

The initiator and recipient authenticate each other in the third exchange of Phase I, using an encrypted form of their IP addresses. The IKE SA is then established and Phase II can begin.

(If we had chosen to run IKE in Aggressive Mode, this would have been a three-message process. ) The initiator packages everything needed for the SA negotiation in the first message, including its DiffieHellman public key.

The recipient responds with the acceptable parameters and authentication information, and its Diffie-Hellman public key. The initiator then sends a confirmation that it received that information, and we’re done!

IKE Phase 2 has one mode, Quick mode. This is also a three-message process. The initiator proposes parameters for the IPSec SA, the recipient responds with a list of acceptable parameters, and the

initiator then transmits a message that lets the responder know that message 2 was received and processed. This message is called proof of liveness.

With the IPSec SA in place, the hosts can now exchange data.

Once the data exchange is complete, the tunnel can be torn down. This tunnel termination can be configured to occur after a certain number of bytes have passed through the tunnel, or perhaps after the tunnel has been up for a certain

number of seconds. But what if traffic is flowing through the tunnel at the same time the tunnel’s supposed to be torn down? No fear - a new Security Association can be agreed upon while the existing one is still in place. Creating An IKE Policy Before configuring the IKE policy, make sure ISAKMP is enabled with the crypto isakmp enable command. It’s supposed to be on by

default, but we all know how that is! R1(config)#crypto isakmp enable

To display the current IKE policies, run show crypto isakmp policy. R1#show crypto isakmp policy

Global IKE policy Default protection suite encryption algorithm: DES -

Data Encryption Standard (56 bit keys).

hash algorithm: authentication method: DiffieHellman group: lifetime:

Secure Hash Standard Rivest-ShamirAdleman Signature #1 (768 bit) 86400 seconds, no volume limit

We’re not going to use the default, however. We’ll create a custom policy with the crypto isakmp policy command. Policies can be assigned priorities, as shown below by IOS Help. The lower the number, the higher the priority, with

1 being the highest priority. There is no default and this value cannot be set to zero. R1(config)#crypto isakmp policy ? Priority of protection suite R1(config)#crypto isakmp policy 100

IOS Help shows the options for the IKE policy.

The options for authentication are preshared keys, RSA Signature, and

RSA Encryption. The default is RSA Signature. We’ll configure the policy to use preshared keys. R1(config-isakmp)#authentication ?

preshare rsaencr

rsasig

Pre-Shared Key RivestShamirAdleman Encryption RivestShamirAdleman Signature

R1(config-isakmp)#authentication pre-share

The options for encryption are DES, AES, and 3DES (TDES). The default is DES. We’ll use 3DES. R1(config-isakmp)#encryption ?

3des

aes

des

Three key triple DES AES Advanced Encryption Standard. ES - Data Encryption Standard (56 bit keys).

R1(config-isakmp)#encryption 3des

We do have options for the DiffieHellman group, so we’ll use group 5. The default is group 1. R1(config-isakmp)#group ?

1 2 5

Diffie-Hellman group 1 Diffie-Hellman group 2 Diffie-Hellman group 5

R1(config-isakmp)#group

The hash algorithm will be either MD5 or SHA. The default is SHA, so we’ll set the policy to MD5.

R1(config-isakmp)#hash ? md5 Message Digest 5 sha Secure Hash Standard R1(config-isakmp)#hash md5

Finally, we need to set the SA lifetime. The default is the maximum number of seconds, 86,400, which equals 24 hours. We’ll set that to 42,400 seconds. R1(config-isakmp)#lifetime ? lifetime in seconds R1(config-isakmp)#lifetime 42400

show crypto isakmp policy displays both policies on the router

- the default and the one we just wrote.

The exact same policy has been configured on R3. R1 and R3 are on the same Serial segment, 172.12.12.0 /24, with their router number as the last octet. R3(config)#crypto isakmp policy 100 R3(config-isakmp)#hash md5 R3(config-isakmp)#lifetime 42400 R3(config-isakmp)#group 5

R3(config-isakmp)#authentication pre-share R3(config-isakmp)#encryption 3des

When IKE Phase 1 negotiation begins, the initiator sends its policies to the receiver. The receiver will then attempt to find a match for that policy among its own policies, and the receiver starts this search with its lowest numbered policy. If that policy doesn’t match, the receiver checks its next lowest numbered policy. It’s vital to remember that just because the first policy comparison doesn’t result in a match, the recipient will continue

to search for a match. In the following example, R2 checks its own policies for a match with the policy sent by the initiator, R1. R2 begins with its lowestnumbered policy, 100. That policy requires SHA and the incoming policy names MD5, so there’s no match. R2 then checks its Policy 200, which requires DES, and that does not match the incoming policy. Policy 300 matches all the requirements, so the negotiation is successful.

You’d think that all five values would have to match for the negotiation to be successful, but that’s not quite true. Here’s a list of the parameters and what has to happen for successful negotiation. Hash: exact match

Encryption: exact match Authentication: exact match DH Group number: exact match Lifetime: Remote peer policy must have lifetime equal to or less than initiator. If less, the lower value is used. Since our policies referred to preshared keys, we better create them! The crypto isakmp key command does this. Along with the key itself, the IP address of the remote peer must be configured. Watch

the

syntax

with

this

command, as it differs between IOS versions. Not all versions have the 0 / 6 option you’ll see below on R1. IOS Help shows that the options are slightly different between the IOS versions we’re using. As a CCNP and world-class Cisco engineer, this is something you need to get used to. Trust me.

If Phase I is successful, an ISAKMP SA will be created. We can verify this with show crypto isakmp sa.

R3#

As always, if the output of a show command shows nothing, there’s nothing to show! The ISAKMP SA doesn’t exist until the entire IPSec

configuration is in place and interesting traffic has started the process. That’s one frustrating thing about IPSec - there’s a good deal of configuration, but you really can’t test it until the entire thing is done. Configuring Transform Sets

The

IPSec

An IPSec Transform Set is simply a group of individual parameters that will enforce a security policy. The endpoints must agree exactly on which encryption and algorithms will be used to create the IPSec SA. If there’s an exact match, the IPSec

process continues; if there’s no match, the process is terminated and the session torn down. As with ISAKMP policies, multiple transform sets can be configured and sent to a remote peer. The remote peer will compare each set received against its own transform sets, and when a match is found, the IPSec SA will be built. A transform set is built with the crypto ipsec transform-set command, as shown here on R3. Options are shown with IOS Help, and then the exact same transform

set is configured on R1.

IPSec SA Lifetimes The default lifetime of an IPSec SA is 1 hour, but IOS Help reveals that the command that changes this value on a global basis sets the IPSec SA

lifetime in seconds. Always use IOS Help to double-check the measuring unit in use by any given command. The below command sets this value to 30 minutes (1800 seconds). The SA lifetime can also be based on volume.

Crypto Access Lists Remember way back when I mentioned that interesting traffic triggers the IPSec process? We’re finally getting to the part of IPSec that identifies this interesting traffic

- crypto access lists. Crypto ACLs are used to define the traffic that is protected by IPSec. While most of the Crypto ACLs you write will be configured to affect outbound traffic, they can also be configured to affect inbound traffic. Outbound crypto ACLs identify the traffic to be secured by IPSec, and traffic not named by the crypto ACL will be sent in clear text.

Inbound crypto ACLs identify traffic that should have been protected by IPSec, but wasn’t. Such traffic will be discarded.

Extended ACLs can serve as Crypto ACLs, but there’s a major difference in operation between the two. With traffic traffic deny). traffic traffic

Extended ACLs, matched is permitted and unmatched denied (by the implicit With Crypto ACLs, matched is encrypted and unmatched is unencrypted but still

transmitted. If inbound Crypto ACLs are configured, unprotected traffic that matches the ACL is dropped simply because it’s unprotected. The trickiest part of writing Crypto ACLs for IPSec peers is making sure they’re symmetrical rather than identical. Let’s use the following network to show you what I mean.

To have traffic on R1’s ethernet segment protected by IPSec if it’s destined for the ethernet segment on R2, R1’s ACL will look like this: access-list 123 permit ip 172.10.1.0 0.0.0.255 172.10.5.0 0.0.0.255

For traffic on R2’s ethernet segment to be protected by IPSec if it’s destined for the ethernet segment on R1, R2’s ACL will look like this:

access-list 123 permit ip 172.10.5.0 0.0.0.255 172.10.1.0 0.0.0.255

When you’re configuring IPSec and concentrating on the many details we’ve discussed in this chapter, it’s really easy to think “Hey, I’ll just write the ACL on one router and then copy and paste it to the other.” Always double-check your ACLs if they’re identical, there is a problem. We don’t want the two ACLs to be an exact copy of each other - rather, we need them to be mirror images, exact reverses of each other.

Once the Crypto ACLs are written, it’s time to apply them to the appropriate interfaces. That’s just one purpose of a Crypto Map. Let’s look at the basic command to write a Crypto Map along with some options, courtesy of IOS Help. R3(config)#crypto map CCNP ?



client

Sequence to insert into crypto map entry Specify client configuration settings

isakmp

isakmpprofile

localaddress

Specify isakmp configuration settings Specify isakmp profile to use Interface to use for local address for this crypto map

R3(config)#crypto map CCNP 100 ?

ipsecisakmp

IPSEC w/ISAKMP

ipsecmanual

IPSEC w/manual keying

R3(config)#crypto map CCNP 100 ipsec-isakmp ?

dynamic

profile



Enable dynamic crypto map support Enable crypto map as a cryptoprofile

R3(config)#crypto map CCNP 100 ipsec-isakmp R3(config-crypto-map)#

We’ve successfully created a crypto map named CCNP, sequence number 100, that will use ISAKMP to establish the IPSec Security Associations. We’re now in crypto map configuration mode, where the ACL, peers, transform sets, and security association lifetime for this particular crypto map can be set. Any SA lifetime value configured here overrides the globally configured value, but we’ll leave that value alone for now.

R1(config)#crypto map CCNP 100 ipsec-isakmp

This new crypto map will remain disabled until a % peer and a valid access NOTE: list have been configured. R1(config-crypto-map)#match address 123 R1(config-crypto-map)#set peer 172.12.123.2 R1(config-crypto-map)#set transform-set R1_TRANSFORM_SET

R1(config-crypto-map)#interface serial 0/1 R1(config-if)#crypto map CCNP R1(config-if)# *Apr 1 17:27:04.807: %CRYPTO-6ISAKMP_ON_OFF: ISAKMP is ON

R3(config)#crypto map CCNP 100 ipsec-isakmp R3(config-crypto-map)#match address 123 R3(config-crypto-map)#set peer 172.12.12.1 R3(config-crypto-map)#set transform-set R3_TRANSFORM_SET R3(config-crypto-map)#set security-association lifetime ? kilobytes Volume-based key duration seconds Time-based key duration R3(config)#int s0/1 R3(config-if)#crypto map CCNP R3(config-if)# *Mar 1 04:10:12.260: %CRYPTO-6ISAKMP_ON_OFF: ISAKMP is ON

Before sending interesting traffic to start the entire process, we’ll enable debug crypto ipsec on R3 to allow us to see the details of the SA negotiations. Near the bottom of the

debug output, you can see that two separate unidirectional SAs have been built. R3#debug crypto ipsec Crypto IPSEC debugging is on R3#ping 172.12.12.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.12.1, timeout is 2 seconds: *Jun 6 23:51:14.999: IPSEC(sa_request):, (key eng. msg.) OUTBOUND local= 172.12.12.3, remote= 172.12.12.1, protocol= AH, transform= ah-md5-hmac (Tunnel), lifedur= 1800s and 4608000kb, spi= 0x91791CF(152539599), conn_id= 0, keysize= 0, flags= 0x400A. *Jun 6 23:51:17.579:

IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) INBOUND local= 172.12.12.3, remote= 172.12.12.1, protocol= AH, transform= ah-md5-hmac (Tunnel), lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x2 *Jun 6 23:51:17.583: Crypto mapdb : proxy_match src addr : 172.12.12.3 dst addr : 172.12.12.1 protocol : 0 src port : 0 dst port : 0 *Jun 6 23:51:17.591: IPSEC(key_engine): got a queue event with 2 kei messages *Jun 6 23:51:17.591: IPSEC(initialize_sas):, (key eng. msg.) INBOUND local= 172.12.12.3, remote= 172.12.12.1, protocol= AH, transform= ah-md5-hmac (Tunnel),

lifedur= 1800s and 4608000kb, spi= 0x91791CF(152539599).!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 48/49/52 ms R2#, conn_id= 0, keysize= 0, flags= 0x2 *Jun 6 23:51:17.591: IPSEC(initialize_sas):, (key eng. msg.) OUTBOUND local= 172.12.12.3, remote= 172.12.12.1, protocol= AH, transform= ah-md5-hmac (Tunnel), lifedur= 1800s and 4608000kb, spi= 0x945FCBB6(2489306038), conn_id= 0, keysize= 0, flags= 0xA *Jun 6 23:51:17.595: Crypto mapdb : proxy_match src addr : 172.12.12.3 dst addr : 172.12.12.1 protocol : 0 src port : 0 dst port : 0 *Jun 6 23:51:17.595: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and

172.12.12.1 *Jun 6 23:51:17.595: IPSec: Flow_switching Allocated flow for sibling 80000002 *Jun 6 23:51:17.595: IPSEC(policy_db_add_ident): src 172.12.12.3, dest 172.12. 12.1, dest_port 0 *Jun 6 23:51:17.599: IPSEC(create_sa): sa created, (sa) sa_dest= 172.12.12.3, sa_proto= 51, sa_sp i= 0x91791CF(152539599), sa_trans= ah-md5-hmac, sa_conn_id= 2001 *Jun 6 23:51:17.599: IPSEC(create_sa): sa created, (sa) sa_dest= 172.12.12.1, sa_proto= 51, sa_spi= 0x945FCBB6(2489306038), sa_trans= ah-md5-hmac, sa_conn_id= 2002

By running show crypto isakmp sa, we can see that the SA is in place and is active… and at last, active is what we want to see!

QM_IDLE is what we do want to see; here are a few other potential messages we don’t want to see, along with a quick explanation of each courtesy of Cisco’s website. A common error message is MM_NO_STATE, and if you think that sounds bad, you’re right! This indicates a fundamental problem

with Phase I, most likely a mismatch of attributes between peers. MM_KEY_EXCH can indicate a misconfiguration of the peer’s IP address, and this message can also be generated by a misconfigured pre-shared key. Two other excellent IPSec troubleshooting commands are show crypto map and show crypto ipsec transform-set.

Transform set R2_TRANSFORM_SET: { ahmd5-hmac } will negotiate = { Tunnel, },

To let you see what the IPSec process looks like when the SA expires, I left the debug running until the one we built in this chapter expired. *Jun 7 00:48:18.270: IPSEC(lifetime_expiry): SA lifetime threshold reached, exp iring in 111 seconds

*Jun 7 00:50:10.074: IPSEC(key_engine): got a queue event with 1 kei messages *Jun 7 00:50:10.074: IPSEC(key_engine_delete_sas): rec’d delete notify from ISA KMP *Jun 7 00:50:10.078: IPSEC(key_engine_delete_sas): delete SA with spi 0x877193D *Jun 7 00:50:10.086: IPSEC(delete_sa): deleting SA, sa_spi= 0xF8BA8F2(260810994), sa_trans= ah-md5-hmac, sa_conn_id= 2003, *Jun 7 00:50:10.086: IPSEC(delete_sa): deleting SA sa_spi= 0x877193DD(2272367581), sa_trans= ah-md5-hmac, sa_conn_id= 2004, (identity) local= 172.12.123.2, remote=

172.12.123.1, *Jun 7 00:50:10.090: IPSec: Flow_switching Deallocated flow for sibling 8000000

A Warning About ACLs And IPSec As you work with more complex combinations of Cisco technologies, you’re going to have to be very careful with your access lists. You should especially be careful with port ranges in ACLs, because you can always block ports that are needed by network services or applications. This is particularly true with IPSec,

because three primary IPSec protocols use ports that must not be blocked by ACLs: ESP, protocol number 50 AH, protocol number 51 IKE, UDP port 500 Make sure your network’s ACLs are not inadvertently blocking these ports and protocol numbers anywhere you have IPSec running. To review, here’s the process we used to create this site-to-site IPSec VPN:

Created the ISAKMP policy Created the IPSec transform set Defined interesting traffic with the crypto access-list Created the crypto map - AND applied it to the proper interface Made sure our ACLs allowed the appropriate port numbers The Return Of GRE The Generic Routing Encapsulation (GRE) tunneling has

actually made a comeback, since GRE can do things that IPSec can’t do, and vice versa. We used to love GRE’s multiprotocol capabilities, but that’s not as important to us in today’s networks as it once was. Combined with a lack of strong security features, GRE was pretty much dead for quite a while. IPSec is very secure, but it does have drawbacks. Originally, IPSec couldn’t carry multicast traffic, and you may still run into some trouble with that in the field - the first IOS

release that allowed IPSec to carry multicast traffic was 12.2(4)T, and there are plenty of routers out there running an earlier IOS. The latest IOS versions can’t handle all multicast traffic, however. Multicast traffic generated by OSPF and EIGRP can’t be carried by basic IPSec we’ve got to run a combination of IPSec and GRE, commonly called GRE over IPSec. By combining GRE and IPSec, each protocol helps to compensate for the other’s limitation:

IPSec adds data integrity and confidentiality that GRE does not offer GRE offers the ability to carry routing protocol traffic, which IPSec does not offer Why call it “GRE over IPSec” rather than “IPSec over GRE”? Because the GRE encapsulation happens first, and then that encapsulation is encapsulated again, by IPSec. In effect, we have a GRE tunnel inside an IPSec tunnel.

Our old friends tunnel mode and transport mode are still around as well. Interestingly enough, Cisco’s website recommends the use of transport mode over tunnel mode with GRE over IPSec. Using transport mode results in less total overhead, and we’re all in favor of that! To review Just as with a site-to-site VPN, the crypto ACL indicates the traffic to be encrypted

GRE over IPSec allows the transmission of dynamic routing protocol multicast traffic Whether you use the CLI or SDM, always make sure to apply the crypto map to the interface! Hey, that’s enough talking about GRE over IPSec. Let’s configure it with SDM - the Security Device Manager. NOTE: SDM has actually been phased out by Cisco, but since many CCNP candidates haven’t seen a

Cisco GUI, I want you to see one here. Configuring A GRE Tunnel Over IPSec Via SDM (PDQ) As always, we’ll start by clicking the Configure button, and from there choose VPN.

From the main VPN window, we’ll select Site-to-Site VPN. The Siteto-Site VPN window gives us two main choices:

When I choose the GRE over IPSec option, this illustration is shown.

After clicking Launch the selected task, we’re given some reminders of why we’re using GRE - good review material for your exam, too!

The next screen asks us for some required GRE-over-IPSec information, namely the tunnel source and destination and the

address of the tunnel itself. Note that for the source, we can specify either the interface or the IP address, where the only option for destination is the IP address.

Did you notice the Details button in the previous screen? Clicking that gives you quite a bit of information regarding that interface. We don’t have any of these features on this interface, but if we did, it’s good

information to have in mind for the tunnel config.

Now back to the config! We’re not going to create a backup tunnel, but the next screen gives us the option to do so.

The next window prompts us for the pre-shared key or to indicate the use of digital certificates.

The next window is the IKE Proposal selection area, and we’ll accept the default IKE policy.

The next window is the Transform Set selection area, and we’ll accept the default there as well.

We’re then prompted to identify the routing protocol that will run over the tunnel.

Earlier in this section, we had the opportunity to create a backup tunnel. If you’re running a routing protocol over the tunnels, you may need to alter some metrics so that one tunnel is preferred over the other. For EIGRP, for example, I’d suggest working with the delay

option rather than the other metrics as it’s easier to get the result you want. With static routing, you could alter the AD of the routes with the distance option. We now have the option of tunneling all traffic, or using Split Tunneling to send select traffic through the tunnel. We’ll enable ST here and configure traffic destined for 10.0.0.0 /8 to use the tunnel.

Real-world note: By default, using Split Tunneling with NAT and PAT on the same router can cause problems. Cisco’s website offers several solutions to this issue, should you run into that problem in the real world. As always, we’re presented with a Summary of the configuration

we’ve chosen.

At this point, the VPN is down, since we haven’t configured the other side of it!

We need an exact reverse of this configuration - a mirror image - to place on the downstream router. SDM has a great tool to create this mirror at the verrrrrry bottom of the screen - the Generate Mirror button! Real-world note: If you can’t find something in SDM, always look at the very bottom of the screen.

After clicking Generate Mirror, we get that mirror configuration, along with warnings about how this config should be used only as a guide and should not be pasted into the remote router.

Since we’re in a lab environment, I’m going to do just what they told me not to do, and save this config and then paste it into the downstream router. Here’s the mirror configuration:

crypto isakmp policy 1 authentication pre-share encr 3des hash sha group 2 lifetime 86400 exit crypto isakmp key secretkey address 172.31.1.1 crypto ipsec transform-set ESP-3DES-SHA esp-sha-hmac esp-3des mode tunnel exit ip access-list extended SDM_1 remark SDM_ACL Category=4 permit gre host 10.2.1.2 host 172.31.1.1 exit crypto map SDM_CMAP_1 1 ipsec-isakmp description Apply the crypto map on the peer router’s interface having IP address 10.2.1.2 that connects to this router. set transform-set ESP-3DES-SHA set peer 172.31.1.1

match address SDM_1 set security-association lifetime seconds 3600 set security-association lifetime kilobytes 4608000 exit

After copying that config to the downstream router, I applied that crypto map to the physical interface and created a tunnel interface manually: interface Tunnel0 ip address 10.1.1.2 255.255.255.0 ip mtu 1420 tunnel source FastEthernet0/1 tunnel destination 10.2.1.1

Going back to the original router, the Edit Site-to-Site VPN screen shows the VPN is now up.

What’s So “Easy” About Easy VPN? Easy VPN following:

consists

of

the

Easy VPN Server Easy VPN Remote Sounds easy enough! Seriously, the real benefit of Easy VPN is that security policies written at the

Server level can then be pushed out to Clients. As a result, the Clients have the most up-to-date policies without the network admins - that’s you and me - having to visit them individually. Quite a few different Cisco devices can act as Easy VPN Servers. I will not list each here, but here are the more common ones:

VPN 3000 concentrators Cisco 7500,7200,7100,3600,2600,170 routers w/ 12.2(8)T IOS

Many Cisco 800 series routers running 12.2(8)T or later The Easy VPN Remote device can be a Cisco router, PIX, or VPN concentrator as well. “Easy VPN Remote” devices are often referred to as “Easy VPN Clients”, and that’s how I’ll refer to them for the rest of this video. For your exam and when reading Cisco documentation, remember that “Remote” and “Client” refer to the same device. The basics of the VPN construction will look familiar at this point!

First, the Client will send ISAKMP proposals to the Server, and the Server responds with the acceptance of a matching proposal. After the policy acceptance, the ISAKMP SA is in place.

The next step is a little different from what we’ve seen in other VPNs. The Server will now send a challenge to the Client, prompting

the Client to send a username and password to the Server.

We can use several methods to set up this authentication: Local (using the username/password command) RADIUS TACACS

Xauth Authentication)

(Extended

We’ll take a closer look at RADIUS and TACACS in another section, but keep in mind that we can use these security protocols in addition to local authentication. Once the Client has successfully authenticated, the process enters Mode configuration. At this stage, the Client requests the necessary configuration details from the Server.

This information can include: IP address information (required) internal DNS and WINS server addresses split tunneling configuration information

Split tunneling allows the Client to have a secure tunnel to the Server and simultaneous non-secure connections to other networks. Once Mode configuration is completed, the Reverse Route Injection stage begins. According to Cisco’s website, “Reverse route injection (RRI) is the ability for static routes to be automatically inserted into the routing process for those networks and hosts protected by a remote tunnel endpoint”. After RRI, we’re almost there!

IPSec Quick Mode then negotiates the IPSec SA, and we’re all set. Configuring Easy VPN Server In SDM We’ll start our Easy VPN server config by clicking the VPN button in the Configure section of SDM.

You’ll see a list of topics under “VPN”, and we’ll select Easy VPN Server.

The description screen shows the following. Note the prerequisite task.

There’s a link to enable AAA on that screen, so I’ll click that. Note that the Enable Easy VPN button is grayed out since AAA is not yet enabled.

After clicking the enable AAA link, we’re presented with this message:

We do want to enable AAA, so we’ll click Yes and move on.

Once the AAA commands are delivered, we can enable Easy VPN Server.

Welcome to the Easy VPN Server Wizard! Good exam review material on this screen as well!

Here’s the next window:

The interface facing the workstation is Fast 0/0, so I’ll choose that in the drop-down box. We’ll use preshared keys as well, but you see that we can use keys, digital certificates, or both. After making those selections, the next window

asks us for the IKE proposal. We could create custom policies by clicking Add, but here we’ll use the default.

The Transform Set selection window is next, and we’ll accept the default there as well.

The next window prompts us for the group authorization method, and we’ll use local authentication only.

I like the summary description here. Actually, if you don’t have a RADIUS or TACACS server in your network, the local database is the only option you have!

In the next window, we’ll indicate local authentication for users.

In the next window, we’ll click Add since a group has not yet been created.

The Add Group Policy window opens to the following tab, and you can see the information I entered for yourself. Note the pre-shared key appears as a series of asterisks.

We’ll enable Split Tunneling, which is disabled by default. When I clicked that check box, the Enter the protected subnets selection window enabled. I’ll click Add and

enter the 10.0.0.0 network with a wildcard mask of 0.255.255.255.

The policy has been added.

At the bottom of this screen, note

that you can specify an idle timer for the tunnel.

Finally, we’re presented with the Summary window.

After clicking Finish at the bottom of that screen, the commands are delivered to the router, and the Easy VPN Server side of the configuration is complete! Configuring The Easy VPN Client

Now to the workstation! I’ll launch the Cisco VPN Client and click New.

I’ll enter the IP address of the Easy VPN Server, along with the group name and password (which again appears only as a series of asterisks). Group Authentication is selected

by default. We’re not going to configure Mutual Group Authentication, but if we chose that option, we’d need to import a valid root certificate.

Now the HQ connection appears under Connection Entry. I’ll click Connect, and we’ll be prompted for a username / password combination that I configured before the lab

began.

The connection is then completed! Note that a lock now appears next to the HQ connection, the message Connected to HQ appears in the bottom left of the window, and the overall connection time appears in the bottom right of the window.

You can also test the connection from the Server side. Go to the Edit Easy VPN Server screen….

.. and at the very bottom of the

screen, select Test Easy VPN Server.

Click Start in the Troubleshooting VPN screen, and you’ll get check marks when all is well. If something isn’t well, you’ll get some great information on the issue here. This is the first place I check when a VPN configuration isn’t working correctly.

You’ll also receive the following confirmation that all is well.

Let’s look at an SDM screen we

haven’t visited yet - the Monitor screen. Just click the Monitor button at the top of SDM, and you’re there.

This screen has buttons on the lefthand side as well. Naturally, we’ll select VPN Status.

The IPSec Tunnels tab verifies that the tunnel is up.

The Easy VPN Server tab verifies it as well, along with the number of encrypted and decrypted packets.

The IKE SA tab shows the SA is in QM_IDLE mode, which is just what we want!

Other Easy VPN Options

In the Easy VPN Client software, you’ll see an option for transparent tunneling. When you have a router serving as a firewall that also happens to be between the Easy VPN Client and Server, you’ll want to enable this option. Why? That gateway is likely running NAT and/or PAT, and that can be a problem for Easy VPN. Enabling transparent tunneling enables us to work around potential issues with NAT and PAT. On the same tab in SDM, you’ll see an option to Allow Local LAN

Access. If this is enabled on both the Server and Client, access to local network files, printers, and other resources is allowed without going through the tunnel. A Note About NAT Easy VPN Client does support NAT and PAT, but with a twist. According to Cisco documentation, Client will autoconfigure the necessary NAT and PAT commands and access-lists; the admin only needs to configure our old friends ip nat inside and ip nat outside.

So what’s the catch? Actually, there are two of them: The autoconfigured NAT, PAT, and access-list commands will not appear in the starting and running configurations. Thankfully, you can see them with the show access-list and show ip nat statistics commands. You must remove any preexisting NAT and PAT configuration before configuring Easy VPN Remote.

Copyright © 2012 The Bryant Advantage. All Rights Reserved.

The Remote Workplace, Part II

Whether they’re working from a “spoke office” or “branch office”, or from non-fixed locations on the road, the ever-increasing number of mobile workers poses a real challenge for today’s network admins. And that’s us! A few of those challenges….

Providing enough bandwidth for the workers to get their jobs done in an efficient manner Security, security, security (addressed in Part 1) Integrating the mobile users’ operating systems and applications with those used at HQ Let’s take a look at that first challenge - and at broadband.

Dialup connections are pretty much a thing of the past for today’s mobile workers, thanks to broadband. We know that broadband brings us a lot more speed than the dialup connections used to, and if you’ve ever paid a hotel bill where the dialup connection has been used even a little - well, suffice to say that broadband helps bring our overall costs down as well. Upstream, Downstream For terms of our discussion and

your Cisco exams, upstream traffic is traffic going from a host device to the cable company and/or ISP, and downstream traffic is traffic going from the ISP to the host device. Broadband Delivery Options The most common broadband delivery method in use today is the good old cable modem. The end user’s connection is carried through a preexisting cable TV connection, enabling many cable companies to offer “do-it-yourself” broadband connectivity kits. (I notice those

aren’t as popular as they used to be.) Ever notice how the lights on the front of a typical cable modem flash quite a bit on startup, but some of them become solid green (we hope) ? That’s because when a cable modem is powered on or reloaded, it begins to look for a signal from the service provider as it boots up. When that signal is found, the cable modem synchronizes its timing with the downstream provider device, and the connection procedure continues from there.

The potential drawback is that the end user is sharing bandwidth with a lot of other users, which can be a problem if the provider doesn’t have enough bandwidth to go around. The end user can simultaneously access the Internet while watching cable television due to the Data Over Cable Service Interface Specification (DOCSIS) standards. Courtesy of wikipedia, here’s what DOCSIS is all about: “Data Over Cable Service Interface Specification is an

international telecommunications standard that permits the addition of high-speed data transfer to an existing Cable TV (CATV) system. It is employed by many cable television operators to provide Internet access over their existing hybrid fiber coaxial (HFC) infrastructure. By using the specific bandwidths outlined by DOCSIS, the same cable can be used to deliver cable television service, transmit data to the client, and receive data from the

client simultaneously. Our friends at the cable company use one of three sets of modulation standards: National Television Standards Committee (NTSC) is used in primarily in North American and Japan. Phase Alternating Line (PAL) is used, well, almost everywhere else. Sequential Color Memory (SECAM) is used primarily in France, Africa, and Eastern

Europe. One step up from the cable modem, we have Digital Subscriber Line, or DSL. DSL uses a preexisting phone line for broadband delivery. There are several different kinds of DSL, though… Asymmetrical DSL (ADSL) works under the assumption that the user will download more information than they send, and for the average Internet user, that’s a safe assumption. The connection speed from the provider to the user is going to be 3 - 4 times faster than

the speed from the user to the provider. For example, an ADSL connection of 512 kbps will give the user 384 KBPS download capabilities, but only 128 kbps uploading capability. ADSL actually offers download speeds of up to 8 mbps and upload speeds of up to 1 mbps or 1.5 mbps depending on whose sales propaganda you’re reading. Regardless of the sales department, though, ADSL is susceptible to that 18,000-feet distance limitation.

The Original High Data-Rate DSL (HDSL) has the capability to deliver T1 (1.544 MBPS) or E1 (2.048 MBPS) speed over copper, and this service is symmetrical - the download and upload capabilities are the same. Unlike ADSL, you cannot use the phone while you’re using the HDSL connection. Second-generation HDSL (HDSL2) does allow for Voice Over IP (VOIP) and video to be carried along with data. Rate-Adaptive DSL (RADSL) is just what it sounds like - the

software calculates the maximum download and upload speeds on the customer’s preexisting phone line and dynamically adjusts those rates. G.SHDSL provides symmetric tranmission for upstream and downstream data rates of anywhere from 192 kbps to 2.3 MBPS. Estimates of G.SHDSL’s maximum distance range from 20,000 feet to 28,000 feet, depending on whose documentation you’re reading. Anyone who lives or has lived in a rural area knows the challenge of trying to get a broadband

connection. Satellite Broadband certainly sounds like a technology that could meet that challenge, and theoretically it does just that. Satellite broadband is more reliable than it used to be - much more reliable - but your connectivity can still be affected by the weather. DSL Drawbacks As mentioned earlier, there is an 18,000-foot limitation on DSL services. However, attenuation the gradual weakening of a signal -

occurs before the actual distance limitation is reached. A bad splice or overall corrosion can lead to an impedance mismatch. As with attenuation, the signal isn’t totally lost, but it is degraded. Those impedance mismatches can be introduced by using wires with different wire gauges. The American wire gauge (sometimes called the Brown & Sharp wire gauge, according to Wikipedia) refers to a standardized system of measuring wire and cable thickness. Signal interference can come from

“inside” and “outside” our network as well. The “inside” interference can result from crosstalk, the result of a signal “crossing over” and interfering with another signal. The “outside” source, I kid you not, is AM radio. Certain AM frequencies can interfere with the DSL signals. Data Transport Over ATM There’s an unusual type of Asynchronous Transfer Mode (ATM) switch as use in this type of network, a DSLAM. DSLAMs are

just ATM switches with DSL cards in them. Nothing to it, right? :) It’s not as complex as it seems. When it comes to transporting data over this setup, we’ve got three choices: PPP over Ethernet (PPPoE) PPP over ATM (PPPoA) RFC 1483/2684 Bridging RFC 1483 Bridging has some advantages and some serious drawbacks.

Advantages: Easy to set up, install, and configure Offers multiprotocol support Excellent for single-user environments Disadvantages: Uses a lot of broadcasts, which can quickly use most or all available bandwidth. Not a scalable solution. Wide open to intruder attacks, including ARP spoofing, IP

address hijacking, broadcast attacks

and

Other than that, Mrs. Lincoln, how did you enjoy the play? More likely, you’ll use Point-toPoint Protocol over Ethernet (PPPoE). Defined in RFC 2516, this process involves bridging an Ethernet frame from the host PC to an aggregation router such as the Cisco 6400 series. However, the Ethernet frame will actually contain a PPP frame, enabling a PPP session to be built

between the host device and the aggregation router. While the PAP / CHAP PPP option is there, CHAP will typically be used due to its encryption options. There are actually two encapsulations taking place. First, the host data is placed into a PPP frame, and then that PPP frame is placed into an Ethernet frame. Finally, the “frame inside a frame” is ready to transmit.

At the very beginning of the PPPoE process, the host device will perform Discovery - and what the host needs to discover is the MAC

address of the PPPoE server. That server will be the aggregation router. This establishes the clientserver relationship, identified by a PPPoE SESSION_ID value. Once Discovery has concluded, the PPP process can continue as it normally would over an ISDN link. Configuring PPPoE Here’s the network we’ll be working with in the following section. We’ll assume the interface closest to the PCs is Ethernet1, and the interface facing the DSLAM is Ethernet0.

Cisco 800 Router: Ethernet interface facing the hosts (Ethernet1) int e1 ip address 172.1.1.1 255.255.255.0

Ethernet interface DSLAM (Ethernet 0)

facing

the

int e0 no ip address pppoe enable pppoe-client dial-pool-number 1

For you ISDN fans (and non-fans), the dial-pool-number command sounds like it links to a dialer profile. The pppoe-client dialpool-number statement binds the physical interface - in this case, the Ethernet0 interface - to the dialer interface. Here’s a typical dialer profile, along with the necessary access-list

and dialer-list statements. access-list 1 permit 172.1.1.0 0.0.0.255 dialer-list 1 protocol ip permit interface Dialer1 ip address negotiated ip mtu 1492 (required for PPPoE configuration; must be placed on dialer interface) dialer pool 1 encapsulation ppp ppp authentication pap ppp pap sent-username CCNP password ISCW

I configured PAP here, but remember that PAP sends passwords in clear text. I personally prefer to use CHAP, which sends a hash result rather than a clear-text password. Those first two commands may be new to you: ip address negotiated - This allows this interface to obtain its address during PPP address negotiation. Another command you may see there is ip address dhcp command allows an interface to acquire an

address via DHCP. ip mtu 1492 - Due to the additional overhead associated with PPPoE, the MTU should be reduced to 1492. The overhead results from the PPPoE header (6 octets) and the PPP Protocol ID (2 octets). Why A Static Route? We spend time in both the OSPF and EIGRP sections talking about stub areas, and how they really just need a single default route in many cases.

A home worker is the ultimate stub area - when the router receives the data from the subscriber, there’s only one possible exit interface for it to use, and that’s the dialer profile on the way back to HQ. There’s no need to run a routing protocol, since the exit interface will remain the same and we’ll have the additional overhead associated with a dynamic protocol. Instead, just write a default static route using the dialer profile interface as the local exit interface. ip route 0.0.0.0 0.0.0.0 interface dialer0

You also learned all about NAT and PAT during your CCNA studies, and we’re going to configure PAT here as well. The commands are the same as the ones you learned during your NA studies, but watch where you put the ip nat inside and ip nat outside commands! ip nat inside source list 1 interface dialer 1 overload int e1 ip nat inside int dialer0 ip nat outside

As you know, the overload option enables PAT, allowing us to use a single routable IP address for multiple inside hosts. Also note that while the ip nat inside command is configured where we’d expect it, on the inside physical interface, the ip nat outside command is applied on the dialer profile. If you like, you can also configure DHCP on this router, and allow it to serve as the DHCP server for the inside hosts. Configuring a Cisco router as a DHCP server offers too many options to see them all here, but let’s assume we want to assign

addresses from the network 172.1.1.0 /24, but no addresses with the last octet of 1 - 100. Also, we’ll assign a 30-day lease. ip dhcp excluded-address 172.1.1.1 172.1.1.100 ip dhcp pool 1 network 172.1.1.0 255.255.255.0 lease 30

To reiterate, you’ll have many options with DHCP on Cisco routers, so just do your homework on Cisco’s website before jumping in and configuring!

Network Address Translation NAT will be a thing of the past one day. Today is not that day. Network Address Translation (NAT) allows a network host with a private IP address to have the source IP address of their packets “translated” into a routable address. Port Address Translation (PAT) allows a single routable IP address to be used by multiple inside private IP hosts. The private IP

addresses are translated to the same public IP, but each host will use a different port number. PAT is commonly referred to as “overloading”. The private IP address ranges are defined by RFC 1918, and they fall into these ranges: Class A: 10.0.0.0 /8 Class B: 172.16.0.0 /12 Class C: 192.168.0.0 /16 Note that the masks that accompany these private address ranges are not

the network masks for the classes (/8, /16, /24). There are four terms used to describe these addresses at different points in the entire NAT process. Inside local addresses are used by hosts on the inside network to communicate with other hosts on that same network. These are the addresses that are actually configured on the hosts. These inside local addresses are translated into inside global

addresses. Inside global addresses are routable addresses. Outside global addresses are the addresses that are configured on the outside hosts. These are fully routable addresses used by Internetbased hosts. Finally, outside local addresses are the actual addresses of remote hosts. This can be, and probably is, an RFC 1918 address as well.

From the 10.1.1.1 host’s point of

view, these are the NAT addresses: Inside Local: 10.1.1.1 /8 Inside Global: 210.1.1.1 /24 Outside Global: IP Address of web server. Outside Local: If web server is using an RFC 1918 address and the remote router is also using NAT, that 1918 address would be the outside local address. Static NAT If a limited number of hosts on a

private network need Internet access, static NAT may be the appropriate choice. Static NAT maps a private address to a public one. There are three internal PCs on an RFC 1918 private network, using addresses 10.5.5.5, 10.5.5.6, and 10.5.5.7. The router’s Ethernet0 interface is connected to this network, and the Internet is reachable via the Serial0 interface. The IP address of the Serial network is 210.1.1.1

/24,

with all

other

addresses on the network available.

210.1.1.0/24

Three static mappings are needed to use Static NAT. The interfaces must be configured for NAT as well. R3(config)#interface ethernet0 R3(config-if)#ip address 10.5.5.100 255.0.0.0 R3(config-if)#ip nat inside R3(config-if)#interface serial0 R3(config-if)#ip address 210.1.1.1 255.255.255.0 R3(config-if)#ip nat outside R3#conf t R3(config)#ip nat inside source static 10.5.5.5 210.1.1.2 R3(config)#ip nat inside source static 10.5.5.6 210.1.1.3 R3(config)#ip nat inside source static 10.5.5.7

210.1.1.4

R3#show ip nat statistics Total active translations: 3 (3 static, 0 dynamic; 0 extended) Outside interfaces: Serial0 Inside interfaces: Ethernet0 Hits: 0 Misses: 0 Expired translations: 0

Dynamic NAT Static NAT is fine for a few hosts, but consider a private network with 150 hosts. It would be an administrative nightmare to

configure 150 static NAT statements on your router. Dynamic NAT allows a pool of public IP addresses to be created. The public IP addresses are mapped to a private address as needed, and the mapping is dropped when the communication ends. Like Static NAT, Dynamic NAT requires the interfaces connected to the Internet and the private networks be configured with ip nat outside and ip nat inside, respectively.

Using the previous network example, R3 is now configured to assign an address from a NAT pool to these three network hosts as needed: R3#conf t R3(config)#access-list 0.0.0.255

1

permit

10.5.5.0

R3#conf t R3(config)#interface ethernet0 R3(config-if)#ip nat inside R3(config-if)#interface serial0 R3(config-if)#ip nat outside

R3#conf t R3(config)#ip nat inside source list 1 pool NATPOOL

R3(config)#ip nat pool NATPOOL 200.1.1.2 200.1.1.5 netmask 255.255.255.0

An access-list is used to identify the hosts that will have their addresses translated by NAT. The nat inside source command calls that list and then names the NAT pool to be used. The next line of the config defines the pool, named NATPOOL. The two addresses listed are the first and last addresses of the pool, meaning that 200.1.1.2, 200.1.1.3, 200.1.1.4, and 200.1.1.5 are in the pool, all using a mask of 255.255.255.0. Take care not to

include the serial address of the NAT router in the pool. The access list permits all hosts on 10.5.5.0/24, meaning that any host on that subnet can use an address from the NAT pool to communicate with Internet-based hosts. Show ip nat statistics will display the name and configuration of the NAT pool. R3#show ip nat statistics Total active translations: 0 (0 static, 0 dynamic; 0 extended) Outside interfaces: Serial0 Inside interfaces: Ethernet0 Hits: 0 Misses: 0 Expired translations: 0 Dynamic mappings:

-- Inside Source access-list 1 pool NATPOOL refcount 0 pool NATPOOL: netmask 255.255.255.0 start 200.1.1.2 end 200.1.1.5 type generic, total addresses allocated 0 (0%), misses 0

4,

Four addresses are available in the NAT pool. What if the network has 50 hosts and ten of them want to connect to an Internet host simultaneously? NAT allows multiple hosts to use the same public IP address via Port Address Translation (PAT). Generally referred to as

“overloading”, the private address will be translated to a public address and port number, allowing the same IP address to support multiple hosts. The router will differentiate the connections by using a different port number for each translation, even though the same IP address will be used. Port Address Translation is simple to configure. Instead of referring to a NAT pool with the ip nat inside source command, identify the outside interface followed by the word overload.

“overload” indicates that the IP address of the named interface will be the only one used for NAT, but that a different port number will be used for each translation, allowing the router to keep the different translations separate while using only a single IP address. R3(config)#interface ethernet0 R3(config-if)#ip nat inside R3(config-if)#interface serial0 R3(config-if)#ip nat outside R3(config-if)#ip nat inside source list 1 interface serial0 overload R3(config)#access-list 1 permit 10.5.5.0 0.0.0.255

Each host that matches the ACL will have its IP address translated to the same IP address - in this case, the same IP address that the serial interface is already using - but each host will be assigned a random port number. These ports will not be from the well-known port number range. The router keeps a translation table with the port numbers to allow translation when reply packets for these transmissions is received.

Copyright © 2012 The Bryant Advantage. All Rights Reserved.

IP Version 6

Why Do We Need A Version 6 Of IP, Anyway? The main reason - we’re running out of IPv4 addresses! That isn’t the only drawback to IPv4 addresses as compared to IPv6, but frankly, it’s the main one. The good news with IPv6 is that the 128-bit addresses give us a tremendous number of addresses,

and is designed to make route summarization easier and more efficient. The bad news: IPv6 uses 128-bit addresses. If this is the first time you’ve really looked at IPv6 - and you’re not alone if it is -- that’s the major shock factor. Once you get used to the address format, though, it’s really not that bad. Before we start comparing the version, let’s look at some additional improvements brought to

us by IPv6: Those dreaded broadcasts we’re always trying to limit are a thing of the past - IPv6 doesn’t use them. NAT was developed to help with the IPv4 address shortage, and since that will also be a thing of the past, so will NAT. (NAT is not a thing of the past when it comes to your CCNP ROUTE exam.) IPv6 was specifically

designed with route aggregation in mind, making that aggregation easier and more effective, which in turn keeps our routing tables - say it with me - complete and concise. The security capabilities of IPv6 are much greater than that of IPv4. That’s particularly true when it comes to Mobile IP. IPv4 can run that with additional config (boo!), but IPv6 doesn’t need any extra config (yay!)

DHCP is still available, but IPv6 nodes can assign themselves an address without the help of a DHCP server via autoconfiguration. Quality of Service (QoS) capabilities are greater with the IPv6 header values than with IPv4 - more about that in just a moment. Of course, moving your entire network from IPv4 to IPv6 might be

a little tricky - any migration is. Knowing the fundamentals of IPv6 makes that migration a lot easier, and we’ll jump into that right now with a comparison of the actual IPv4 and v6 headers. IPv6 Header Fields You’re familiar with the IPv4 headers, but there are quite a few changes in the move to IPv6. Here’s a link to an illustration on Cisco’s website comparing the v4 and v6 headers:

http://www.cisco.com/web/about/ac1 3/93_ipv6_fig1_lg.jpg There are eight header fields in IPv6: version - This is set to “6” in IPv6. But you knew that. :) traffic class - In IPv4, this was the Type Of Service (TOS) field. The “traffic class” name comes from this field’s ability to allow us to assign levels of importance to a packet via QoS.

flow label - No equivalent in IPv4, this field allows a packet to be labeled as part of a particular flow. This also helps with QoS, allowing us to prioritize traffic flows rather than individual packets. payload length - IPv4’s equivalent is the Total Length field hop limit - Roughly equivalent to IPv4’s Time To Live (TTL)

field. Every hop decrements this counter by one, and when that counter hits zero -- the “time to live” becomes the time to be discarded. next header - Equivalent to IPv4’s Protocol field source address, destination address - they’re now 128 bits! There are some IPv4 fields that are not represented in IPv6:

Header Length Identification Flags Fragment Offset Header Checksum The IPv6 Address Format Typical IPv4 129.14.12.200

address:

Typical IPv6 address: 1029:9183:81AE:0000:0000:0AC1:2 IPv6 isn’t exactly just tacking two more octets onto an IPv4 address! With IPv6, our non-compressed address has eight sections of four hex values, separated by a total of seven colons. Luckily for us, there are easy ways to compress these addresses so we don’t have to enter so many numbers -- and I have a feeling your ability to perform these compressions will be a highly

valuable skill on your way to passing the CCNP ROUTE exam. You remember from your CCNA studies that there’s no difference between an upper-case letter or lower-case letter in hexadecimal. That’s the first rule. The other rules deal with all the zeroes you’ll run into in IPv6 addresses. If you’re not comfortable and/or rusty with your hexadecimal conversions, I strongly recommend you work with the hex conversions workbook included with this course before proceeding. Hex is easy

when you know how, and once you work with that material just a bit, you’ll know how. Please take my word for this: Even if you think you’re comfortable with hex, spend a little time practicing your conversions anyway. Zero Compression And Leading Zero Compression If you have consecutive fields of zeroes, they can be expressed with two colons. It doesn’t matter if you have two fields or eight, you can simply type two colons and that

represents all of them. The key rule: you can only do this zero compression once in an IPv6 address. Here’s an example:

Original format: 1234:1234:0000:0000:0000:0000:34 Using zero compression: 1234:1234::3456:3434 Leading zeroes in any 16-bit field can be dropped, but each block you do this with must have at least one number remaining. If the block is all zeroes, you have to leave one zero.

This is leading zero compression. Zero compression: Allowed only once per address. Leading zero compression: Perform as often as you like in an address. Let’s look at an example of leading zero compression with this address:

1234:0000:1234:0000:1234:0000 We have four different fields with leading zeroes, making this address a prime candidate for leading zero compression.

Original format:

1234:0000:1234:0000:1234:0000 With leading zero compression:

1234:0:1234:0:1234:0:123:1234 We’re allowed to use both zero compression and leading zero compression in a single address, and the frequency rules discussed earlier apply. Using both methods, we can take this address….

1111:0000:0000:1234:0011:0022 .. and compress it to this:

1111::1234:11:22:33:44 Zero compression uses the doublecolon to replace the second and third block of numbers, which were all zeroes; leading zero compression replaced the “00” at the beginning of each of the last four blocks. Just be careful and take your time with both zero compression and leading zero compression and you’ll do well on the exam and in the real world. The key to success here is remembering that you can only use zero compression once in a

single address. Tipoffs that you’re looking at an invalid IPv6 address include seeing four colons in a row… 1111::::2222:3333:4444:5555 … or spotting consecutive colons at multiple points in that same address. 1111::2222::4444:5555 The key to success with IPv6 compression: practice. Identifying An Interface In IPv6

Every interface on a given IPv6 link has to have a unique identifier, and once again the name is the recipe with these interface identifiers. This value will always be 64 bits in length, and in the case of an Ethernet interface, the identifier is dynamically created from the MAC address of the interface. The 48-bit MAC address. Hmm. Sounds like we need to add something there… and that’s just

what IPv6 does. The hex value “FFFE” is inserted directly in the middle of the MAC address, right between the OUI and the vendor code. (Confess: Never thought you’d hear the term “OUI” again, right?) In the MAC address 00-01-02-aabb-cc, the OUI is 00-01-02 and the vendor code is aa-bb-cc. It’s simple enough, then, to come up with the interface identifier here… 00-01-02-FF-FE-aa-bb-cc.

This is networking, though, so you know there’s got to be one more detail here. That detail is the seventh bit of the first octet, and right now that first octet is… 00000000 The 7th bit is the Universal/Local bit, and that’s just what this bit does -it tells us whether this address is universally unique or just locally unique (unique only to this link). It’s assumed a MAC address is universally unique, so that U/L bit is set to 1…

00000010 … giving us a final interface identifier of 02-01-02-FF-FE-AABB-CC. The 8th bit is generally called the g bit, “g” standing for “group, but you’ll occasionally see it called the i/g bit for “individual/group”. If this bit is set to zero, it’s a unicast address; if set to one, it’s a multicast address. IPv6 Address Types You know the drill with IPv4

address types: Unicast - represents a single host Multicast - represents a group of hosts Broadcasts - represents all hosts We still have unicasts and multicasts with IPv6, but broadcasts are gone and now we have anycasts - an address that represents multiple

interfaces. Additionally, we have different types of unicast addresses. The official name of the first IPv6 unicast address we’ll discuss is aggregateable global unicast address. Quite a bit of documentation on IPv6 leaves the “aggregateable” off, so we’ll refer to these addresses simply as global unicast addresses. This address is equivalent to the public IPv4 address classes. These addresses are fully routable and can

be used for Internet access. The word “aggregateable” refers to the ability to aggregate, or summarize, these addresses to make routing more efficient. Unlike IPv4, IPv6 is specifically designed to be fully hierarchical, allowing for easier and more efficient route aggregation. The range of IPv6 global unicast addresses is 2000::/3 (any address that begins with 001). The IPv6 link-local address is our “the name is the recipe” address of

the day - it’s an address that is kept on the local link. They’ll have an prefix of Fe80::/10, followed by that interface identifier we spoke of earlier. Much more on these later. Site-local addresses were originally created as IPv6’s equivalent to IPv4’s private address classes. You’re likely reading that and thinking “If we don’t need NAT any more and we have sooooo many addresses with IPv6, why do we need private address classes?”

Great question! It’s such a great question that site-local addresses are no longer used by IPv6. I’m mentioning it here just in case you’ve read some of my older IPv6 materials (or someone else’s!) that mentioned them. You can identify several classes of IPv6 addresses by their initial bits: 001 - Global address 1111 1111 - Multicast (FF) 1111 1110 10 - Link Local

(FE80) ::x.x.x.x or 0:0:0:0:0:0:x.x.x.x - IPv4compatible address. Any IPv6 address with the first 96 bits set to zero is an IPv4compatible address. I used zero compression in the first representation of that range, and leading zero compression for the second. Reserved IPv6 Addresses IPv4 has the reserved address

127.0.0.1 to allow for testing; IPv6 has a loopback address reserved for the same purpose.

IP v6 Loopback: 0000:0000:0000:0000:0000:0000:0 Using Leading Zero Compression Only: 0:0:0:0:0:0:0:1 Combining Leading Zero and Zero Compression: ::1 Zero compression looks pretty good now, doesn’t it? Unique to IPv6 is the unspecified address. You may be thinking “if

it’s unspecified, how do we know what it is?” Another great question! This address is used to represent an unknown address.

IPv6 Unspecified Address: 0000:0000:0000:0000:0000:0000:00 Using Zero Compression: 0:0:0:0:0:0:0:0, or just ::/128. Since the unspecified address is ::/128, it follows that the default route for IPv6 is ::/0. IPv4 - IPv6 Compatible Addresses

If you see an address with a great many zeroes -- 96 of them, to be exact -- at the beginning, it may well be an IPv4-compatible IPv6 address. Such an address is going to have zeroes for the first 96 bits, which makes zero compression even better! The rest of the bits are simply a hexadecimal expression of the IPv4 address. For example…. IPv6 Address ::D190:4E71 The

To

double-colon

Convert: is

zero

compression in action, so now we need to convert the lower 32 bits into decimal. Hex D1 = Decimal 209 Hex 90 = Decimal 144 Hex 4E = Decimal 78 Hex 71 = Decimal 113 The IPv4 address that was embedded into the IPv6 address is 209.144.78.113. Just another good reason to know your hex conversions!

Multicasts And Anycasts You know what a multicast is, and that IPv4 multicast addresses are Class D addresses with a first octet value of 224 - 239. The IPv6 multicast range is much larger, but just as easy to remember. Any address that begins with “1111 1111”, or “FF” in hex, is a multicast address -- the full prefix being FF00::/8. There are some local-link-only addresses in that range worth noting:

FF02::1 -- All nodes on the local link FF02::2 -- All routers ““ FF02::9 -- All RIP routers ““ FF02::A -- All EIGRP routers ““ FF02::1:FFzz:zzzz/104 -Solicited-node address. These are used in Neighbor Solicitation messages - more

about these very soon. The “z”s are the rightmost 24 bits of the unicast/address of the node. Here’s a link to a regularly-updated IANA document with plenty of additional reserved addresses and links to related RFCs. It’s not required reading for the CCNP ROUTE, but an excellent document for present and future reference.

http://www.iana.org/assignments/ipv multicast-addresses/ipv6-multicastaddresses.xml

The Anycast Address IPv6 introduces the anycast address, an interesting combination of unicast and multicast An anycast address is a unicast address assigned to multiple interfaces. (Something we really couldn’t get away with in v4.) A sender transmits an anycast packet in the same manner it would a unicast packet… … and when the router receives the anycast packet, the router then sends

that packet to the closest device with that anycast address. Sounds simple, right? It is - but we also know the word “closest” is a big red flag. “You said I’m closest. How am I closest? What is so closest about me?” Sorry. But we really do need to know how IPv6 defines “closest” here… It’s the first learned directly connected neighbor - if there

are directly connected neighbors. If that’s not the case, it’s simply the closest neighbor as determined by the routing protocol metric. That’s how I’m closest, Henry. The IPv6 Process

Autoconfiguration

IPv4 has DHCP; IPv6’s equivalent is autoconfiguration. There are two main types of autoconfiguration

- stateless and stateful. Stateful autoconfiguration is used when the host obtains an IPv6 address and other information from a server. If that sounds kinda like DHCP, that’s because it is DHCPv6, actually! You hear the term stateful autoconfiguration more often than “DHCPv6”, though, but you should know they’re one and the same. The key phrase there is “from a server”. If the DHCPv6 server goes down, we’re out of luck. With stateless autoconfiguration, there’s

no such dependency, and the entire process starts with the IPv6 host configuring its own link-local address. An IPv6 address is 128 bits, and here’s where they come from in this instance: The first 64 bits of this selfgenerated address will be 1111 1110 10 (FE80) followed by 54 zeroes. The last 64 bits are the interface identifier.

Technically, that address is tentative at this point. It’s been successfully calculated, but now we must make sure that no other host is using the same address. That’s a remote possibility, but still a possibility, and that’s where DAD comes in - the Duplicate Address Detection feature. At this point, the host will send a Neighbor Solicitation (NS) message to see if any other host on the link is using that same link-local address.

Basically, the host is asking all other hosts on the link, “Is anyone else using the address I just generated for myself?”

If another host on the link is using that address, that host will respond with a Neighbor Advertisement

(NA). When the host that sent the NS receives the NA, it will disable its link-local address. If no response to the NS is received, the local host is satisfied that it has a unique link-local address. At this point, that host will send a Router Solicitation (RS) onto the segment. The destination for the RS will be FF02::2, the “all-routers” multicast address. What’s the host soliciting? It needs additional configuration information

from a router in the form of a Router Advertisement (RA). Routers generally send these RAs periodically without an express request from a host, but even though the host would only have to wait 10 seconds or so, polling the router now with an RS does speed up the overall process. (If the router is running the usual ipv6 unicast-routing command, you’ll see those RAs. If the router is running the ipv6 address autoconfig command but not unicastrouting, those RAs are not sent.)

Information in the RA includes… Flags indicating whether the host should use DHCP for addressing information If DHCP is in use, the RA tells the host where the DHCP serer is If not, the RA contains the prefix and prefix lifetime information If DHCP is not in use, the router

attaches the network prefix to the host’s link-local address, which results in the host’s full IPv6 address complete with network prefix.

IPv6 Routing On Cisco Routers To go along with the new address

types, we have new variations of RIP for IPv6 - the actual name is RIPng (new generation) EIGRP for IPv6 ISIS for IPv6 OSPF v3 (Version 3, defined in RFC 2740.) Static routes are still available with IPv6

Multiprotocol BGP V4 (MPBGPVer4 or simply MPBGP) Before we start with any of these, we need to enable a Cisco router’s IPv6 routing capabilities with ipv6 unicast-routing. R1(config)#ipv6 unicast-routing

OSPF For IPv6 (OSPF Version 3) Of the IPv6-compatible protocols listed earlier, OSPF v3 is probably

the one in the most widespread use today. Let’s take a look at some basic OSPFv3 commands and compare OSPF v3 to IPv4’s OSPF v2. During your migration between the two, you may run both v2 and v3 on the same router. There’s no rule against that, and the two instances are kept as separate as they would be if you ran two v2 instances on the same router. In IPv6, you’re not going to start an OSPF configuration with router ospf. One major difference between

v2 and v3 is that v2 is enabled in router config mode and v3 is enabled on a per-interface basis. This will automatically create a routing process. R1(config-if)#ipv6 ospf 1 area 0

One similarity between the two versions is their use of the OSPF RID. v3 is going to use the exact same set of rules to determine the local router’s RID - and v3 is going to use an IPv4 address as the RID! If there is no IPv4 address configured on the router, you’ll

need to use our old friend router-id to create the RID. The RID must be entered in IPv4 format, even if you’re only running IPv6 on the router. R1(config-router)#router-id 12.1.1.1

Other similarities and differences between v2 and v3: The basic operational theory of v3 is very similar to that of v2. The Hello packet is still around, as are the LSAs and LSAcks.

Stub, total stub, and NSSAs are still around, and the Area 0 rule still exists (as do virtual links). The general rules for neighbor discovery and adjacencies are the same. And speaking of discovery… v3 NBMA configurations require neighbor statements, just like v2.

One major difference between the two is that v3 allows a link to be part of multiple OSPF instances, where v2 would allow a link to be part of only one. v3 point-to-point and point-tomultipoint configurations do not elect DRs and BDRs, just like v2. v3 headers are smaller than v2, since v3 headers have no authentication fields.

The v2 reserved address 224.0.0.5 is represented in v3 by FF02::5. The v2 reserved address 224.0.0.6 is represented in v3 by FF02::6. We can still use the area range command, and IPv6 does make summarization more effective but when you use the area range command in v3, the OSPF cost of that summary is

simply the highest of the individual route costs. So while we have new addresses and commands to get used to, the theory remains much the same. A Sample OSPFv3 Configuration Before we begin the configuration, we need to enable IPv6 packet forwarding with ipv6 unicastrouting, the IPv6 version of Cisco Express Forwarding (CEF) with ipv6 cef, and the OSPF v3 process with ipv6 router ospf.

R1(config)#ipv6 unicast-routing R1(config)#ipv6 cef R1(config)#ipv6 router ospf 1 R1(config-rtr)# R2(config)#ipv6 unicast-routing R2(config)#ipv6 cef R2(config)#ipv6 router ospf 1 R2(config-rtr)#

If you don’t have any IPv4 addresses configured on the router, you must configure an OSPF RID with the router-id command. R1(config)#ipv6 router ospf 1 R1(config-rtr)#router-id 1.1.1.1 R2(config)#ipv6 router ospf 1 R2(config-rtr)#router-id 2.2.2.2

OSPF v3 interfaces are placed into areas at the interface level. R1(config-rtr)#int fast 0/1 R1(config-if)#ipv6 ospf 1 ? area Set the OSPF area ID R1(config-if)#ipv6 ospf 1 area 0 R2(config-rtr)#int fast 0/1 R2(config-if)#ipv6 ospf 1 area 0

Here, IOS Help shows us that quite a few OSPF v3 options look just like their v2 counterparts! R2(config-if)#ipv6 ospf ?



Process Enable

authentication

authenti

cost

Interfac Filter O LSA du synchro and floo Interval which a neighbo declare OSPF d circuit OSPF F Reducti Time be HELLO

databasefilter

dead-interval demandcircuit floodreduction hello-interval

mtu-ignore neighbor network priority retransmitinterval transmitdelay

packets Ignores MTU in packets

OSPF n Networ Router Time be retransm lost link adverti Link sta transmi

One thing we still like to see in

OSPF v3 are adjacencies! Here, the router console lets us know that an adjacency has just been formed. Note the message indicates that OSPF v3 is in use. *Mar 4 16:13:48.623: %OSPFv3-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/ 1 from LOADING to FULL, Loading Done

Verify OSPF v3 adjacencies with show ipv6 ospf neighbor.

To see more details about the neighbor, run show ipv6 ospf neighbor detail. The output is just a

little different than OSPF v2. R2#show ipv6 ospf neighbor detail Neighbor 1.1.1.1 In the area 0 via interface FastEthernet0/1 Neighbor: interface-id 10, link-local address FE80::20A:41FF:FE64:31C2 Neighbor priority is 1, State is FULL, 6 state changes DR is 2.2.2.2 BDR is 1.1.1.1 Options is 0x84EFB26D Dead timer due in 00:00:34 Neighbor is up for 00:06:52 Index 1/1/1, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec

Here are two other important OSPF v3 commands, show ipv6 ospf interface and show ipv6 ospf database. The first command shows the link-local address of both the local router and the BDR (R1). The second command indicates the use of OSPF v3 in the output almost immediately. R2#show ipv6 ospf interface fast 0/1 FastEthernet0/1 is up, line protocol is up Link Local Address FE80::20F:F7FF:FE69:8D21, Interface ID 5 Area 0, Process ID 1, Instance ID 0, Router ID 2.2.2.2 Network Type BROADCAST, Cost: 1 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 2.2.2.2, local

address FE80::20F:F7FF:FE69:8D21 Backup Designated router (ID) 1.1.1.1, local address FE80::20A:41FF:FE64:31C2 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:08 Index 1/1/1, flood queue length 0 Next 0x0(0)/0x0(0)/0x0(0) Last flood scan length is 1, maximum is 4 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 1.1.1.1 (Backup Designated Router) Suppress hello for 0 neighbor(s) R2#show ipv6 ospf database OSPFv3 Router with ID (2.2.2.2) (Process ID 1)

Router Link States (Area 0)

The IPv6 equivalent of OSPF IPv4’s show ip ospf is show ipv6 ospf. This command also indicates the use of OSPF v3. R2#show ipv6 ospf Routing Process “ospfv3 1” with ID 2.2.2.2 SPF schedule delay 5 secs, Hold time between two SPFs 10 secs Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Number of external LSA 0. Checksum Sum 0x000000

Number of areas in this router is 1. 1 normal 0 stub 0 nssa Reference bandwidth unit is 100 mbps Area BACKBONE(0) Number of interfaces in this area is 1 SPF algorithm executed 3 times Number of LSA 6. Checksum Sum 0x0293F7 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0

The IPv6 equivalent of OSPF IPv4’s clear ip ospf process is clear ipv6 ospf process. Just as with OSPF v2, the OSPF database is cleared out and then rebuilt with this command. Note that first I tried to use the OSPF v2 command clear

ip ospf process, but that did nothing since we’re not running OSPF v2. OSPF v3 still asks us if we’re really sure we want to do this - the prompted answer to the question “Reset ALL OSPF processes?” is “no”! R1#clear ip ospf process R1# R1# R1#clear ipv6 ospf process Reset ALL OSPF processes? [no]: y R1# *Jan 22 02:46:33.535: %OSPFv3-5ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached R1# *Jan 22 02:46:41.879: %OSPFv3-5-

ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/1 from LOADING to FULL, Loading Done

Here are some general IPv6 commands and their output you should be familiar with: R2#show ipv6 route IPv6 Routing Table - 5 entries Codes: C - Connected, L - Local, S - Static, R RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 OSPF NSSA ext 2 O 4DDE:EEEE:1::/64 [110/1]

via ::, FastEthernet0/1 C 5DDE:EEEE:1::/64 [0/0] via ::, FastEthernet0/1 L 5DDE:EEEE:1::1/128 [0/0] via ::, FastEthernet0/1 L FE80::/10 [0/0] via ::, Null0 L FF00::/8 [0/0] via ::, Null0 R2#show ipv6 interface FastEthernet0/1 is up, line protocol is up IPv6 is enabled, link-local address is FE80::20F:F7FF:FE69:8D21 Global unicast address(es): 5DDE:EEEE:1::1, subnet is 5DDE:EEEE:1::/64 R2#show ipv6 interface brief FastEthernet0/0 down/down] unassigned

[administratively

Serial0/0 [administratively down/down] unassigned FastEthernet0/1 [up/up] FE80::20F:F7FF:FE69:8D21 5DDE:EEEE:1::1 Serial0/1 [administratively down/down] unassigned

Transitioning From IPv4 To IPv6 This is the part that’s going to be really interesting for all of us in the years ahead. Any migration is challenging, and migrating a network from IPv4 to IPv6 is no exception.

Theory holds that to roll out IPv6, you start at the network edge and work your way toward the core. This means we have to think of some ways for IPv6 and IPv4 to work together while we make the transition to an all-IPv6 network. To get this job done, you’re either translating or encapsulating. There are three primary methods of accomplishing this. The first is the dual stack. A host runs dual stack when it runs both IPv4 and IPv6. Dual stack helps meet the migration challenge we

face when end users want to keep using their favorite IPv4-based apps while the network moves forward to IPv6-based apps. Another solution is the 6-to-4 tunnel. Cisco documentation states that setting up a 6-to-4 tunnel is very simple on the host ends of the tunnel. A 6-to-4 tunnel is also automatic, is torn down when the session ends, and is a scalable solution. 6-to-4 tunneling is accomplished by taking an IPv6 packet and encapsulating it into an IPv4 packet

(protocol type 41) for transport across the IPv4 section of the network, then de-encapsulating it when the remote edge router is ready to route it across the IPv6 network. The IPv6 networks shown in this method are sometimes referred to as IPv6 islands. 6to4 tunnels also have a reserved IPv6 address prefix for edge routers such as the ones shown below. These prefixes begin with 2002 and are followed by the router’s IPv4 address expressed in hex. These prefixes carry a /48 prefix, such as 2002:1234:83cd::/48.

The IPv4 address of the interface involved in the tunneling is vital in determining the correct IPv6 address for the tunnel. Let’s say the IPv4 address of the router on the left is 220.200.18.42. We know the address for the corresponding tunnel interface begins with 2002 but what’s the rest of it? Breaking down each octet into hex, we get: 220 = 13 units of 16, 12 units of 1 =

hex value is DC 200 = 12 units of 16, 8 units of 1 = hex value is C8 18 = 1 unit of 16, 2 units of 1 = hex value is 12 42 = 2 units of 16, 10 units of 1 = hex value is 2A The IPv6 address for the tunnel interface is 2002:DCC8:122A::/48. R1(config)#int fast 0/1 R1(config-if)#ip address 255.255.255.0 R1(config-if)#int tunnel0

220.200.18.42

R1(config-if)#ipv6 2002:DCC8:122A::/48

address

Another method of cutting over from one version to the other is Network Address Translation Protocol Translation. NAT-PT works much like plain old NAT. If you have IPv6 hosts that need to intercommunicate with IPv4 hosts on another segment, NAT-PT may be the perfect solution. NAT routers translate private IPv4 addresses to public IPv4 addresses, and back again; NAT-PT routers translate IPv6 addresses to IPv4 addresses, and back again.

A Final Word On IPv6 As I mentioned earlier, I admit my first reaction to IPv6 was “what do we need that for?” The key is not why it’s here, but that it is here. We can either resist it or embrace it, and we might as well start embracing it -because it is here! What you must not do is take the approach of “well, we use IPv4 at my job, so I don’t need to know IPv6.” I heard the same thing when Windows 2000 Server came along “We use NT4 and we’ll use that forever.” That didn’t work out for

too many people. My point here is that you don’t want to fall into that trap. Few of us are going to work in one place forever in this field, and to get ahead, we have to know things that other people don’t. Like IPv6. Those who know IPv6 are going to have a huge advantage over those who don’t. I’ve only given you an introduction to IPv6 here. There is a lot of solid information available readily through your favorite search engine, some of it from Cisco and some not. Take the incentive now

and learn IPv6. You’ll be glad you did!

Copyright © 2012 The Bryant Advantage.. All Rights Reserved.

Route Redistribution

What Is Route Redistribution? Route redistribution is simply the process of taking routes from one source and placing them into another routing domain. That source doesn’t have to be a dynamic routing protocol - we can redistribute directly connected networks and static routes. Sounds simple, right? Maybe even fun?

Actually, you’ll find the basic configs of route redistribution to be just that - simple - with two caveats: The more route redistribution you perform in a given network, the greater the chance of routing loops. That’s especially true when you’re redistributing between networks with multiple entrance / exit points. We’re in the business of details, but with route

redistribution, you really have to watch the details. Some protocols require seed metrics; others don’t. Some require you to configure a default metric; some don’t. The rules aren’t complex, but they are vital. Route redistribution is much like route summarization in that they’re both helpful in the right situation, and it should be you and I as the network admins who decide where route redistribution takes place not the routing protocol.

In real-world networks and your CCNP ROUTE exam, you’re going to find very few scenarios where route redistribution takes place automatically. It’s a good idea to know where that might happen, though…

Here’s a network where the nowobsolete IGRP is the LAN protocol, and OSPF is used as the organization’s WAN protocol. The

central router is the only router that knows that two protocols are being used. The OSPF-only router has no idea of the IGRP routes, and the IGRP-only router doesn’t have any of the OSPF routes. That’s likely the way we want it, for two major reasons: There’s no reason for the LAN to have individual routes for any destinations across the WAN, since the next-hop address would always be R1.

There’s really no reason for the WAN routers to have paths to the LAN networks, and it could pose a security issue for outside routers to know exactly what network numbers we’re using on our LAN -that makes attacking our WAN that much easier. If for some reason we did want the WAN to know about some or all of our LAN routes, or vice versa, we’d need to configure route redistribution.

So if IGRP is obsolete, why did I mention it? Because IGRP is involved in an auto-redistribution scenario. If IGRP and EIGRP are running on the same router and are using the exact same AS number, each protocol will automatically redistribute their routes to the other. There are other scenarios where route redistribution happens automatically, all of them involving EIGRP. Automatic Route Redistribution Scenarios

IGRP automatically redistributes with EIGRP when both run the same AS number. EIGRP for AppleTalk automatically redistributes between EIGRP and RTMP (Routing Table Management Protocol, an AppleTalk routing protocol). EIGRP for IPX will automatically redistribute between IPX for RIP

(Internetwork Packet Exchange, a networking protocol used by Novell NetWare). Let’s look at a much more common scenario - where we have multiple EIGRP instances running on a single router (a “border router”). In the following lab, R1 is running two EIGRP instances with the AS numbers 50 and 100. R2 is the neighbor in AS 100, R3 in AS 50. Both routers are advertising their loopback via EIGRP.

R1 sees both routes … R1#show ip route eigrp 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/2297856] via 172.12.123.2, 00:09:33, Serial0 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/2297856] via 172.12.13.3, 00:00:29, Serial1

.. but neither R2 nor R3 sees the other’s loopback.

R2#show ip route eigrp R2# R3#show ip route eigrp R3#

The same rule holds for routes redistributed into an EIGRP AS -they will not be redistributed into any other EIGRP ASes running on that router. Note that all EIGRP routes here are internal and have an AD of 90; we haven’t done any route redistribution, so we have no external routes. We’ll revisit this

lab in the EIGRP-specific portion of this session. OSPF processes running on the same router do not automatically exchange routes.

Just as with EIGRP, R1 will see both loopbacks but neither R2 nor R3 will see the other’s loopback.

R1#show ip route ospf 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/65] via 172.12.123.2, 00:00:35, Serial0 3.0.0.0/32 is subnetted, 1 subnets O 3.3.3.3 [110/65] via 172.12.13.3, 00:00:07, Serial1 R2#show ip route ospf R2# R3#show ip route ospf R3#

Now that we’ve covered nonredistribution in detail, let’s get to some redistribution! RIP And The Seed Metric

RIP’s configuration is pretty simple - so maybe redistributing routes into RIP is simple, too. Maybe. Let’s take a look at the redistribute command in a RIP config with IOS Help. R1(config)#router rip R1(config-router)#redistribute static ? metric Metric for redistributed routes route-map Route map reference

The is a little misleading

here. While the command redistribute static is a complete command, it’s not enough to do the job when redistributing routes into RIP - we need to plant a seed. Seed metric, that is. RIP’s sole metric is hop count. If we redistribute an OSPF route into RIP that has a cost of 74 - a common OSPF metric - RIP doesn’t want anything to do with that route, since RIP considers a metric of 16 to be “unreachable”.

We have to tell RIP “here’s a value for the route that you understand.”, and that value is the seed metric.

The seed metric will increment as the route travels through the new domain, just as any other route would. In the following network, we will redistribute one OSPF route into a RIP domain. First, we’ll try to redistribute the route without specifying the seed metric.

R1#show ip route < code table removed for clarity > 20.0.0.0/24 is subnetted, 1 subnets C 20.1.1.0 is directly connected, Serial0 172.12.0.0/24 is subnetted, 2 subnets O 172.12.34.0 [110/74] via 172.12.13.3, 00:00:12, Serial1 C 172.12.13.0 is directly connected, Serial1 R1(config)#router rip R1(config-router)#redistribute ospf 1 R1(config-router)#redistribute connected

First, we did what we should always do in this situation - make sure that the border router has the routes we want to redistribute in the first place.

T-Shoot Checkpoint #1: If you’ve redistributed routes into any routing protocol OSPF, RIP, EIGRP - and you see some of the routes but not all of them, the first thing you should do is make sure your border router has the routes in the first place.

If you don’t see any of the routes, there’s likely another issue. We’ll get to that later. We want R2 to see both the 172.12.13.0 /24 and 172.12.34.0 /24 networks, so both OSPF and connected routes have to be redistributed into RIP on R1. (172.12.13.0/24 is a connected route to R1.) T-Shoot Checkpoint #2: If you’ve successfully performed route redistribution and find some pings don’t go through

during your testing, it’s likely you need to redistribute your connected networks. In this example, redistributing OSPF routes into RIP isn’t enough, because 172.12.13.0/24 is not an OSPF route on the router performing the redistribution. Now on with the lab… R2#clear ip route * R2#show ip route rip R2#

When a show command returns nothing, there’s nothing to show. The OSPF route has not been successfully redistributed into RIP. Since RIP converges slowly, I ran clear ip route * to force updates to be sent and to be requested by R2. We do not see the route to 172.12.34.0/24 or 172.12.13.0 /24, and a quick debug ip rip shows that it’s not contained in any update from R1. R2#debug ip rip RIP protocol debugging is on R2#clear ip route *

R2# 00:13:39: RIP: sending request on Serial0 to 224.0.0.9 00:13:39: RIP: received v2 update from 20.1.1.1 on Serial0 00:13:39: 20.1.1.0/24 via 0.0.0.0 in 1 hops

Even though it’s R2 that isn’t getting the routes, the trouble’s at the border router. We didn’t configure a seed metric for the route, and even though R1 allowed us to enter redistribute ospf 1 as a valid command, the route was not redistributed. Let’s go back to R1 and run the command again, but use a seed metric this time.

R1(config)#router rip R1(config-router)#no redistribute ospf 1 R1(config-router)#no redistribute connected R1(config-router)#redistribute ospf 1 metric 2 R1(config-router)#redistribute connected metric 2

I removed the original redistribute commands. When you configure a redistribute statement, that does not remove any previously configured ones. (It’s common to have multiple redistribute commands in a protocol config.) Let’s go to R2, clear the routing table, and see what the situation is now with 172.12.34.0 /24.

R2#clear ip route * R2#show ip route rip 172.12.0.0/24 is subnetted, 2 subnets R 172.12.34.0 [120/2] via 20.1.1.1, 00:00:02, Serial0 R 172.12.13.0 [120/2] via 20.1.1.1, 00:00:02, Serial0 R2#ping 172.12.34.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.34.3, timeout is 2 seconds: ….. Success rate is 0 percent (0/5)

R2 now has both the OSPF route and connected route that were redistributed into RIP at R1. Putting the seed metric in the redistribution command allowed us to

successfully redistribute routes. However, the pings didn’t go through! Pings show us that there is an IP connectivity issue, but they don’t tell us where the problem is. To begin pinpointing an IP connectivity issue, run traceroute. R2#traceroute 172.12.34.3 Type escape sequence to abort. Tracing the route to 172.12.34.3 1 20.1.1.1 36 msec 36 msec 32 msec 2*** 3 * entered here, otherwise 30 rows will appear>

R2#

The problem seems to be on R1. Let’s try pinging 172.12.34.3 from there. R1#ping 172.12.34.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.34.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Interesting, eh? The real problem here is that the pings can get from R2 to R3, but R3 can’t get them back to R2. R3 is strictly an OSPF

router, and it has no route to R2. T-Shooting Checkpoint #3: Just because A sees B, it doesn’t mean that B sees A. We have two options to give R3 a route to R2: Write a static route Perform two-way route redistribution We’re in the redistribution business

right now, so let’s stay there. R1(config)#router ospf 1 R1(config-router)#redistribute connected % Only classful networks will be redistributed R1(config-router)#redistribute connected subnets

We didn’t put a seed metric for redistribution into OSPF. OSPF has a default seed metric of 20, so none has to be specified with the redistribute command. What OSPF does require is the subnets option to be enabled -- if you want subnets to be redistributed into OSPF, that is.

And it’s likely you do. Let’s look at R3’s routing table now: R3#show ip route ospf 20.0.0.0/24 is subnetted, 1 subnets O E2 20.1.1.0 [110/20] via 172.12.13.1, 00:01:51, Serial1

We see two important OSPF defaults in action here: The route has a metric of 20, OSPF’s default seed metric The route is marked as “E2”, short for External-Type 2. This

is the default routing code for a route redistributed into OSPF. An E2 metric reflects only the cost from the ASBR (R1) to the external destination (R2). Let’s see if R3 and R2 can exchange pings… R3#ping 20.1.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.1.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 100/101/108 ms

R2#ping 172.12.34.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.34.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 96/99/100 ms

R2 can now ping R3’s Ethernet0 interface, and R3 can ping R2’s Serial0 interface. This is about as simple as a route redistribution scenario can get, and you saw that it could go wrong easily. That’s why we’re going to spend some serious time here on redistribution theory as well as

looking at examples.

several

hands-on

Speaking of theory, here are those default seed metrics I mentioned… RIP and EIGRP have a seed metric of “infinity”, and you know no routes with a metric of “infinity” are ever going to be placed into a routing table. Both RIP and EIGRP require a default seed metric to be defined during the redistribution process.

OSPF has a default seed metric of 20, as well as defaulting to a route type of E2. There’s always an exception, and the exception here is that BGP routes are given a metric of 1 by OSPF. And as you’ll see, you better be really careful when redistributing BGP into OSPF. Another link-state protocol, ISIS, has a default seed metric of zero, and it does allow routes to be redistributed without a specified seed

metric. (ISIS is not tested on the CCNP ROUTE exam.) OSPF’s default seed metric can be changed in the redistribute command itself. Here, we’ll double the OSPF default seed metric of 20 for EIGRP routes being redistributed into OSPF. R2(config)#router ospf 1 R2(config-router)#redistribute eigrp 100 ?

metric

Metric for redistributed routes OSPF/IS-IS exterior

metrictype

routemap subnets

tag

metric type for redistributed routes Route map reference Consider subnets for redistribution into OSPF Set tag for routes redistributed into OSPF

R2(config-router)#redistribute eigrp 100 metric

? OSPF default metric R2(config-router)#redistribute eigrp 100 metric 40 % Only classful networks will be redistributed R2(config-router)#redistribute eigrp 100 metric 40 subnets

There’s one more reminder to include the subnets option if you want subnets to be redistributed. Call me crazy, but I think that’s an important detail to remember, because the CCNP ROUTE exam won’t remind you of it.

Suboptimal Routing And Routing Loops When route redistribution works well, it’s quite a rush, both in production networks and the exam room. When it doesn’t work well, it can become your worst nightmare. The larger your network, the harder it is to see all the potential issues. You can think you’ve got all the bases covered, and then you put your carefully thought-out route redistribution plan into action -and a problem quickly occurs that

you never saw coming. This is particularly true of two-way route redistribution. Most of the problems you have with redistributed routes fall into two categories -- suboptimal routing (bad) and routing loops (very bad). Suboptimal routing generally occurs because of a miscalculation in coming up with the right seed metric value. The packets will eventually get where they are supposed to go.

Keyword: “eventually”

R2 has two paths to send data to 172.12.34.0/24. The data could follow the path R1-R4-R3, or the more direct R1-R3. Quick aside: Never assume the physically shortest path is

the logically shortest path, whether you’re routing or switching. All values being equal, the best path is the more direct path. If route redistribution metrics are incorrect, R2 could end up using the longer path. Data would still reach the desired destination, but would take longer to arrive and would put an unnecessary strain on R4’s resources. That’s suboptimal routing at its best / worst. A far worse effect of improperly

configured route redistribution is a routing loop. Packets that enter a routing loop will be sent back and forth between the same group of routers over and over. Packets that enter a routing loop will keep looping and will never reach the intended destination. Traceroute is an excellent tool to detect a routing loop. If you see the same IP addresses appearing in the command output over and over, you’ve got a routing loop…. as you’re about to see. This lab’s networks:

Frame Relay: 172.12.123.0 /24 Ethernet: 172.23.23.0 /24 R3 / R4 Link: 172.34.34.0 /24 R4’s Loopback: 4.4.4.4 advertised into OSPF

/32,

We want the routers in the RIP domain to have connectivity to R4’s

loopback - and as always, before beginning to configure redistribution, we’ll check the border router and make sure it has that route to begin with! R3#show ip route ospf 4.0.0.0/32 is subnetted, 1 subnets O 4.4.4.4 [110/65] via 172.34.34.4, 00:00:03, 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 = 36/36/36 ms

The

BR

has

the

route

and

connectivity to that network, so now we’ll config redistribution. This time we’ll use the default-metric command to define RIP’s seed metric. R3(config)#router rip R3(config-router)#redistribute ospf 1 R3(config-router)#redistribute connected R3(config-router)#redistribute static R3(config-router)#default-metric 2

Note that even though we had no static routes that needed redistribution - actually, there were no static routes on R3 - I included the redistribute static command in the config.

More than once I’ve seen admins enter the redistribute connected and redistribute static commands when they weren’t really necessary. You might want to avoid this “blind configuration”, since someone may add a static route to the config later that you don’t want redistributed. Someone who writes an incorrect static route, like this: R3(config)#ip route 4.4.4.4 255.255.255.255 172.12.123.1

That static route to 4.4.4.4 is pointing to R1’s serial interface, not R4’s.

Let’s see the result on R2: R2#show ip route rip 4.0.0.0/32 is subnetted, 1 subnets R 4.4.4.4 [120/2] via 172.23.23.3, 00:00:07, Ethernet0 172.34.0.0/24 is subnetted, 1 subnets R 172.34.34.0 [120/1] via 172.23.23.3, 00:00:07, Ethernet0

No big deal, right? The routes are still there. Let’s ping 4.4.4.4 now: R2#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: …..

We had connectivity a few minutes

ago, and lost it when that static route was redistributed -- and that’s because the result of that redistribution is a routing loop, as shown by traceroute. R2#traceroute 4.4.4.4 Type escape sequence to abort. Tracing the route to 4.4.4.4 1 2 3 4 5 6 7 8 9 10

172.23.23.3 4 msec 4 msec 4 msec 172.12.123.1 36 msec 36 msec 32 msec 172.12.123.2 28 msec 28 msec 28 msec 172.23.23.3 32 msec 24 msec 28 msec 172.12.123.1 60 msec 60 msec 60 msec 172.12.123.2 52 msec 52 msec 52 msec 172.23.23.3 52 msec 52 msec 52 msec 172.12.123.1 84 msec 84 msec 80 msec 172.12.123.2 72 msec 72 msec 72 msec 172.23.23.3 72 msec 72 msec 72 msec

11 msec 12 msec 13 14 msec 15 msec 16 msec 17 msec 18 msec 19 msec 20 msec 21 msec 22 msec

172.12.123.1 104 msec 104 msec 104 172.12.123.2 96 msec 124 msec 92 172.23.23.3 96 msec 96 msec 96 msec 172.12.123.1 128 msec 124 msec 128 172.12.123.2 120 msec 116 msec 120 172.23.23.3 120 msec 120 msec 116 172.12.123.1 148 msec 148 msec 148 172.12.123.2 140 msec 140 msec 144 172.23.23.3 140 msec 140 msec 140 172.12.123.1 172 msec 176 msec 172 172.12.123.2 160 msec 164 msec 160 172.23.23.3 164 msec 164 msec 164

23 msec 24 msec 25 msec 26 msec 27 msec 28 msec 29 msec 30 msec

172.12.123.1 192 msec 196 msec 196 172.12.123.2 184 msec 188 msec 188 172.23.23.3 188 msec 184 msec 184 172.12.123.1 216 msec 220 msec 220 172.12.123.2 212 msec 212 msec 208 172.23.23.3 208 msec 212 msec 212 172.12.123.1 256 msec 240 msec 240 172.12.123.2 232 msec 232 msec 232

Anytime you see the same few (or two) IP addresses in traceroute, you have a routing loop. Basically, here’s what’s happening:

Line 1: R2 pings 4.4.4.4. According to R2’s routing table, the next-hop IP address is 172.23.23.3, and the packet is sent there. Line 2: R3 looks up 4.4.4.4 in its routing table, and as a result of that static route, the next-hop IP is 172.12.123.1 -R1’s serial interface. (The static route went into the routing table since its AD is less than that of the other source for that exact same network, OSPF.)

Line 3: R1 gets the packet, looks in its routing table, and sees the next-hop for 4.4.4.4 is 172.12.123.2 -- R2’s serial interface. At that point, R2 gets the packet back, and the entire process begins again - and we have ourselves a routing loop.

Preventing Routing Loops .. And Fixing Them

There is no “one-size-fits-all” solution for routing loop prevention. The solution you use depends on your network topology, where the routing loop is taking place, and the preexisting configuration. Having said that, we’re going to take a look at some routing loop prevention mechanisms that not only will Cisco expect you to know to become a CCNP, but you should know about each of them in order to use the proper strategy for your particular network.

The first solution is having a solid network design in the first place, which is why it’s more than worth your time to carefully analyze your network topology and identify potential trouble spots. If you’re lucky, you’ll see a network like the one illustrated below where the routing domains’ only interconnection is at the point of redistribution itself. The importance of planning before implementing redistribution cannot be overstated. Examine both the logical and physical topology of

your network, the routing domains, the traffic flows - everything.

This network topology lowers the possibility of routing loops, because the only interconnectivity

between the RIP and OSPF domains is at the point of route redistribution. You need to decide in advance where your protocol border routers are - that is, the routers where both protocols involved in redistribution are configured. Naturally, it’s not always that easy many networks have multiple connectivity points between routing domains for redundancy’s sake. This is a great idea - until you have to configure redistribution. Then you’re going to hate redundancy. (It’s okay, I won’t tell anybody.)

This topology is a dream for network fault tolerance, and a nightmare when it comes to route

redistribution. There are four points at which the two protocols will interact; R1-R2, R1-R3, R2-R3, and R4-R5. R1 is still the best location for redistribution to be configured. What you’d have to concern yourself with here are routes being sent back and forth between the other routers. I’ve worked with both network configurations shown here and the first example is a lot easier to work with, but the second example is more common. You’ve got to be prepared to work with both.

Speaking from personal experience, if you can use one-way route redistribution in situations with multiple boundary routers, you should. Cisco recommends that as well - avoid two-way route redistribution whenever possible. Monitoring Protocol’s Distance

And

Adjusting A Administrative

You know what the AD is and you know the common and not-socommon AD values - and now we’re going to put that knowledge

to use. ADs are used only when there is no “longest match” in the routing table. If a router has two routes to the same destination that have exactly the same prefix length, there’s got to be a tiebreaker, and AD is that tiebreaker. AD is much like split horizon most of the time it does just what you want it to do, but under certain circumstances, you’ve got to make some changes. You can’t disable AD the way you

can disable split horizon, but you can make some (careful) changes in AD values to fine-tune your network after route redistribution.

The RIP domain includes: The 172.12.123.0 /24 frame cloud connecting R1, R2, and R3

The 10.1.1.0 /24 network on R1 The OSPF Area 0 network: The 30.1.1.0 /24 network connecting R2, R3, R4, and R5 The objective: All routers in the OSPF domain have the network 10.1.1.0 /24 network in their tables.

Process: Miniaturization! (Okay, we’ll use route redistribution instead.) As always, our first step is to make sure our border router has the routes to be redistributed: The first step is to make sure R3 sees the RIP route …. R3#show ip route rip

10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:19, Serial0 R2#show ip route rip 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:01, Serial0

R3 sees the route, and we’ll now redistribute that route into the OSPF domain. I put R2’s table there as well, because it’s a very good idea to keep an eye on the other routing tables in your routing domain as well when performing redistribution. R3(config)#router ospf 1

R3(config-router)#redistribute rip subnets R3(config-router)#redistribute connected subnets R3(config-router)#router rip R3(config-router)#redistribute metric 1

connected

R4 now sees both 172.12.123.0 and 10.1.1.0 /24. As we expect, both routes are marked E2 and have a cost of 20, and the next hop for both routes is the IP address of R3’s E0 interface. R5 shows the exact same OSPF routing table: R4#show ip route ospf

172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via 30.1.1.3, 00:00:15, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 30.1.1.3, 00:00:15, Ethernet0 R5#show ip route ospf 172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via 30.1.1.3, 00:02:25, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 30.1.1.3, 00:02:25, Ethernet0

When you have multiple border routers and you’re configuring one of them for redistribution, be sure to watch the others for ill effects of redistribution.

R2’s routing redistribution:

table

before

R2#show ip route rip 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:01, Serial0 R2#show ip route ospf R2# (No OSPF routes to show)

R2’s routing redistribution:

table

R2#show ip route rip R2# (No RIP routes to show) R2#show ip route ospf

after

10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 30.1.1.3, 00:04:14, Ethernet0

We don’t expect 172.12.123.0/24 to show up in R2’s RIP or OSPF routing table, because it’s a directly connected network. However, the route to 10.1.1.0 /24 is now using R3’s Ethernet0 as a next-hop address, and it’s now an OSPF route. Packets from R2 destined for the 10.1.1.0 /24 network will now take a longer path than they would have before redistribution was configured on R3. Previously, such

packets would have gone straight to R1; now, those packets will go to R3, then R1. Hello, suboptimal routing!

Why did R2 choose the longer path? After redistribution is configured on R3, R2 is receiving two routes for the network 10.1.1.0/24. One is

from R1 via RIP; the other is from R3 via OSPF. (The OSPF update is shown with a two-headed arrow to indicate that every router on the broadcast segment will receive the update sent by R3.) The prefix length of /24 is contained with both updates, so there has to be a tiebreaker, and that tiebreaker is AD. OSPF has an AD of 110, where RIP’s is 120, so the OSPF route is chosen. You would have noticed this by looking at the table, but it’s a good idea to check all routes on a border

router that is not performing redistribution - and you can perform that checking with the traceroute command. This command shows you the exact path data is taking to reach the destination, which gives you an idea of whether suboptimal routing has occurred. R2#ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/72 ms

R2#traceroute 10.1.1.1 Type escape sequence to abort. Tracing the route to 10.1.1.1 1 30.1.1.3 8 msec 4 msec 20 msec 2 172.12.123.1 36 msec * 36 msec

Our basic IP connectivity test, ping, shows that we still have connectivity to 10.1.1.0/24. The problem is that this data is taking the long way to get there, with a next-hop of 30.1.1.3. With suboptimal routing, we basically have three different approaches to resolving the issue:

Changing the administrative distance Changing the route’s metrics Filtering routes with distribute-lists (covered in a later section) Let’s apply the first option…. To change the AD of a protocol on a router, use the distance command under the appropriate routing process. We’ll use this command to

change the AD of OSPF on R2 to 200. R2(config)#router ospf 1 R2(config-router)#distance ? Administrative distance ospf OSPF distance R2(config-router)#distance 200 R2#show ip route rip 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:02, Serial0

R2#show ip route ospf < No OSPF routes to show > R2#traceroute 10.1.1.1

Type escape sequence to abort. Tracing the route to 10.1.1.1 1 172.12.123.1 36 msec * 36 msec

The RIP route is now preferred because all OSPF routes on R2 have an AD of 200. The next-hop IP address is now 172.12.123.1, the direct path to 10.1.1.0 /24. If we shut down the RIP-enabled interface on R2, the OSPF routes will be put into the routing table. You can see the OSPF route’s AD has been successfully changed to 200. R2#show ip route ospf

172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [200/20] via 30.1.1.3, 00:00:04, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [200/20] via 30.1.1.3, 00:00:05, Ethernet0

In effect, we turned the OSPF routes into something similar to a floating static route - the higher AD guarantees the OSPF routes will appear in the table only if the RIP routes disappear. You have to be truly careful using any “all-or-nothing” command when it comes to your routing table, and the distance command does just that -it changes the AD of all the

routes acquired by that particular protocol. More likely, you’ll want to change the AD of some routes rather than all of them. To do so, you can write an ACL identifying the routes whose AD you want to affect and tie that ACL in with the distance command. To illustrate, let’s take a routing table from another lab. R2 has three routes in its EIGRP routing table, all with an AD of 90. R2#show ip route eigrp 3.0.0.0/32 is subnetted, 1 subnets

D 3.3.3.3 [90/409600] via 172.12.23.3, 00:00:28, Ethernet0 4.0.0.0/32 is subnetted, 1 subnets D 4.4.4.4 [90/409600] via 172.12.23.3, 00:00:28, Ethernet0 5.0.0.0/32 is subnetted, 1 subnets D 5.5.5.5 [90/409600] via 172.12.23.3, 00:00:28, Ethernet0

Let’s double the AD of the route for 4.4.4.4 while leaving the other routes alone. ACL 5 identifies that route and that route only, and then we just use that ACL number at the end of the distance command. R2(config)#access-list 5 permit 4.4.4.4 0.0.0.0 R2(config)#router eigrp 100 R2(config-router)#distance

180

0.0.0.0

255.255.255.255 ?





WORD

R2(config-router)#distance 255.255.255.255 5

IP Standard access list number IP Standard expanded access list number Standard access-list name 180

0.0.0.0

After clearing the route table, the route to 4.4.4.4 now has an AD of 180, while the other distances

remain the same. R2#show ip route eigrp 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/409600] via 172.12.23.3, 00:00:27, Ethernet0 4.0.0.0/32 is subnetted, 1 subnets D 4.4.4.4 [180/409600] via 172.12.23.3, 00:00:27, Ethernet0 5.0.0.0/32 is subnetted, 1 subnets D 5.5.5.5 [90/409600] via 172.12.23.3, 00:00:27, Ethernet0

Anytime you have two dynamic routing protocols operating in the same network and redistribution is involved, you may find it helpful to fine-tune a route or two in this fashion.

For example, if a network is running OSPF and RIPv2, the OSPF route will always be selected if AD is the determining factor. You may have some RIP routes that are actually optimal, but won’t be used. Now you know how to selectively change the AD of those particular RIP routes. Default-Information (Always?)

Originate

You’ll see the following discussion in the Multi-Area OSPF section as well. Since this command redistributes a default route, I’m

putting it here as well. It’s worth seeing again. You know that default routes are generated in OSPF when stub and total stub areas are involved. You also know that you can’t make Area 0 a stub area. What we can do is run the OSPF command default-information originate with the always option to send a default route to all other OSPF routers -- and that includes routers in Area 0.

The always option allows the router to propagate a default route without actually having one in its routing table. Without that option, the router must have a default route in its table in order to advertise one. If there is no default route to advertise, neighbors will not receive a default route! Here, both R2 and R3 will have the same next-hop address for every remote destination - R1’s serial0 interface, 172.12.123.1.

That fact would simply scream at us to configure this as a stub or total stub area, but there’s just one problem … R1(config)#router ospf 1 R1(config-router)#area 0 stub OSPF: Backbone can not be configured as stub area R1(config-router)#area 0 stub ?

no-summary Do not send summary LSA into stub area R1(config-router)#area 0 stub no-summary OSPF: Backbone can not be configured as stub area

…. all three routers are in Area 0, and we can’t config A0 as any kind of stub. We can use the default-information originate command to send a default route from R1 to the spoke routers. Assuming R1 does not have a default route in its own table, we’ll need to use the always option. Here’s what happens if we don’t:

R1(config-router)#default-information ? originate Distribute a default route R1(config-router)#default-information originate ?

always

metric

metrictype route-

Always advertise default route OSPF default metric OSPF metric type for default routes Route-map

map

reference

R1(config-router)#default-information originate R2#show ip route ospf R2#

Nothing on R2 or R3. We’ll go back to R1, remove the first version of the command, and replace it with the same command and the always option. R1(config-router)#no default-information originate R1(config-router)#default-information originate always

And now to R2 and R3 …. R2#show ip route ospf O*E2 0.0.0.0/0 [110/1] 00:00:10, Serial0

via

172.12.123.1,

R3#show ip route ospf O*E2 0.0.0.0/0 [110/1] 00:00:15, Serial0

via

172.12.123.1,

Both routers have the route, marked as both a candidate default route and an E2 route. Unlike stub areas, this route does not automatically replace any routes already present in the receivers’ route tables. You’ll have to filter those some other way - shortly, we’ll do just that.

ip default-gateway vs. ip defaultnetwork The ip default-network command can be used to inject a default route into your routing process, too. Maybe. If the router has an interface directly connected to the network specified with this command, the router will generate a default route and send that route to its neighbor routers. This command can be a little tricky

to use, and it works differently with different protocols. Here, R1 and R2 are both running RIPv2. When a gateway of last resort is configured using ip default-network on R1, RIP will advertise a default route of 0.0.0.0 to R2. Additionally, RIP does not need to know about the network configured as the default. R1 will name the network 13.0.0.0 /8 as the default network. This route is not being advertised by RIP, but R2 still has the default route. R1(config)#ip default-network 13.0.0.0

R2#show ip route < code table deleted for clarity > Gateway of last resort is 172.12.123.1 to network 0.0.0.0 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0 30.0.0.0/24 is subnetted, 1 subnets C 30.1.1.0 is directly connected, Ethernet0 R* 0.0.0.0/0 [120/1] via 172.12.123.1, 00:00:25, Serial0

In contrast, EIGRP has to know about the default network via either a network command or a static route redistribution.

It’s easy to get ip default-network and ip default-gateway mixed up. They’re both used to generate a default route. The key difference is that ip default-gateway is used when IP routing is off, while ip default-network is used when IP routing is on. And after all the redistribution we’ve done here, redistributing a static route is simple enough - just watch the seed metric requirements of the protocol receiving that route. R1(config)#router rip R1(config-router)#redistribute ?

Border

bgp connected egp

eigrp

igrp

Gateway Protocol (BGP) Connected Exterior Gateway Protocol (EGP) Enhanced Interior Gateway Routing Protocol (EIGRP) Interior Gateway Routing

isis iso-igrp

metric mobile odr

ospf

Protocol (IGRP) ISO IS-IS IGRP for OSI networks Metric for redistribute routes Mobile routes On Demand stub Routes Open Shortest Path First

rip routemap static

(OSPF) Routing Information Protocol (RIP) Route map reference Static routes

R1(config-router)#redistribute static metric 1

EIGRP Redistribution We’ll keep RIP for the protocol

running between R1, R2, and R3. 10.1.1.0 /24 is still advertised by RIP. The protocol running over the ethernet segment is now EIGRP.

EIGRP has a default seed metric of “infinity”, and we need to define a seed metric when we perform the redistribution. With EIGRP, that

means defining settings.

five

different

There are two ways to set the seed metric with EIGRP: Set the metric for the redistributed routes learned from a specific source at the end of the redistribute command. Use the default-metric command to set the default metric for all routes being redistributed.

We’ll use the first method in this example. Note that the redistribute command is incomplete until all five metrics have been defined. Unlike RIP, EIGRP will not allow you to redistribute routes into an AS without specifying the seed metric. Ignore the mention of “IGRP” in IOS Help - that’s just an IOS quirk. R3(config)#router eigrp 100 R3(config-router)#redistribute rip metric ? Bandwidth metric in Kbits per second R3(config-router)#redistribute rip metric 1544 ?

IGRP delay metric, in 10 microsecond units R3(config-router)#redistribute rip metric 1544 10 ? IGRP reliability metric where 255 is 100% reliable R3(config-router)#redistribute rip metric 1544 10 255 ? IGRP Effective bandwidth metric (Loading) where 255 is 100% loaded R3(config-router)#redistribute rip metric 1544 10 255 1 ? IGRP MTU of the path R3(config-router)#redistribute rip metric 1544 10 255 1 1500 R3(config-router)#redistribute connected metric

1544 10 255 1 1500

The values I put in are typical EIGRP redistribution values. For your CCNP ROUTE exam, it’s an excellent idea to have the order of those values down cold. On a production router, you can always use IOS Help to remind you of the order. Let’s check R4 and R5 to see if their EIGRP tables show the redistributed routes. R4#show ip route eigrp 100 172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/1686016] via 30.1.1.3, 00:02:04, Ethernet0

10.0.0.0/24 is subnetted, 1 subnets D EX 10.1.1.0 [170/1686016] via 30.1.1.3, 00:02:04, Ethernet0 R5#show ip route eigrp 172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/1686016] via 30.1.1.3, 00:02:29, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets D EX 10.1.1.0 [170/1686016] via 30.1.1.3, 00:02:29, Ethernet0

The routes have been redistributed successfully into EIGRP. The redistributed route is marked with “D EX”, indicating that it is an EIGRP External route. As seen in the brackets, the AD of these routes is 170 by default, as opposed to the AD of 90 for EIGRP internal routes

and 5 for EIGRP Summary routes. We can also use the default-metric command to set the seed metric. This will set the seed metric for all routes redistributed into EIGRP. R2(config)#router eigrp 100 R2(config-router)#default-metric 1544 10 255 1 1500

Let’s now look at R2’s RIP and EIGRP routing tables, before and after redistribution. Before redistribution: R2#show ip route rip 10.0.0.0/24 is subnetted, 1 subnets

R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:01, Serial0 R2#show ip route eigrp R2# (No EIGRP routes to show)

After redistribution: R2#show ip route rip 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:01, Serial0 R2#show ip route eigrp R2# (No EIGRP routes to show)

The tables on R2 are exactly the same after redistribution.

Why is R2 choosing to put the RIP route into its table rather than the EIGRP route?

R2 is receiving a RIP update containing the route with an AD of 120, where the external EIGRP update coming in on its ethernet

interface has an AD of 170. The lowest AD is preferred, so the RIP route is still considered the best route. If we wanted the EIGRP path to be preferred, we could change its AD on R2. We’ll change the default AD of EIGRP External routes on R2 to 119, just one less than the AD of 120. The command is a little different for EIGRP (like every other EIGRP command, right?) R2(config)#router eigrp 100 R2(config-router)#distance ? Administrative distance eigrp IP-EIGRP distance

R2(config-router)#distance eigrp ? Distance for internal routes R2(config-router)#distance eigrp 90 ? Distance for external routes R2(config-router)#distance eigrp 90 119

Note that when you want to change only one EIGRP AD, you still need to specify the value of each with this command. The result on R2’s routing tables: R2#show ip route rip R2#show ip route eigrp 10.0.0.0/24 is subnetted, 1 subnets D EX 10.1.1.0 [119/1686016] via

30.1.1.3, 00:01:45, Ethernet0

This skill becomes even more valuable when you’re configuring two-way route redistribution, since changing the AD of one of your routing protocols can help prevent routing loops. Verifying Redistribution “Show IP Protocols”

With

When configuring route redistribution or changing default values, you need to run show ip protocols to make sure you are getting the results you thought you’d be getting.

Here is the command output on R3:

You can see that connected routes are being redistributed into RIP, that autosummarization is turned off, version 2 has been hard-coded, and RIP updates are being received from 172.12.123.1.

The rest of the output:

The EIGRP portion of the command from top to bottom shows… The metric weights have not been changed Unequal-cost load balancing is in effect (variance is set to 1)

RIP and connected routes are being redistributed into EIGRP No EIGRP updates are coming in from other routers Default ADs have not been changed Controlling Redistributed Routes Not only can you use the distance command to alter route selection

after redistribution, but you can also control which routers will receive the redistributed routes in the first place. Even better, many of the tools at our disposal are features you’re already familiar with. Certain routing protocols, particularly OSPF, will generate default routes under certain circumstances. They can be helpful in avoiding routing loops, especially if a default route is configured instead of performing two-way redistribution. We’re always trying to avoid two-way redistribution!

If you want each router in this network to be able to reach every other network, a default route could be sent into one routing domain while one-way redistribution is performed with the other. For

instance, a default route could be generated by the ASBR (R1) for R3 and R4 to use. The OSPF routes could then be redistributed into the RIP domain. We could use one of two techniques with OSPF to make this happen, depending on whether we’re dealing with Area 0: If we are, default-information originate (always) would come in handy. If we’re not, making the area a

stub or total stub route would be the direction to go in.

Passive Interfaces Passive interfaces can be a big help in controlling routing updates and or/ routing control traffic, depending on which protocol you’re dealing with: RIP: Passive interfaces do not send routing updates, but will accept them. RIP adjacencies aren’t affected by passive interfaces since RIP doesn’t have adjacencies in the

first place. In the following example, R1’s Ethernet0 interface has been configured as passive. R1’s loopback 10.1.1.1 /24 is advertised into RIP. The R1-R2-R3 network is our usual Frame Relay network, 172.12.123.0 /24.

R1’s config: router rip version 2 passive-interface Ethernet0 network 10.0.0.0 network 30.0.0.0 network 172.12.0.0 no auto-summary

Both R2 and R3 see the loopback and the 30.1.1.0 subnet. R2#show ip route rip 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:15, Serial0 30.0.0.0/24 is subnetted, 1 subnets R 30.1.1.0 [120/1] via 172.12.123.1, 00:00:15, Serial0

R3#show ip route rip 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:21, Serial0 30.0.0.0/24 is subnetted, 1 subnets R 30.1.1.0 [120/1] via 172.12.123.1, 00:00:21, Serial0

R5 does not see R1’s loopback - the passive interface is not sending routing updates to R5. R5#show ip route rip R5#

Let’s add the loopback on R5 to the RIP process and see if R1 sees it: R5(config)#router rip R5(config-router)#network 5.0.0.0

R1#show ip route rip 5.0.0.0/24 is subnetted, 1 subnets R 5.1.1.0 [120/1] via 30.1.1.5, 00:00:14, Ethernet0

R1 does see the route. A RIP passive interface will not send routing updates, but it will accept them. This partial output of debug ip rip proves that R1 is multicasting updates via Serial0, but not E0, and is receiving updates from all other routers in the domain. EIGRP: Hellos aren’t sent, so no adjacency can be formed via a passive interface. If an adjacency exists on an interface that is then

made passive, the adjacency is dropped. A subnet running a passive interface can be advertised. We’ll use the exact same topology from the previous lab in this example and enable EIGRP on the Frame Relay and Ethernet segments.

R1 has adjacencies to all of the

other routers in the AS, R2 and R3 see the 30.1.1.0 /24 network, and R5 sees the 172.12.123.0 /24 network.

What will the impact be when we make e0 passive? Let’s find out!

The first impact is the lost adjacency between R1 and R5. EIGRP passive interfaces do not send Hellos, and we know what happens when that doesn’t happen. As a result, R5 loses the EIGRP route for the Frame Relay network. R5#show ip route eigrp R5#

What about R2 and R3? Will they still see the 30.1.1.0 /24 network?

R2#show ip route eigrp 30.0.0.0/24 is subnetted, 1 subnets D 30.1.1.0 [90/2195456] via 172.12.123.1, 00:08:47, Serial0 R3#show ip route eigrp 30.0.0.0/24 is subnetted, 1 subnets D 30.1.1.0 [90/2195456] via 172.12.123.1, 00:08:52, Serial0

Yes, they do! EIGRP passive interfaces do not send Hellos, but the subnet running on that passive interface can still be advertised via the network command. OSPF: Passive interfaces do not send OSPF Hellos, so no adjacency

can be formed, and existing adjacencies are lost on interfaces that are then configured as passive. Additionally, the subnet running on the passive interface will be advertised as a stub network. We’ll use the same topology as the previous two labs for this example.

R1 has an OSPF neighbor relationship with all other routers in the network:

The other routers see 1 OSPF route. R2#show ip route ospf 30.0.0.0/24 is subnetted, 1 subnets O 30.1.1.0 [110/74] via 172.12.123.1, 00:02:52, Serial0 R3#show ip route ospf 30.0.0.0/24 is subnetted, 1 subnets O 30.1.1.0 [110/74] via 172.12.123.1, 00:02:57, Serial0 R5#show ip route ospf

172.12.0.0/24 is subnetted, 1 subnets O 172.12.123.0 [110/74] via 30.1.1.1, 00:03:02, Ethernet0

Let’s make E0 passive and watch the results. We know what the first result is going to be… R1(config)#router ospf 1 R1(config-router)#passive-int ethernet0 00:40:56: %OSPF-5-ADJCHG: Process 1, Nbr 5.1.1.1 on Ethernet0 from FULL to DOWN, Neighbor Down: Interface down or detached

The R1 - R5 adjacency is lost immediately, and we know R5 lost

its OSPF route as a result. But is the 30.1.1.0 /24 network still advertised into OSPF? R2#show ip route ospf 30.0.0.0/24 is subnetted, 1 subnets O 30.1.1.0 [110/74] via 172.12.123.1, 00:01:47, Serial0 R3#show ip route ospf 30.0.0.0/24 is subnetted, 1 subnets O 30.1.1.0 [110/74] via 172.12.123.1, 00:01:54, Serial0

Yes, it is! Just as with EIGRP, the adjacency through the now passive interface is lost, but the subnet is still advertised via the network command.

You can set all interfaces on a router as passive for a given protocol with the passive-interface default command. R3(config)#router ospf 1 R3(config-router)#passive-interface default

To set the interfaces back to their default, just use the no passiveinterface default command. R3(config-router)#no passive-interface default

Using Distribute-Lists To Control Redistribution Once

you

perform

route

redistribution, you’ll often find that you need to fine-tune the process by allowing some routes to be redistributed while preventing redistribution of other routes. We can do that with distribute-lists. A distribute-list uses an ACL to define the routes to be redistributed -and explicitly or implicitly prohibited from redistribution. Here’s the network for the first example:

R1 is receiving RIP updates from R5 for six networks: R1#show ip route rip 5.0.0.0/24 is subnetted, 1 subnets R 5.1.1.0 [120/1] via 30.1.1.5, 00:00:09, Ethernet0 6.0.0.0/24 is subnetted, 1 subnets R 6.1.1.0 [120/1] via 30.1.1.5, 00:00:09, Ethernet0 7.0.0.0/24 is subnetted, 1 subnets R 7.1.1.0 [120/1] via 30.1.1.5, 00:00:09,

Ethernet0 8.0.0.0/24 is subnetted, 1 subnets R 8.1.1.0 [120/1] via 30.1.1.5, 00:00:09, Ethernet0 9.0.0.0/24 is subnetted, 1 subnets R 9.1.1.0 [120/1] via 30.1.1.5, 00:00:09, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 30.1.1.5, 00:00:09, Ethernet0

If we perform redistribution as we have throughout this section, the OSPF routers would see all of those routes - as shown here. R1(config)#router ospf 1 R1(config-router)#redistribute rip subnets R1(config-router)#redistribute connected subnets

R2#show ip route ospf 5.0.0.0/24 is subnetted, 1 subnets O E2 5.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0 6.0.0.0/24 is subnetted, 1 subnets O E2 6.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0 7.0.0.0/24 is subnetted, 1 subnets O E2 7.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0 8.0.0.0/24 is subnetted, 1 subnets O E2 8.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0 9.0.0.0/24 is subnetted, 1 subnets O E2 9.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0 30.0.0.0/24 is subnetted, 1 subnets O E2 30.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0

R3#show ip route ospf 5.0.0.0/24 is subnetted, 1 subnets O E2 5.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0 6.0.0.0/24 is subnetted, 1 subnets O E2 6.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0 7.0.0.0/24 is subnetted, 1 subnets O E2 7.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0 8.0.0.0/24 is subnetted, 1 subnets O E2 8.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0 9.0.0.0/24 is subnetted, 1 subnets O E2 9.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0 30.0.0.0/24 is subnetted, 1 subnets O E2 30.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0

What if we don’t want those routers to know about the existence of the 8.1.1.0 and 9.1.1.0 networks? We can write an ACL identifying those networks as networks to be denied, and then apply that ACL to the redistribution process via the distribute-list command. R1(config)#access-list 17 deny 8.1.1.0 0.0.0.255 R1(config)#access-list 17 deny 9.1.1.0 0.0.0.255 R1(config)#access-list 17 permit any

Remember when you thought writing an ACL was hard? Now it’s second nature to you. All we need to do is apply the command to the Serial0 interface in the OSPF

config… R1(config-router)#distribute-list 17 out serial0 % Interface not allowed with OUT for OSPF

D’oh! Filtering routes with OSPF is just a little tricky, since we’re not filtering routes per se as we would with RIP or EIGRP. We deal with LSAs in link state protocols, and we can’t start filtering LSAs or our OSPF databases in an area won’t be synched. Let’s try specifying a protocol there instead of an interface.

R1(config-router)#distribute-list 17 out rip

We didn’t get an error message, so let’s check the OSPF tables on R2 and R3… R2#show ip route ospf 5.0.0.0/24 is subnetted, 1 subnets O E2 5.1.1.0 [110/20] via 172.12.123.1, 00:02:04, Serial0 6.0.0.0/24 is subnetted, 1 subnets O E2 6.1.1.0 [110/20] via 172.12.123.1, 00:02:04, Serial0 7.0.0.0/24 is subnetted, 1 subnets O E2 7.1.1.0 [110/20] via 172.12.123.1, 00:02:04, Serial0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 172.12.123.1, 00:02:04, Serial0 30.0.0.0/24 is subnetted, 1 subnets O E2 30.1.1.0 [110/20] via 172.12.123.1,

00:02:04, Serial0 R3#show ip route ospf 5.0.0.0/24 is subnetted, 1 subnets O E2 5.1.1.0 [110/20] via 172.12.123.1, 00:12:17, Serial0 6.0.0.0/24 is subnetted, 1 subnets O E2 6.1.1.0 [110/20] via 172.12.123.1, 00:12:17, Serial0 7.0.0.0/24 is subnetted, 1 subnets O E2 7.1.1.0 [110/20] via 172.12.123.1, 00:12:17, Serial0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 172.12.123.1, 00:12:17, Serial0 30.0.0.0/24 is subnetted, 1 subnets O E2 30.1.1.0 [110/20] via 172.12.123.1, 00:12:17, Serial0

Success!

If I wanted to go one step further and stop those two routes from being put into R1’s routing table, I could have put the distribute-list in the RIP process. R1(config)#router rip R1(config-router)#distribute-list 17 ?

in out

Filter incoming routing updates Filter outgoing routing updates

R1(config-router)#distribute-list 17 in ?

BRI

ISDN Basic Rate Interface

Ethernet Loopback Null Serial

IEEE 802.3 Loopback interface Null interface Serial

R1(config-router)#distribute-list 17 in ethernet0

The resulting RIP table on R1: R1#show ip route rip 5.0.0.0/24 is subnetted, 1 subnets

R 5.1.1.0 [120/1] via 30.1.1.5, 00:00:00, Ethernet0 6.0.0.0/24 is subnetted, 1 subnets R 6.1.1.0 [120/1] via 30.1.1.5, 00:00:00, Ethernet0 7.0.0.0/24 is subnetted, 1 subnets R 7.1.1.0 [120/1] via 30.1.1.5, 00:00:00, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 30.1.1.5, 00:00:00, Ethernet0

Distribute-lists can also be used to filter all routes from being advertised via a certain interface without making that interface passive and losing the adjacency. Let’s use an EIGRP topology that we used earlier in this section, but

we’ll advertise routes from R2 in this lab.

Here are those routes on R1: R1#show ip route eigrp 2.0.0.0/24 is subnetted, 1 subnets D 2.2.2.0 [90/2297856] via 172.12.123.2, 00:00:09, Serial0 22.0.0.0/24 is subnetted, 1 subnets D 22.2.2.0 [90/2297856] via 172.12.123.2, 00:00:04, Serial0

And on R5: R5#show ip route eigrp 2.0.0.0/24 is subnetted, 1 subnets D 2.2.2.0 [90/2323456] via 30.1.1.1, 00:00:15, Ethernet0 172.12.0.0/24 is subnetted, 1 subnets D 172.12.123.0 [90/2195456] via 30.1.1.1, 00:01:29, Ethernet0 22.0.0.0/24 is subnetted, 1 subnets D 22.2.2.0 [90/2323456] via 30.1.1.1, 00:00:10, Ethernet0

What if we don’t want R5 to see any of those routes - but we need to keep the adjacency? That means we can’t make E0 passive, but we can filter all routes coming in from R1. A one-line ACL denies all traffic

explicitly: R1(config)#access-list 25 deny any We apply it to the EIGRP process: R1(config)#router eigrp 100 R1(config-router)#distribute-list 25 ?

in out

Filter incoming routing updates Filter outgoing routing updates

R1(config-router)#distribute-list 25 out ?

BRI

ISDN Basic Rate Interface IEEE

Ethernet Loopback Null Serial bgp connected egp

802.3 Loopback interface Null interface Serial Border Gateway Protocol (BGP) Connected Exterior Gateway Protocol (EGP) Enhanced

eigrp

igrp

ospf

rip

Interior Gateway Routing Protocol (EIGRP) Interior Gateway Routing Protocol (IGRP) Open Shortest Path First (OSPF)

Routing Information Protocol

static

(RIP) Static routes

R1(config-router)#distribute-list 25 out ethernet0

And we go to R5… R5#show ip route eigrp 2.0.0.0/24 is subnetted, 1 subnets D 2.2.2.0 [90/2323456] via 30.1.1.1, 00:11:36, Ethernet0 172.12.0.0/24 is subnetted, 1 subnets D 172.12.123.0 [90/2195456] via 30.1.1.1, 00:12:50, Ethernet0 22.0.0.0/24 is subnetted, 1 subnets D 22.2.2.0 [90/2323456] via 30.1.1.1, 00:11:31, Ethernet0

… and the routes are still there. Been there for over 11 minutes, too. Why? EIGRP only sends routing updates when there’s a change in the network - and a distribute-list being applied is not considered such a change. We need to force a routing update with clear ip route *, after which we’ll check the EIGRP table on R5 immediately. R5#clear ip route * R5#

R5#show ip route eigrp < nothing to show >

R5#

Sometimes a little route clearing is all it takes! You can verify your distribute-list operation with debug ip eigrp… R1#debug ip eigrp IP-EIGRP Route Events debugging is on 02:11:27: %LINK-3-UPDOWN: Interface Serial0, changed state to down 02:11:27: IP-EIGRP: 172.12.123.0/24 - denied by distribute list 02:11:27: IP-EIGRP: Int 172.12.123.0/24 metric 4294967295 - 0 4294967295

02:11:27: IP-EIGRP: 2.2.2.0/24 - denied by distribute list 02:11:27: IP-EIGRP: Int 2.2.2.0/24 metric 4294967295 - 1657856 4294967295 02:11:27: IP-EIGRP: 22.2.2.0/24 - denied by distribute list

… as well as our old buddy show ip protocols. R1#show ip protocols Routing Protocol is “eigrp 100” Outgoing update filter list for all interfaces is not set Redistributed eigrp 100 filtered by 25 Incoming update filter list for all interfaces is not set

We can use the distribute-list command to filter EIGRP routing updates when redistribution is

involved, too. For this lab we’ll use a slightly different topology. R1 - R2 link: 172.12.123.0 / 24 R1 - R3 link: 172.13.13.0 /24 R1 - R5 link: 30.1.1.0 /24

R1 is learning two routes via RIP

from R2. R1#show ip route rip 2.0.0.0/24 is subnetted, 1 subnets R 2.2.2.0 [120/1] via 172.12.123.2, 00:00:52, Serial0 22.0.0.0/24 is subnetted, 1 subnets R 22.2.2.0 [120/1] via 172.12.123.2, 00:00:52, Serial0

After performing redistribution of both RIP and connected routes into EIGRP 100 … R1(config)#router eigrp 100 R1(config-router)#default-metric 1500 10 255 1 1500 R1(config-router)#redistribute connected R1(config-router)#redistribute rip

… both R3 and R5 see the two RIP routes and the 172.12.123.0 /24 network as EIGRP external routes. R5#show ip route eigrp 2.0.0.0/24 is subnetted, 1 subnets D EX 2.2.2.0 [170/1734656] via 30.1.1.1, 00:00:16, Ethernet0 172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/2195456] via 30.1.1.1, 00:00:11, Ethernet0 172.13.0.0/24 is subnetted, 1 subnets D 172.13.13.0 [90/2195456] via 30.1.1.1, 00:06:28, Ethernet0 22.0.0.0/24 is subnetted, 1 subnets D EX 22.2.2.0 [170/1734656] via 30.1.1.1, 00:00:16, Ethernet0 R3#show ip route eigrp 2.0.0.0/24 is subnetted, 1 subnets D EX 2.2.2.0 [170/2221056] via

172.13.13.1, 00:00:31, Serial1 172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/2681856] via 172.13.13.1, 00:00:26, Serial1 22.0.0.0/24 is subnetted, 1 subnets D EX 22.2.2.0 [170/2221056] via 172.13.13.1, 00:00:31, Serial1 30.0.0.0/24 is subnetted, 1 subnets D 30.1.1.0 [90/2195456] via 172.13.13.1, 00:06:25, Serial1

What if we didn’t want R5 to see any of those routes, but for R3 to continue to see all of them? First, write a one-line ACL denying all traffic… R1(config)#access-list 47 deny any

… and apply that in the EIGRP config with the distribute-list command, referencing the interface leading to R5. R1(config)#router eigrp 100 R1(config-router)#distribute-list 47 out ethernet0

The result: R5 has none of the routes…. R5#show ip route eigrp R5#

… and R3 still sees them all. R3#show ip route eigrp 2.0.0.0/24 is subnetted, 1 subnets D EX 2.2.2.0 [170/2221056] via 172.13.13.1, 00:05:56, Serial1

172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/2681856] via 172.13.13.1, 00:05:51, Serial1 22.0.0.0/24 is subnetted, 1 subnets D EX 22.2.2.0 [170/2221056] via 172.13.13.1, 00:05:56, Serial1 30.0.0.0/24 is subnetted, 1 subnets D 30.1.1.0 [90/2195456] via 172.13.13.1, 00:11:50, Serial1

We filtered all of the routes going to R5, but kept the adjacency. But -- and you knew that was coming -- what if we now want to filter a route from reaching R3, but we need to use a different distribute-list? That new requirement brings up

three new questions.. Can we even use more than one distribute-list on the same router? If so, can we use them in the same routing protocol config? If we can, what’s the net effect to all of our routing tables? Let’s find out. The new requirement is that R3 should not see the 30.1.1.0 /24 network, but continue

to see the external routes. We’ll write an ACL identifying the route to be denied… R1(config)#access-list 33 deny 0.0.0.255 R1(config)#access-list 33 permit any

30.1.1.0

…. and write another distribute-list in the EIGRP config,but we will not specify an interface or protocol. R1(config)#router eigrp 100 R1(config-router)#distribute-list 33 ?

in out

Filter incoming routing updates Filter outgoing routing updates

R1(config-router)#distribute-list 33 out ?

BRI Ethernet Null Serial bgp connected egp

ISDN Basic Rate Interface IEEE 802.3 Null interface Serial Border Gateway Protocol (BGP) Connected Exterior Gateway

eigrp

igrp

ospf

Protocol (EGP) Enhanced Interior Gateway Routing Protocol (EIGRP) Interior Gateway Routing Protocol (IGRP) Open Shortest Path First

rip

static

(OSPF) Routing Information Protocol (RIP) Static routes

R1(config-router)#distribute-list 33 out

The routing table on R3: R3#show ip route eigrp 2.0.0.0/24 is subnetted, 1 subnets D EX 2.2.2.0 [170/2221056] via 172.13.13.1, 00:00:17, Serial1

172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/2681856] via 172.13.13.1, 00:00:17, Serial1 22.0.0.0/24 is subnetted, 1 subnets D EX 22.2.2.0 [170/2221056] via 172.13.13.1, 00:00:17, Serial1

The 30.1.1.0 /24 route has been successfully filtered -- but what about the previous distribute-list and its effect on R5’s routing table? R5#show ip route eigrp R5#

The previous distribute-list is still in effect, since it was specifically written to filter route updates leaving e0. “General” distribute-

lists --lists that do not indicate a specific interface -- do not overwrite distribute-lists that specifically mention an interface. Let’s review the current EIGRP config on R1: router eigrp 100 redistribute connected redistribute rip network 30.1.1.0 0.0.0.255 network 172.13.13.0 0.0.0.255 default-metric 1500 10 255 1 1500 distribute-list 47 out Ethernet0 distribute-list 33 out no auto-summary no eigrp log-neighbor-changes

We have a specific distribute-list

and then a general one where an interface was not specified. In this case, the specific distribute-list is applied to the e0 interface, and the general distribute-list will be applied to all other interfaces - and in this lab, that includes S1 leading to R3. Using Route Maps To Change Route Values And Attributes Distribute-lists are a powerful tool in our route redistribution toolbox but sometimes we’ll want to do more than simply permit or deny routes to be advertised and

redistributed. Sometimes we’ll want to set different metrics for different routes, and maybe even change an OSPF external route type or two and we’ll do that with route maps. Let’s take a look at the mechanics of route map operation, and then we’ll apply route maps to our redistribution labs. Route maps are somewhat similar to access-lists. They both come to a basic decision of “permit” or “deny”. Route lists give us

additional power over the data beyond just a simple “transmit” or “don’t transmit”. With route maps, we can actually change route attributes. Here’s an example of how an ACL and a route-map work together we’ll use BGP in the example. R2(config)#access-list 17 permit host 20.1.1.1 R2(config)#route-map ? WORD Route map tag R2(config)#route-map CHANGE_NEXT_HOP ?

Sequence to insert



deny

permit

to/delete from existing route-map entry Route map denies set operations Route map permits set operations

R2(config)#route-map CHANGE_NEXT_HOP permit ? Sequence to insert to/delete from existing route-map entry

R2(config)#route-map CHANGE_NEXT_HOP permit 10 R2(config-route-map)#match ip address 17 R2(config-route-map)#set ip next-hop 10.1.1.1 R2(config-route-map)#set ?

as-path

automatic-tag

comm-list

Prepend string fo BGP AS attribute

Automa comput value set BGP commun list (for deletion BGP

community

dampening

default

extcommunity

interface ip

commun attribute Set BG route fl dampen parame Set defa informa

BGP extende commun attribute Output interfac IP spec informa

level localpreference

metric

metric-type

Where import BGP lo prefere path att Metric for destinat routing protoco

Type of metric f destinat routing protoco BGP or

origin

tag

weight

code

Tag val destinat routing protoco BGP w for rout table

First, we wrote a standard ACL specifying the source IP address 20.1.1.1. (Remember, the only factor that a standard ACL can match is the source IP address.) Then we began writing the routemap. We’ll now take a line-by-line

look at how this route map was written. R2(config)#route-map ? WORD Route map tag

A route map has to be named, and it’s a good idea to give it an intuitive name. Since we’re going to change the next-hop IP address of matching traffic, we’ll call the route map CHANGE_NEXT_HOP. R2(config)#route-map CHANGE_NEXT_HOP ?



deny

permit

from existing route-map entry Route map denies set operations Route map permits set operations

Route map statements can be given a sequence number, and this is a great help when you want to go back to an existing route map and

add statements. You do not have to assign a sequence number, and if you don’t, the first statement you enter will be numbered “10” and each statement after that will have a sequence number that increments by 10 from the previous statement. The indicates that this command could be entered just as it is, without a permit or deny statement. If you do not specify permit or deny, a route map statement will default to “permit”. We’ll use the following topology to demo route maps and how they

work with route redistribution. R1 - R2 Link: 172.12.123.0 /24 R1 - R3 Link: 172.13.13.0 /24 R1 - R5 Link: 30.1.1.0 /24

R2 is advertising three networks 2.2.2.0 /24, 22.2.0.0 /24, and

222.2.0.0 /24. R1 sees them in its RIP routing table: R1#show ip route rip R 222.2.2.0/24 [120/1] via 172.12.123.2, 00:00:16, Serial0 2.0.0.0/24 is subnetted, 1 subnets R 2.2.2.0 [120/1] via 172.12.123.2, 00:00:16, Serial0 22.0.0.0/24 is subnetted, 1 subnets R 22.2.2.0 [120/1] via 172.12.123.2, 00:00:16, Serial0

For this lab, we have the following requirements: 2.2.2.0 -- Double the default seed metric and set the route to OSPF external type 1.

22.2.0.0 - Keep the default seed metric, set the route to OSPF external type 1. 222.2.2.0 -- Do not redistribute this route at all. All future redistributed routes -- allow redistribution with the default seed metric and OSPF route type. That should keep us busy! And the first step, as always -- identify each route or group of routes with an

ACL. R1(config)#access-list 2 permit 2.2.2.0 0.0.0.255 R1(config)# R1(config)#access-list 22 permit 22.2.2.0 0.0.0.255 R1(config)# R1(config)#access-list 44 permit 222.2.2.0

Now we’ll start on the route map. Route maps are named, not numbered, and I again recommend you give yours an intuitive name: R1(config)#route-map RIP2OSPF permit 10 R1(config-route-map)#match ?

as-path

Match B AS path list

community

extcommunity

interface

ip length

Match B commun list Match BGP/V extende commun list Match f hop interfac route IP spec informa Packet length

Match metric o route Match route-ty of route Match t of route

metric

route-type tag R1(config-route-map)#match ip ?

address

next-

Match address of route or match packet Match nexthop

hop

routesource

address of route Match advertising source address of route

R1(config-route-map)#match ip address ?

WORD

IP accesslist number IP accesslist number (expanded range) IP accesslist name

prefixlist

Match entries of prefix-lists

R1(config-route-map)#match ip address 2 ?

WORD

IP accesslist number IP accesslist number (expanded range) IP accesslist name

R1(config-route-map)#match ip address 2

All IP addresses matching ACL 2 will match this route-map clause. Note that you can specify more than one ACL for a single route map clause. What attributes can we set with a route map? R1(config-route-map)#set ?

as-path

automatic-tag

Prepend string fo BGP AS attribute Automa comput value

comm-list

community

dampening

default

extcommunity

set BGP commun list (for deletion BGP commun attribute Set BG route fl dampen parame Set defa informa BGP extende commun attribute

interface ip level localpreference

metric

Output interfac

IP spec informa Where import BGP lo prefere path att Metric for destinat routing protoco Type of metric f

metric-type

origin

tag

weight

destinat routing protoco

BGP or code Tag val destinat routing protoco BGP w for rout table

Plenty of them. Quite a few are BGP-specific, but here we’ll set both the metric and metric type for

this route being redistributed into OSPF. R1(config-route-map)#set metric ?

+/-



Add or subtrac metric Metric value o Bandw in Kbit per sec

R1(config-route-map)#set metric 40 R1(config-route-map)#set metric-type ?

external

IS-IS external

internal

type-1

type-2

metric Use IGP metric as the MED for BGP OSPF external type 1 metric OSPF external type 2 metric

R1(config-route-map)#set metric-type type-1

We can set more than one attribute in a route-map clause. Here we’re doubling the OSPF seed metric of 20 and setting the route type to OSPF E1 from the default of E2. The next clause will match ACL 22 and will leave the seed metric at the default, but will change the OSPF route type to E1. R1(config)#route-map RIP2OSPF permit 20 R1(config-route-map)#match ip add 22 R1(config-route-map)#set metric-type type-1

The third clause will match ACL 44 and will deny the route from being redistributed. Note the deny in the

route-map clause and that no attribute is actually set - since we’re denying it in the first place. R1(config)#route-map RIP2OSPF deny 30 R1(config-route-map)#match ip address 44

That matches all of our three current routes, but we were also asked to allow future routes to be redistributed with the default seed metric and OSPF route type. For that, we’ll write what I call a “catch-all” clause - a clause that matches any route that wasn’t specifically matched earlier. This clause has no match rule, and since

we’re not changing any attributes, it won’t have any set rules either. R1(config)#route-map RIP2OSPF perm 40 R1(config-route-map)#

As you’ve now seen, these can get pretty involved! Let’s take a look at the route-map as a whole with show route-map. R1#show route-map route-map RIP2OSPF, permit, sequence 10 Match clauses: ip address (access-lists): 2 Set clauses: metric 40 metric-type type-1 Policy routing matches: 0 packets, 0 bytes

route-map RIP2OSPF, permit, sequence 20 Match clauses: ip address (access-lists): 22 Set clauses: metric-type type-1 Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, deny, sequence 30 Match clauses: ip address (access-lists): 44 Set clauses: Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, permit, sequence 40 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes

Now after all that, we get to apply it! Let’s see the results of the redistribution without the route-

map. R1(config)#router ospf 1 R1(config-router)#redis rip subnets R3#show ip route ospf O E2 222.2.2.0/24 [110/20] via 172.13.13.1, 00:00:03, Serial1 2.0.0.0/24 is subnetted, 1 subnets O E2 2.2.2.0 [110/20] via 172.13.13.1, 00:00:03, Serial1 172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via 172.13.13.1, 00:00:03, Serial1 22.0.0.0/24 is subnetted, 1 subnets O E2 22.2.2.0 [110/20] via 172.13.13.1, 00:00:03, Serial1 30.0.0.0/24 is subnetted, 1 subnets O 30.1.1.0 [110/74] via 172.13.13.1, 00:00:03, Serial1 R5#show ip route ospf

O E2 222.2.2.0/24 [110/20] via 30.1.1.1, 00:00:15, Ethernet0 2.0.0.0/24 is subnetted, 1 subnets O E2 2.2.2.0 [110/20] via 30.1.1.1, 00:00:15, Ethernet0 172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via 30.1.1.1, 00:00:15, Ethernet0 172.13.0.0/24 is subnetted, 1 subnets O 172.13.13.0 [110/74] via 30.1.1.1, 00:00:15, Ethernet0 22.0.0.0/24 is subnetted, 1 subnets O E2 22.2.2.0 [110/20] via 30.1.1.1, 00:00:15, Ethernet0

Just what we expected. Now let’s remove that redis statement and replace it with one that calls the route-map. We’ll put a “regular” redistribute connected in there,

too. R1(config)#router ospf 1 R1(config-router)#redis rip subnets route-map RIP2OSPF R1(config-router)#redis conne subnets

The result on R3: R3#show ip route ospf 2.0.0.0/24 is subnetted, 1 subnets O E1 2.2.2.0 [110/104] via 172.13.13.1, 00:01:56, Serial1 172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via 172.13.13.1, 00:01:56, Serial1 22.0.0.0/24 is subnetted, 1 subnets O E1 22.2.2.0 [110/84] via 172.13.13.1, 00:01:56, Serial1 30.0.0.0/24 is subnetted, 1 subnets

O 30.1.1.0 [110/74] via 172.13.13.1, 00:01:56, Serial1

Let’s review the route-map on R1 and check the impact on R3: R1#show route-map route-map RIP2OSPF, permit, sequence 10 Match clauses: ip address (access-lists): 2 Set clauses: metric 40 metric-type type-1 Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, permit, sequence 20 Match clauses: ip address (access-lists): 22 Set clauses: metric-type type-1 Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, deny, sequence 30 Match clauses:

ip address (access-lists): 44 Set clauses: Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, permit, sequence 40 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes

Clause 10: 2.2.2.0 had its seed metric doubled and is marked as an E1 route. Since E1 routes reflect the entire path to the destination, the cost is not the doubled seed metric of 40, but 104. Clause 20: 22.2.2.0 did not have its seed metric doubled

and is marked as an E1 route so again the cost is higher than the default seed of 20. Clause 30: 222.2.2.0 does not appear in the routing table at all, having been successfully filtered from redistribution. 172.12.123.0 was redistributed via the redistribute connected command, which did not have a route-map applied, and so we see the usual defaults there - the route is an E2 route and has the default seed

metric of 20. Great stuff! Route maps are a very powerful tool in controlling redistribution and changing attributes when needed - they’re not just for BGP configs. Hey, there’s one more thing we need to test - remember the last requirement? All future redistributed routes -- allow redistribution with the default seed metric and OSPF route type.

Let’s add a RIP route to the network on R2 and see if it’s redistributed into OSPF at R1 with the defaults. The route is created and added to RIP… R2(config)#int loopback 55 R2(config-if)#ip address 55.5.5.5 255.255.255.0 R2(config-if)#router rip R2(config-router)#network 55.0.0.0

…. the route is seen in R1’s RIP routing table… R1#show ip route rip R 222.2.2.0/24 [120/1] via 172.12.123.2, 00:00:02, Serial0 2.0.0.0/24 is subnetted, 1 subnets R 2.2.2.0 [120/1] via 172.12.123.2,

00:00:02, Serial0 55.0.0.0/24 is subnetted, 1 subnets R 55.5.5.0 [120/1] via 172.12.123.2, 00:00:02, Serial0 22.0.0.0/24 is subnetted, 1 subnets R 22.2.2.0 [120/1] via 172.12.123.2, 00:00:02, Serial0

… and it’s seen at R3 with the default seed metrics, having matched clause 40 of the route-map. R3#show ip route ospf 2.0.0.0/24 is subnetted, 1 subnets O E1 2.2.2.0 [110/104] via 172.13.13.1, 00:08:56, Serial1 55.0.0.0/24 is subnetted, 1 subnets O E2 55.5.5.0 [110/20] via 172.13.13.1, 00:00:24, Serial1 172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via

172.13.13.1, 00:08:56, Serial1 22.0.0.0/24 is subnetted, 1 subnets O E1 22.2.2.0 [110/84] via 172.13.13.1, 00:08:56, Serial1 30.0.0.0/24 is subnetted, 1 subnets O 30.1.1.0 [110/74] via 172.13.13.1, 00:08:56, Serial1

Bingo, baby! Clause 20 of the route-map had two set statements - you can also have multiple match statements in a clause. If so, both match statements must match in order for that clause to be, well, a match. I’ve added a clause 50 to this routemap. For this clause to match, the

route would have to match ACL 5 *and* be an OSPF E2 route to have its metric set to the specified value. R1(config)#route-map RIP2OSPF permit 50 R1(config-route-map)#match ip address 5 R1(config-route-map)#match route-type ?

external

internal

external route (BGP, EIGRP and OSPF type 1/2) internal route (including OSPF intra/inter

level-1

level-2

local

nssaexternal

area) IS-IS level-1 route IS-IS level-2 route locally generated route nssaexternal route (OSPF type 1/2)

R1(config-route-map)#match external ?

external

internal

level-1

route-type

external route (BGP, EIGRP and OSPF type 1/2) internal route (including OSPF intra/inter area) IS-IS level-1 route

level-2

local

nssaexternal

type-1

IS-IS level-2 route locally generated route nssaexternal route (OSPF type 1/2) OSPF external type 1 route OSPF external

type-2

type 2 route

R1(config-route-map)#match route-type external type-2 R1(config-route-map)#set metric 100

There’s just one more set value I want to introduce you to… tag protocol

Tag value for destination routing

This innocent little value can help you prevent some big nasty routing loops, especially with 2-way redistribution. You can tag routes

with a numeric value as they’re redistributed, and then prohibit routes with that same value from being “re-redistributed” back into the original routing protocol. Let’s use the previous lab topology for a demo.

Let’s say we’re configuring 2-way

redistribution here, and we want to make absolutely sure that routes redistributed into OSPF cannot be “re-redistributed” back to the RIP domain, and vice versa -- and that includes the possibility of additional border routers being added to our network in the future. We can tag the routes redistributed into OSPF with a value of 10, and deny routes with that same value from being redistributed back into RIP. I’ve removed the previous lab’s configuration and we’ll start by

checking for RIP routes on R1. R1#show ip route rip 2.0.0.0/24 is subnetted, 1 subnets R 2.2.2.0 [120/1] via 172.12.123.2, 00:00:20, Serial0 22.0.0.0/24 is subnetted, 1 subnets R 22.2.2.0 [120/1] via 172.12.123.2, 00:00:20, Serial0

We want to redistribute them into OSPF and tag them with a value of 10. If that’s all we need to do, we don’t need an ACL or any match statements - just this route-map: R1(config)#route-map RIP2OSPF permit 10 R1(config-route-map)#set tag 10

The redistribution config: R1(config)#router ospf 1 R1(config-router)#redistribute rip route-map RIP2OSPF subnets R1(config-router)#redistribute connected % Only classful networks will be redistributed R1(config-router)#redistribute connected subnets

Don’t forget the subnets option. :) Also note that in the RIP redis statement, you can put subnets at the end of the command or immediately after redistribute rip -- it doesn’t matter, just make sure you put it somewhere. The OSPF table on R3:

R3#show ip route ospf 2.0.0.0/24 is subnetted, 1 subnets O E2 2.2.2.0 [110/20] via 172.13.13.1, 00:00:24, Serial1 172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via 172.13.13.1, 00:00:06, Serial1 22.0.0.0/24 is subnetted, 1 subnets O E2 22.2.2.0 [110/20] via 172.13.13.1, 00:00:25, Serial1 30.0.0.0/24 is subnetted, 1 subnets O 30.1.1.0 [110/74] via 172.13.13.1, 00:00:25, Serial1

Three routes are learned via redistribution. You won’t see tag values in the routing table, but you will see them in the extended show ip route command. Let’s run that command for one of the external

routes and for the internal 30.1.1.0 network. R3#show ip route 2.2.2.0 Routing entry for 2.2.2.0/24 Known via “ospf 1”, distance 110, metric 20 Tag 10, type extern 2, forward metric 64 Last update from 172.13.13.1 on Serial1, 00:00:43 ago Routing Descriptor Blocks: * 172.13.13.1, from 172.13.13.1, 00:00:43 ago, via Serial1 Route metric is 20, traffic share count is 1 R3#show ip route 30.1.1.0 Routing entry for 30.1.1.0/24 Known via “ospf 1”, distance 110, metric 74, type intra area Last update from 172.13.13.1 on Serial1, 00:00:52 ago

Routing Descriptor Blocks: * 172.13.13.1, from 172.13.13.1, 00:00:52 ago, via Serial1 Route metric is 74, traffic share count is 1

The external route has a tag of 10, and that tag is present with that route everywhere that route is seen throughout the network. The internal route has no tag since it wasn’t learned via redistribution, and therefore wasn’t subject to tagging by the route map. The following config will prevent any routes with the tag 10 from being redistributed from OSPF back

into RIP, while allowing any untagged routes to be redistributed and tagged with 20. R1(config)#route-map OSPF2RIP deny 10 R1(config-route-map)#match tag 10 R1(config-route-map)#route-map OSPF2RIP perm 20 R1(config-route-map)#set tag 20

Now what if we want to go back to the RIP2OSPF route map and use that tag to prevent routes with that tag of 20 from being advertised back to OSPF? Here’s what that route-map looks like now: R1#show route-map RIP2OSPF route-map RIP2OSPF, permit, sequence 10

Match clauses: Set clauses: tag 10

We need the new clause to have a sequence number of less than 10, since we need the deny clause in front of this clause, which allows all routes and tags them with 10. Here’s how we make that happen, along with verification. R1(config)#route-map RIP2OSPF deny 5 R1(config-route-map)#match tag 20 R1#show route-map RIP2OSPF route-map RIP2OSPF, deny, sequence 5 Match clauses: tag 20 Set clauses:

Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, permit, sequence 10 Match clauses: Set clauses: tag 10 Policy routing matches: 0 packets, 0 bytes

The joy of sequence numbers! If we had the permit clause run first, everything would be permitted and tagged with 10 -- even the routes we’re trying to deny. By putting the deny statement first, we deny the routes that are tagged 20 and then allow all other routes to be redistributed. That’s why I put a “5” in the first line of this new

config - that’s the sequence number. Policy Routing Policy-based routing, generally referred to as “policy routing”, is the use of route maps to determine the path a packet will take to get to its final destination. As you progress through your CCNP studies and go on to the CCIE (or to a Cisco Quality Of Service certification), you’ll find that traffic can be “marked” by policy routing in order to give different levels of service to various classes of traffic.

This is done by marking the traffic and placing the different classes of traffic in different queues in the router, allowing the administrator to give some traffic higher priority for transmission. Some basic policy routing rules: Policy routing doesn’t affect the destination of the packet, but does affect the path that is taken to get there. Policy routing can forward traffic based on the source IP

address or the destination IP address (with the use of an extended ACL). Policy routing can be configured globally or on a per-interface level. Applying policy routing on an interface affects only packets arriving on that interface - in this case, Serial0. R2(config)#int s0 R2(config-if)#ip policy CHANGE_NEXT_HOP

route-map

Applying the policy globally applies the route map to packets generated on the router, not on all packets received on all interfaces. R2(config)#ip local CHANGE_NEXT_HOP

policy

route-map

Verify either - or both! - with show ip policy. R2#show ip policy

Interface local Serial0 And here’s remember….

the

Route map CHANGE_ CHANGE_ big

rule

to

If a packet doesn’t match any of the specific criteria in a route map, or does match a line that has an explicit deny statement, the data is sent to the routing process and will be processed normally. If you don’t want to route packets that don’t match a route-map clause, the set command must used to send those packets to null0 interface. Naturally, this command should be the final command in the route map.

be the set set

There are four possibilities for an incoming packet when route maps are in use. The following example illustrates all of them. R2(config)#access-list 29 permit host 20.1.1.1 R2(config)#access-list 30 permit host 20.2.2.2 R2(config)#access-list 31 permit host 20.3.3.3 R2(config)#access-list 32 permit host 20.4.4.4 R2(config)#route-map EXAMPLE permit 10 R2(config-route-map)#match ip address 29 R2(config-route-map)#set ip next-hop 40.1.1.1 R2(config-route-map)#route-map EXAMPLE deny 20 R2(config-route-map)#match ip address 30

Assuming the route map has been applied to the router’s ethernet0

interface, a packet sourced from 20.1.1.1 would match the first line of the route map and have its nexthop IP address set to 40.1.1.1. A packet sourced from 20.2.2.2 would match the deny statement (sequence number 20). Since there is no action listed, this packet would return to the routing engine to undergo the normal routing procedure. All traffic that did not match these two addresses would also be routed normally - there would be no action taken by the route map.

Perhaps we want to specifically block traffic sourced from 20.3.3.3 or 20.4.4.4. We can use multiple match statements in one single route map, and have packets matching those two addresses sent to the bit bucket - the interface null0. R2(config)#route-map EXAMPLE permit 30 R2(config-route-map)#match ip address 31 R2(config-route-map)#match ip address 32 R2(config-route-map)#set ?

as-path

automatic-tag

Prepend string fo BGP AS attribute Automa comput

comm-list

community

dampening

default

extcommunity

value set BGP commun list (for deletion

BGP commun attribute Set BG route fl dampen parame Set defa informa BGP extende

interface ip level localpreference

metric

commun attribute Output interfac IP spec informa

Where import BGP lo prefere path att Metric for destinat routing protoco

metric-type

origin

tag

weight

Type of metric f destinat routing protoco

BGP or code

Tag val destinat routing protoco BGP w for rout table

R2(config-route-map)#set interface null0

Any traffic matching ACLs 31 or 32 will be sent to null0, resulting in its being discarded by the router. Any traffic that didn’t match any of the route map statements will be returned to the routing engine for normal processing. You can verify your policy-map effectiveness and monitor the number of matches with show access-list. Whew! We use a lot of route maps in our CCNP ROUTE studies, and you’ll use them often in production networks as well - they’re not just

for BGP, it just seems that way! Speaking of that, since we’ve used these maps in different sections of the course, here’s a summary of the various uses: Packet destination set values: Next-hop IP address, including a default next-hop Interfaces that can route packets, including a default interface

IP PREC values (IP Precedence), Don’t Fragment bit value, and IP Type of Service (ToS)

Routing protocol set values: metric metric type tag values

BGP set values:

AS-Path Community Local Preference Weight Bonus Material - Not Covered On DVD, But Good Reading Anyway! “ip default next-hop” vs. “ip nexthop” These are two values that can be set

with a route map that are very similar, and I want to point out to you that while many CCNP candidates think they’re the same thing, they are not. If you set an “ip default next-hop” with a route map, that next-hop will be used ONLY if an explicit path to the destination network is not present in the routing table. An extended ACL must be used here, since a source and destination must be defined. R2(config)#access-list 150 permit 172.1.1.1 210.1.1.0 0.0.0.255

ip host

R2(config)#route-map DEFAULT_NEXT_HOP permit R2(config-route-map)#match ip address 150 R2(config-route-map)#set ip default next-hop 100.1.1.3 R2(config)#interface e0 R2(config-if)#ip policy DEFAULT_NEXT_HOP

route-map

When a packet comes into ethernet0 with a source IP of 172.1.1.1 and is destined for any host on the 210.1.1.0/24 network, the next-hop address will be set to 100.1.1.3 IF there is no entry in the routing table for that network. The Null0 Interface And BGP

Redistribution Null interfaces are seen in the routing table after manual route summarization has been configured, but you can also create a static route with Null0 as the “exit interface”. Configuring Null0 as the exit interface means that matching data will be dropped. You configure such a route just as you would any other static route with a specific exit interface. R2(config)#ip route 172.12.1.0 255.255.255.0 null0

You may be wondering why we’d do that in the first place. The main purpose of a static route to null0 is to allow BGP - IGP route redistribution. BGP route redistribution is a complex subject that you’ll master during your CCIE studies, but here are a couple of basics for you. Instead of redistributing specific routes from an IGP into BGP, you can create this null0 statement and then just redistribute this static route into BGP. Basically, what you’re doing is aggregating the routes before injecting them into

BGP. The null0 statement will not impact your IGP routing, since the morespecific statements in the IGP table will be used before this null0 route due to the longest match rule. Let’s work through an example. You have the IGP routes 150.100.1.0, 150.100.2.0, and 150.100.3.0, all with a /24 mask. You have a need to redistribute these routes into BGP. Instead of redistributing the three individual routes into BGP, you summarize them. The result is

150.100.0.0 /22. You create a route for that network and mask that leads to the null0 interface like this…. R2(config)#ip route 150.100.0.0 255.255.252.0 null0

… and then redistribute that route into BGP. The presence of this null router in your IGP table will not matter, since traffic destined for the 150.100.1.0, 2.0, and 3.0 networks will have a longer match in the table. There’s one more use for such a null route, and that’s to trick BGP into thinking that there is an IGP

route for this destination in the first place. If you faced a situation where you needed to redistribute a network into BGP from your IGP table, and that network didn’t actually exist in your IGP table, you could create a route to null0 with the ip route command and then redistribute it into BGP. Potential Issues Regarding BGP Redistribution We just covered one major issue regarding BGP redistribution, and discussed how to solve that with a static route to null0. There’s another

major factor we have to consider, though, and that is the sheer size of BGP routing tables. A full BGP table can hold well over 100,000 routes. You read that right over 100,000 routes. You should carefully consider this fact before attempting any redistribution involving BGP. A lot of damage can be done very quickly to your network and worldwide internet connectivity as a whole if BGP redistribution is performed incorrectly. There’s

another

problem

with

redistributing routes from an IGP into BGP. If the IGP routes were dynamically learned, they may actually have been learned from BGP in the first place. Putting them back into BGP can quickly lead to a routing loop. “routing instability” doesn’t begin to describe what can happen here.

Here, R1 is redistributing a BGPlearned route into OSPF. That’s fine until R4 advertises it back to R5 because route redistribution has been incorrectly configured. Placing a filter at R4 to prevent it

from possibly advertising that route and prefix to R5 can prevent a routing loop possibility. You also have to be careful when redistributing BGP aggregate routes. If one of the more-specific routes being aggregated goes down, the data is said to have entered a black hole -- that is, the router’s going to discard the data. By the always actually security applied.

way, black holes aren’t a bad thing - they’re an effective network technique when properly (Note the emphasis on

properly applied!) That’s beyond the scope of the CCNP ROUTE exam, but if you enter “routing black hole” into your favorite search engine, you’ll quickly find a few documents on using black holes for network security purposes. Whether BGP is involved or not, you’ve got to be very careful when configuring route redistribution in a network with multiple paths between the routing domains. You can use default routes and static routes to avoid two-way redistribution. If you just can’t

avoid two-way, make sure to use your skills to change administrative distances, default metrics, or some kind of route filtering to prevent loops from occurring. Route filtering becomes very important when working with two-way redistribution. Redistributing External Routes Into BGP

OSPF

Since I’ve warned you about 2000 times not to redistribute anything to and from BGP unless absolutely necessary, I won’t make it 2001.

But should you have to redistribute external OSPF routes, there are some options you need to know about. IOS Help reveals quite a few options for OSPF > BGP redistribution: R1(config)#router bgp 100 R1(config-router)#redistribute ospf 1 ?

metric

Redistribution OSPF routes Metric for redistributed ro

routemap

Route map reference

match

vrf

VPN Routing/Forwa Instance

R1(config-router)#redistribute ospf 1 match ?

external

internal

nssa-

Redistribute OSPF external routes Redistribute OSPF internal routes Redistribute OSPF NSSA

external

external routes

R1(config-router)#redistribute ospf 1 match external ?

1

2

external

Redistribute external type 1 routes Redistribute external type 2 routes Redistribute OSPF external routes

internal

match

metric

nssaexternal routemap

Redistribute OSPF interna routes Redistributio of OSPF routes Metric for redistributed routes Redistribute OSPF NSSA external routes Route map reference

R1(config-router)#redistribute ospf 1 match external 1 ?

external

internal

match

metric

Redistribute OSPF external routes Redistribute OSPF interna routes Redistributio of OSPF routes Metric for redistributed routes Redistribute

nssaexternal routemap

OSPF NSSA external routes Route map reference

R1(config-router)#redistribute ospf 1 match external 1 external 2

OSPF has two external route types, E1 and E2, E2 being the default. If external OSPF routes must be redistributed into BGP, the full command to put both E1 and E2 routes into BGP is shown above.

Changing A Protocol’s Default Metric (Review) Here’s a quick review on using the default-metric command with RIP, EIGRP, and OSPF. RIP’s metric is simple - hop count and so is the command. R2(config)#router rip R2(config-router)#default-metric 2

EIGRP requires five values to be set: R2(config)#router eigrp 100 R2(config-router)#default-metric ? Bandwidth in Kbits per

second R2(config-router)#default-metric 1544 ? Delay metric, in 10 microsecond units R2(config-router)#default-metric 1544 10 ? Reliability metric where 255 is 100% reliable R2(config-router)#default-metric 1544 10 255 ? Effective bandwidth metric (Loading) where 255 is 100% loaded R2(config-router)#default-metric 1544 10 255 1 ? Maximum Transmission Unit metric of the path R2(config-router)#default-metric 1544 10 255 1 1500

OSPF has a default seed metric already set (and you know what that is by now!), and it can be changed as follows: R2(config)#router ospf 1 R2(config-router)#default-metric ? OSPF default metric R2(config-router)#default-metric 25

Recommended Video Viewing From My YouTube Channel: Troubleshooting Redistribution:

Route

http://www.youtube.com/watch?

v=ol1boiYUtEk Video Practice Exam on route redistribution: http://www.youtube.com/watch? v=eY2yyRd0lvM “The Good, The Bad, and The Redistributed” http://www.youtube.com/watch? v=GdJOle54whI Configuring and Troubleshooting

RIP Redistribution: http://www.youtube.com/watch? v=pRtZgfLxlbQ Routing Loops In The Wild: http://www.youtube.com/watch? v=pKimoicJCFQ Free CCNP ROUTE Video Boot Camp on route redistribution: http://bit.ly/Arnhjq

My CCNP ROUTE Video Boot Camp - Exclusive Discount Link For My Ebook Readers Only!

Just click this link for a free hourlong preview AND $10 off the already low price!

http://bit.ly/A7pLBu Available for immediate download and on DVD!

Copyright ©2012 The Bryant Advantage. All Rights Reserved.

Bonus Section: Creating A VLSM Scheme

Working with VLSM isn’t a topic on the CCNP ROUTE exam, and isn’t covered in the Cisco study guides on this topic - but it’s a valuable skill to have. For that reason, I’ve included this section on creating a VLSM scheme. Let’s get started!

Subnetting is simply the process of taking a major network number and dividing that major network number into smaller, more manageable networks. This is done through borrowing host bits. (You never, ever, ever borrow network bits for subnetting.) Subnetting is much like taking a pie and cutting it into slices. For your CCNA studies, the slices were the same size; the stakes will be raised in your CCNP studies and the “network slices” will not be the same size.

These are the major network classes and their network masks:

Class D and E addresses cannot be assigned to public users, so we’re not going to be subnetting those. Also, keep in mind that while it’s common knowledge that the 127.0.0.0 network is reserved for loopback addressing, that means loopback addressing for hosts, not

Cisco router loopback interfaces. If you try to assign an address from the 127.0.0.0 range to a Cisco loopback interface, you’ll get a message informing you that this is not a valid host address. R1(config)#int loopback 100 R1(config-if)#ip address 127.1.1.1 255.0.0.0 Not a valid host address - 127.1.1.1 R1(config-if)#ip address 127.244.244.244 255.0.0.0 Not a valid host address - 127.244.244.244

You also learned that there is another way to express a mask rather than using dotted decimal. You can use prefix notation, where

the number behind the slash is the number of consecutive bits set to “1” in the mask. Therefore, since the mask 255.0.0.0 is equivalent to the binary string 11111111 00000000 00000000 00000000, this mask can also be expressed as /8, or “slash eight”. Determining The Number Of Valid Hosts And Valid Subnets To even start subnetting, you’ve got to know those network classes and network masks. This is the starting point for answering any subnetting

question, whether it’s a Cisco question or a real-world scenario. During your CCNA studies, the subnets were all the same size. You would see a question such as “How many valid hosts exist on the subnet 172.12.12.0 /24?” You would then use this formula to answer the question: Number of valid hosts = (2 to the nth power) - 2, where n = the number of host bits You know this is a Class B network, with a network mask of

255.255.0.0, or /16. You also know that the subnet mask is /24, or 255.255.255.0 in dotted decimal. Placing the two masks next to each other reveals where the subnet bits are:

The bits where the network mask has a 0 and the subnet mask has a 1 are the subnet bits. The bits where both the network mask and subnet mask have a 0 are the host bits. Placing “8” into the formula for “n”, you see the number of valid hosts is (2 to the 8th power) - 2,

which is 254. The formula for determining the number of valid subnets looks similar, but be careful - there are two major differences. Number of valid subnets = (2 to the nth power), where n = the number of subnet bits In this formula, “n” equals the number of subnet bits, not host bits. Also, you no longer subtract 2 to determine the number of valid subnets. Cisco’s formula for their exams used to hold that you should

subtract 2, feeling that the “allzeroes” subnet and the “all-ones” subnet were not valid. The problem was that the use of the “all-zeroes” subnet, more commonly referred to as “subnet zero”, is actually enabled by default on almost all Cisco routers: R1#show config Using 872 out of 32762 bytes ! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption !

hostname “R1” ! ! ip subnet-zero Cisco’s networking theory now holds that both of these subnets are valid, so the “2” is no longer subtracted. Using the previous masks, you can see there are eight subnet bits as well as eight host bits:

Since there are eight subnet bits, the number of valid subnets is 2 to the

8th power, or 256. While this question type proves to Cisco that you understand subnetting theory, it’s not a good real-world situation. This particular subnet mask took the major network number 172.12.0.0 and divided it into 256 valid subnets that each contain 254 valid IP addresses. It’s much more likely that your network will have segments that need a lot of host addresses, and other segments that may require only two. That’s the kind of subnetting CCNPs need to know

how to do, and this is VLSM variable-length subnet masking. You will still be taking a major network number and logically dividing it, but now you will be tailoring the subnetting to your particular network requirements. Of course, if you’re going to use VLSM, you better be using a routing protocol that supports it! RIPv2, OSPF, EIGRP, and BGP all support VLSM. RIPv1 does not. Creating A VLSM Scheme In the following example, we’ll be

using the major network number 150.50.0.0. We have five network segments, each requiring a different number of valid host addresses. In accordance with the change in Cisco’s approach to subnet zero, we will be using that subnet. Network A: 200 host addresses needed Network B: 50 host addresses needed Network C: 25 host addresses needed

Network D: 5 host addresses needed Network E: 2 host addresses needed When you’re designing a VLSM scheme in the real world, you should keep two things in mind. First, design it before you put it into action; putting a VLSM scheme into action requires advance planning to avoid problems after you start putting it into action. Second, keep future growth in mind. You may not want to make your masks too restrictive regarding the number of

valid hosts - what if you need to put 20 more hosts on a subnet a year from now, but you only left yourself 10 valid addresses? You may not have to come up with any full-blown VLSM scheme during the BSCI exam, but as a CCNP, you should certainly be able to. A method that has worked for me and my students all over the world has been to ask yourself this simple question when designing VLSM: “What is the smallest subnet that can be created with all host bits set to zero?”

Network A requires 200 valid host addresses. Using the formula we reviewed earlier in this chapter, we determine that we will need eight host bits (2 to the 8th power equals 256; 256 - 2 equals 254). What is the smallest subnet that can be created with all host bits set to zero?

We use a subnet mask of /24 to have eight host bits remaining, resulting in a subnet and subnet mask of 150.50.0.0 /24, or 150.50.0.0

255.255.0.0. It’s a good idea to keep a running chart of your VLSM scheme, so we’ll start one here. The network number itself is the value of that binary string with all the host bits set to zero; the broadcast address for this subnet is the value of that binary string with all the host bits set to one. These addresses cannot be assigned to hosts; every value between the network number and broadcast address is a valid IP address.

The next subnet will start with the

next number up from the broadcast address. Since 255 is a full octet, the next sequential number after 150.50.0.255 is 150.50.1.0. Now we need to determine the subnet mask for the subnet 150.50.1.0. Network B requires 50 valid host addresses. Using the valid hosts formula, we determine that six host bits are necessary (2 to the 6th power equals 64; 64 minus 2 equals 62). What is the smallest subnet that can be created with all host bits set to zero?

We use a subnet mask of /26 to have six host bits remaining, resulting in a subnet and subnet mask of 150.50.1.0 /26, or 150.50.1.0 255.255.255.192. We’ll add that to our chart. Remember, the network number is the value of that binary string when all host bits are set to zero, and the broadcast address for that subnet is the value with all host bits set to one. Those addresses are not valid host addresses, but every address between them is.

The next subnet is one value up from that broadcast address. In this case, it’s 150.50.1.64. Now we need to determine how many host bits Network C needs. Since we need 25 valid addresses, we need five host bits, which will yield 30 valid host addresses. (2 to the 5th power is 32, subtract the two invalid host addresses and you’ve got 30 left.) That gives us a subnet mask of /27.

The next subnet is one value up from that broadcast address, which makes it 150.50.1.96. Network D needs 5 host addresses, so we have to have at least three subnet bits. (You know the formula by now; what we’d be looking out for in the real world is that there are only 6 valid addresses on this subnet.) We’ll use a subnet mask of /29 to leave three host bits:

If all three host bits are set to zero, the result is 150.50.1.96; that’s the network number. If the host bits are all set to one, the result is 150.50.1.103. Everything in between is a valid IP address.

Finally, Network E needs only two valid host addresses. The next value up is 150.50.1.104, so that

will be the subnet; a mask of /30 leaves us two valid host addresses.

You know the network number is 150.50.1.104, and the broadcast address is 150.50.1.107. There are exactly two valid host addresses on this subnet, 150.50.1.105 and 106. This completes our VLSM scheme.

You don’t need a practice exam to practice this skill - just a few minutes and something to write with. That’s it. And this I guarantee you: those few minutes of extra practice here and there add up big time. -- Chris B.

Copyright © 2012 by The Bryant Advantage. All Rights Reserved.

Bonus Section: How To Develop A VLSM Scheme

Here’s a little more practice with VLSM! Our first drill will involve the major network number 210.49.29.0. We’ve been asked to create a VLSM scheme for the following five networks, and we’ve also been told that there will be no further hosts added to any of these

segments. The requirement is to use no more IP addresses from this range for any subnet that is absolutely necessary. The networks: NW A: 20 hosts NW B: 10 hosts NW C: 7 hosts NW D: 5 hosts NW E: 3 hosts We’ll need to use the formula for

determining how valid host addresses are yielded by a given number of host bits: (2 to the nth power) - 2, with n representing the number of host bits To create our VLSM scheme, we’ll ask this simple question over and over: “What is the smallest subnet that can be created with all host bits set to zero?” NW A requires 20 valid host

addresses. Using the above formula, we determine that we will need 5 host bits (2 to the 5th power equals 32; 32 - 2 = 30). What is the smallest subnet that can be created with all host bits set to zero?

We’ll use a subnet mask of /27 to have five host bits remaining, resulting in a subnet and subnet mask of 210.49.29.0 /27, or 210.49.29.0 255.255.255.224. It’s an excellent idea to keep a running chart of your VLSM

scheme, so we’ll start one here. The network number itself is the value of that binary string with all host bits set to zero; the broadcast address for this subnet is the value of that binary string with all host bits set to one. These two particular addresses cannot be assigned to hosts, but every IP address between the two are valid host IP addresses.

The next subnet will start with the next number up from the broadcast address. In this case, that’s

210.49.29.32. With a need for 10 valid host addresses, what will the subnet mask be?

Four host bits result in 14 valid IP addresses, since 2 to the 4th power is 16 and 16 - 2 = 14. We use a subnet mask of /28 to have four host bits remaining, resulting in a subnet and mask of 210.49.29.32 /28, or 210.49.29.32 255.255.255.240. Remember, the network number is the value of the binary string with all host bits set to zero and the broadcast address is the value of

the binary string with all host bits set to one.

The next subnet is one value up from that broadcast address, which gives us 210.49.29.48. We need seven valid host addresses. How many host bits do we need?

We still need four host bits - three

would give us only six valid IP addresses. (Don’t forget to subtract the two!) The subnet and mask are 210.49.29.48 255.255.255.240, or 210.49.29.48 /28. Calculate the network number and broadcast address as before.

The next value up from that broadcast address is 210.49.29.64. We need five valid IP addresses,

which three host bits will give us (2 to the 3rd power equals 8, 8 - 2 = 6).

The subnet and mask are 210.49.29.64 255.255.255.248, or 210.49.29.64 /29. Calculate the network number and broadcast address as before, and bring the VLSM table up to date.

We’ve got one more subnet to calculate, and that one needs only three valid host addresses. What will the network number and mask be?

We still need a /29 subnet mask, because a /30 mask would yield only two usable addresses. The subnet and mask are 210.49.29.72 /29, or

And now you’re done! The next subnet would be 210.49.29.80, and the mask would of course be determined by the number of host addresses needed on the segment. This particular exercise didn’t ask us to consider any future growth, but some of your exam questions might do so. Just as important, any

VLSM scheme you originate or add to should take future growth of the subnet into account. A more realistic scenario is one such as this: We’re going to work with the major network number 140.10.0.0. There will be four subnets, with a varying number of valid IP addresses needed for each segment. Management has indicated that no subnet will grow by more than 5 hosts per year for the next five years. Develop a VLSM scheme that will accommodate current and

future needs. Network A: 110 hosts Network B: 90 hosts Network C: 65 hosts Network D: 34 hosts If we will need up to five hosts per year for the next five years on each of these subnets, we need to add 25 to the above values. Network A: 135 hosts Network B: 115 hosts

Network C: 90 hosts Network D: 59 hosts Now that we’ve allowed for the network’s future growth, we’re going to follow the exact same procedure as we did for the previous example. That procedure starts with the question… “What is the smallest subnet that can be created with all host bits set to zero?” NW A requires 135 valid host addresses. Using the above formula,

we determine that we will need 8 host bits (2 to the 8th power equals 256; 256 - 2 = 30). What is the smallest subnet that can be created with all host bits set to zero?

We’ll use a subnet mask of /24 to have eight host bits remaining, resulting in a subnet and subnet mask of 140.10.0.0 /24, or 140.10.0.0 255.255.255.0. Calculate the network number and broadcast address, and begin your VLSM table.

The next subnet will start with the next number up from the broadcast address. In this case, that’s 140.10.1.0. With a need for 115 valid host addresses, what will the subnet mask be?

Seven host bits will yield 126 usable host addresses. The resulting network number and broadcast address are shown below, and NW B is added to the VLSM table.

The next subnet will start with the next number up from the broadcast address. In this case, that’s 140.10.1.128. With a need for 90 valid host addresses, what will the subnet mask be?

Again, a /25 mask is needed. This leaves seven host bits, the minimum number required for 90 valid hosts.

The resulting network number and broadcast address are shown below, and NW C is added to the VLSM table.

To finish our VLSM scheme, we’ll use the subnet 140.10.2.0 (one address up from the broadcast address 140.10.1.255). With 59 hosts required, how many host bits will be needed?

Six host bits will give us 62 usable host addresses. You know the drill calculate the network number and broadcast address for this subnet, list the valid host addresses, and update the VLSM table!

I told you learning binary math instead of memorizing charts would

pay off one day! This is just one of the real-world uses of binary math, and no chart memorization is going to help design a VLSM scheme. You either know how to do it or you don’t - and how do you learn how to do it? Practice. You don’t need expensive practice exams - the only thing you need is a piece of paper and a pencil. Just come up with your own scenarios! All you need to do is choose a major network number, then just write down five or six different

requirements for the number of valid host addresses needed for each subnet. it! I can tell you from firsthand experience that this is the best way to get really, really good with VLSM - just pick a network number, write down five or six different requirements for the number of valid addresses needed, and get to work! To your success, Chris Bryant

CCIE #12933 “The Computer Bulldog”

Certification

Copyright © 2012 The Bryant Advantage. All Rights Reserved.