Ccnp Route Guide 6k523r

[email protected]

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

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 (s IP, IPX, and AppleTalk)

s 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 ed 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 Diffudate 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 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 Diffudate 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 istrative 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 - ive, 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 ? <1-128> 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 d 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 <<<< BEWARE!

Load Sharing And maximum-paths command

:)

The

You’ve probably noticed that we didn’t have to enter any commands to perform equal-cost load balancing with EIGRP. EIGRP will enter four equal-cost routes to the same destination into the routing table by default, and this value can be changed with the maximumpaths command to a minimum of

one and a maximum of 16. R1(config)#router eigrp 100 R1(config-router)#maximum-paths ? <1-16> Number of paths

Setting maximum-paths disables load balancing. DUAL Queries And “ive” Is A Good Thing

to

1

Why

EIGRP uses the Diffudate Algorithm (DUAL) to calculate routes, and there’s one other important role DUAL plays in an EIGRP deployment.

If a Successor route is lost and there is no Feasible Successor, we’ve got a problem! DUAL doesn’t give up easily, though. DUAL will mark the route as Active, indicating that the route is being calculated and cannot be used to route data, and will send out a Query message to all of that router’s EIGRP neighbors. A DUAL Query is basically one neighbor asking another, “Hey, do you know how to get to this network I just lost my route to?” If that neighbor has a route, the query will

be answered with that route. If the neighbor doesn’t have such a route, that neighbor will ask its neighbors. The process continues until a downstream router replies with the desired route, or the EIGRP downstream routers run out of neighbors to ask. Routes in the EIGRP Topology table marked as Active are considered unusable, since Active indicates that the route is currently being calculated by DUAL. Hopefully the route comes out of Active very quickly and becomes ive, as

indicated by the “P” in the following Topology table. When it comes to EIGRP routes, ive is good and Active is bad! R1#show ip eigrp topology IP-EIGRP Topology Table for AS(100)/ID(1.1.1.1) Codes: P - ive, 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

Back To Index Recommended Video Viewing: EIGRP Tables and Commands: http://www.youtube.com/watch? v=ZndBgShoxl4 Advanced EIGRP Concepts: http://www.youtube.com/watch? v=LPuXmiKznEI Video Practice Exam on Route Redistribution:

http://www.youtube.com/watch? v=eY2yyRd0lvM The Mystery Of The AD 5: http://www.youtube.com/watch? v=X9AzQCt7rCM Free CCNP ROUTE Video Boot Camp on route redistribution: http://bit.ly/Arnhjq Enjoy! -- Chris B.


Intermediate And Advanced EIGRP Concepts And Configuration

EIGRP Fundamentals Let’s take a few minutes to review EIGRP fundamentals and add to those mentioned in the Basic EIGRP section. EIGRP is a Cisco-proprietary protocol that improves greatly on the original version of this protocol,

the Interior Gateway Routing Protocol (IGRP). (The “E” in EIGRP stands for enhanced.) The benefits include:

of using EIGRP

for Appletalk, IP, and IPX (Novell Netware) via protocol-dependent modules (PDMs) for variable-length subnet masking (VLSM) Dynamic neighbor discovery

via packets multicast to 224.0.0.10 Fast convergence after network topology changes backup routes are actually calculated and placed into a table in advance of their actually being needed. (Note: This table is NOT the IP routing table.) Where RIP sends routing updates every 30 seconds, even if nothing has changed,

EIGRP will send routing updates only when a network topology change actually occurs. EIGRP updates do not contain the entire routing table, but reflect only the routes that have been changed. The scope of these updates is limited to the routers that actually need them - they’re not flooded.

Those last two points might not sound like much, but everything we do on a Cisco router has a cost in U and time. If your routing table has 105 routes and only 1 has changed, why take the time to create an update for every single route when an update reflecting only the change will serve our purpose? EIGRP’s routing algorithm is the Diffudate Algorithm (DUAL). DUAL not only calculates routes that ensure a loop-free network, but also calculates backup routes before they’re needed.

These backup routes, the feasible successors, are kept in the EIGRP topology table. The primary routes, the successors, are kept in both the EIGRP topology and route tables. EIGRP’s third table is the neighbor table, which contains just what you would think it does - information about EIGRP neighbors. EIGRP is a classless routing protocol, which means it s Variable Length Subnet Masking (VLSM). EIGRP routing update packets contain a prefix length for each individual network, making VLSM possible.

EIGRP uses metric weights to determine how important certain values are in route calculation. By default, bandwidth and delay are the only metric values used in route calculation. The other metric weights, or “k-weights”, are load, reliability, and MTU. You can change the bandwidth and delay values to alter EIGRP path selection. If you’re changing any EIGRP values to fine-tune your routing table, I’d go with bandwidth as it’s simply easier to get the desired results.

The bandwidth command is entered in kbps and should be set to the minimum bandwidth of the path. The delay command is configured in tens of microseconds. As you’d guess, the bandwidth command is easier to use for fine-tuning routes. R1(config)#int s0 R1(config-if)#bandwidth ? <1-10000000> Bandwidth in kilobits R1(config-if)#bandwidth 64 R1(config-if)#delay ? <1-16777215> Throughput delay (tens of microseconds)

Since DUAL actually calculates

backup routes before they’re even needed, EIGRP responds to topology changes faster than RIP (which isn’t saying much) and OSPF (which is saying a lot). With EIGRP, routing loops have literally no time to form. EIGRP will perform equal-cost load-sharing over four paths by default, with a maximum of 16 paths. That value is configurable with the maximum-paths command. R1(config)#router eigrp 100 R1(config-router)#maximum-paths ? <1-16> Number of paths

We can also perform unequal-cost load balancing with EIGRP, and we’ll practice that skill later in this section. Almost all EIGRP packets are multicast to 224.0.0.10, and use IP protocol number 88. Let’s take a look at the different EIGRP packet types… and see if we can spot that exception to the multicast rule. EIGRP Packet Types And RTP EIGRP uses the Reliable Transport Protocol (RTP) to handle the guaranteed and reliable delivery of

EIGRP packets to neighbors. “Guaranteed and reliable” sounds a lot like T, but the two are quite different in how they operate. Not all EIGRP packets are going to be sent reliably. Hello packets are used for neighbor discovery and to keep existing neighbor relationships alive; these are multicast to 224.0.0.10. Acknowledgement packets themselves are simply hello packets that contain no data.

Neither Acks nor Hellos use RTP, and are therefore considered unreliable. Update packets are sent to new neighbors to allow the neighbor to build an accurate routing and topology table, and are also sent when a change in the network occurs. Update packets are generally multicast packets, but there’s one important exception that you’ll read about later in this section.

Query packets are sent when a router loses a successor route and has no feasible successor. Reply packets are sent in response to query packets, and a reply packet indicates that a new route to the destination has been found. Update, query, and reply packets all use RTP and are considered reliable.

To see how many of these packets have ed through a router, run show ip eigrp traffic.

R1#show ip eigrp traffic IP-EIGRP Traffic Statistics for process 100 Hellos sent/received: 2/2 Updates sent/received: 13/4 Queries sent/received: 0/0 Replies sent/received: 0/0 Acks sent/received: 0/2 Input queue high water mark 1, 0 drops SIA-Queries sent/received: 0/0 SIA-Replies sent/received: 0/0

To review: Hello and ACK packets are unreliable. Reply, Query, and Update packets are reliable. That’s a handy troubleshooting command, too. If the Query, Reply, and Update values remain the same over a period of time, your network is stable.

If they’re constantly incrementing, there’s a problem. The Query and Reply values will increment only if a successor route is lost. If you see those incrementing regularly, you have yourself a flapping link (believe me, I’ve been there). If the SIA values are incrementing along with them, that’s not good - more on that later in this part of the course.

How EIGRP Routers Become Neighbors EIGRP

routers

form

neighbor

relationships, and after the initial exchange of routing updates between neighbors, EIGRP routers will then only send routing updates when there is a change in the network topology. These neighbor relationships, or adjacencies, begin when a router first has EIGRP enabled on some or all of its interfaces with the router eigrp command. In the following example, R1 is running EIGRP on a Serial interface. R1 will multicast an EIGRP Hello packet to 224.0.0.10 out that interface in an attempt to

find potential neighbors.

A downstream router, R2, receives this Hello. If certain values are agreed upon between the two, R2 will respond with an EIGRP Update packet, which contains all the EIGRP-derived routes that R2 knows.

Did you notice that the EIGRP Update packet going back to R1 was a unicast? Generally, EIGRP Update packets are multicast to 224.0.0.10, just as EIGRP Hello packets are. There’s almost always an exception in networking, and that’s true here as well. Update packets are unicast in this particular situation, but

otherwise they’re multicast. R1 will send an EIGRP Acknowledgement packet, or ack, to let R2 know the routes in the Update packet were received. R1 will also send an Update packet of its own, unicast to R2, containing all EIGRP routes R1 has. R2 will respond with an ack of its own.

Other EIGRP Adjacency Issues (And Non-Issues) Unlike OSPF, EIGRP does not require neighbors to agree on hello and dead times. The EIGRP hold time has the same function as OSPF dead time - they’re both the duration of time in which a hello must be received in order to retain the neighbor relationship. The default EIGRP hold time is three times the hello time. In the following example, an adjacency has been formed between R2 and R3 using the default values

for hello and hold times as well as the metric weights. The router eigrp command indicates that both routers are in EIGRP Autonomous System (AS) 100. The AS is a logical group of EIGRP-speaking routers, and this value must match between potential neighbors. Routers must agree on the EIGRP AS number in order to become neighbors, and the interfaces through which the adjacency is to form must be on the same IP subnet. In the following example, both routers will be placed into EIGRP 100 via the following interfaces:

R2: Ethernet0, 172.12.23.2 /24 R3: Ethernet0, 172.12.23.3 /24 R2(config)#router eigrp 100 R2(config-router)#no auto-summary R2(config-router)#network 172.12.23.0 0.0.0.255 R3(config)#router eigrp 100 R3(config-router)#no auto-summary R3(config-router)#network 172.12.23.0 0.0.0.255

show ip eigrp neighbor verifies that R3 is a neighbor of R2.

Let’s change the hello timers on R2’s Ethernet 0 interface and see what happens to the adjacency. I’ve disabled EIGRP event logging for the following example.

Note the uptime of 12 seconds. That indicates that the EIGRP adjacency did drop, but it came right back up. The mismatched Hello timers didn’t prevent the adjacency from forming again, but what about a change in

the metric weights? R2(config)#router eigrp 100 R2(config-router)#metric weights ? <0-8> Type Of Service (Only TOS 0 ed) R2(config-router)#metric weights 0 1 1 1 1 1 R2#show ip eigrp neighbor IP-EIGRP neighbors for process 100 R2#

show ip eigrp neighbor shows us nothing because there’s no neighbor to show! We can wait a long, long time for that adjacency to come back, but it’s not going to. Potential EIGRP neighbors must agree on the

AS number and all metric weight settings in order to become neighbors. A great command to begin troubleshooting adjacencies with is debug eigrp packets, and if there’s a metric weights mismatch, you’ll see the following: R2#debug eigrp packets EIGRP Packets debugging is on (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY) R2# 01:10:00: EIGRP: Received HELLO on Ethernet0 nbr 172.23.23.3 01:10:00: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 01:10:00: K-value mismatch

The K-value mismatch message indicates a problem with the metric weight setting. In short, EIGRP neighbors must…. … reside in the same EIGRP AS … be on the same subnet … have matching metric weights A quick note on that ip hello eigrp command - unlike OSPF, changing the EIGRP hello time does not

dynamically change the hold time (dead time). EIGRP Hello Packets Hello packets find potential neighbors and also keep neighbor relationships alive. On a high-speed link, EIGRP Hello packets are sent every 5 seconds; on slower links, Hellos are sent every 60 seconds. High-speed links include broadcast technologies such as Ethernet, FDDI, and our old friend Token Ring; high bandwidth (over T1 speed) multipoint circuits, including

ISDN Primary Rate Interface and Frame Relay; both Frame Relay and ATM point-to-point subinterfaces; and finally, point-to-point serial links, such as PPP and HDLC circuits. After that list, you might think there aren’t any interface types left, but there are! Low-speed links include multipoint circuits running at less than T1 speed, such as ATM switched virtual circuits and multipoint interfaces, Frame Relay multipoint interfaces, and ISDN Basic Rate

Interface. An EIGRP neighbor relationship is declared dead when three hello packets are missed, meaning the EIGRP dead time on an ethernet segment is 15 seconds and 180 seconds on an NBMA interface such as a Serial interface. If you change the hello transmission time, Cisco recommends you change the hold time as well to keep it to three times the hello value. To EIGRP neighbor relationships, run show ip eigrp neighbors.

From left to right, let’s examine the meaning of these categories: IP-EIGRP neighbors for process 100 - The AS these neighbors are contained in. H - The order in which the neighbors were discovered. Address - The IP address of the neighbor. Interface - The interface upon which the router is receiving hellos.

Hold - Short for holdtime, the number of seconds the router will wait until it declares this particular adjacency dead. Uptime - The amount of time since this neighbor was first heard from. SRTT - Smooth Round-Trip Time. This is the number of milliseconds it takes for an EIGRP packet to be sent to that neighbor and the amount of time it takes to get an ACK from that neighbor. RTO - Retransmission TimeOut. The amount of time the software

will wait until it retransmits a packet to a neighbor. Q Cnt - Queue Count. The number of EIGRP packets waiting to be sent. Seq Num - Sequence Number. This is the sequence number of the last update, reply, or query packet that was received from this particular neighbor. To debug EIGRP adjacencies, you’ve got two options. You can run debug eigrp neighbors, or debug ip eigrp neighbor

ADDRESS>. Personally, I use debug eigrp neighbors first, and if I don’t get the information I need, I’ll use debug ip eigrp neighbor. The output of debug eigrp neighbors looks like this during an adjacency: 6d00h: EIGRP: Neighbor(172.12.123.3) not yet found 6d00h: EIGRP: Neighbor(172.12.123.2) not yet found 6d00h: found 6d00h: found 6d00h: found 6d00h:

EIGRP: Neighbor(172.12.123.3) not yet EIGRP: Neighbor(172.12.123.2) not yet EIGRP: Neighbor(172.12.123.3) not yet EIGRP: Neighbor(172.12.123.2) not yet

found 6d00h: EIGRP: New peer 172.12.123.2 6d00h: EIGRP: New peer 172.12.123.3

EIGRP Adjacencies Secondary Addresses

And

Technically, EIGRP will not form adjacencies using secondary addresses. Even though it looks like it will. Let’s take a look at R2 and R3, which will be using secondary addresses to form an EIGRP adjacency over an ethernet segment.

R2(config)#interface ethernet0 R2(config-if)#ip address 255.255.255.0 R2(config-if)#ip address 255.255.255.0 secondary

172.12.23.2 23.23.23.2

R2(config)#router eigrp 100 R2(config-router)#no auto-summary R2(config-router)#network 23.23.23.0 0.0.0.255

R3(config)#interface ethernet0 R3(config-if)#ip address 255.255.255.0 R3(config-if)#ip address 255.255.255.0 secondary

172.12.23.3 23.23.23.3

R3(config)#router eigrp 100 R3(config-router)#no auto-summary R3(config-router)#network 23.23.23.0 0.0.0.255

Here’s the partial output of show ip eigrp neighbor on R3: R3#show ip eigrp neighbor IP-EIGRP neighbors for process 100 H Address Interface 0

172.12.23.2

Et0

The adjacency has formed! However, the secondary addresses were not used to form the adjacency. Note the address is actually the primary IP address on the interface, even though we used the secondary network number in the EIGRP network command.

How EIGRP Routers Determine Successors And Feasible Successors Once the EIGRP neighbor relationships form, DUAL will begin sending a series of queries and responses, and these responses are used to build the EIGRP topology table. These queries and responses are sent by the Reliable Transport Protocol (RTP). As mentioned earlier, show ip eigrp traffic will display the number of queries and replies that have been sent and

received. R1#show ip eigrp traffic IP-EIGRP Traffic Statistics for process 100 Hellos sent/received: 110457/115367 Updates sent/received: 43/17 Queries sent/received: 4/0 Replies sent/received: 0/4 Acks sent/received: 14/21 Input queue high water mark 2, 0 drops SIA-Queries sent/received: 0/0 SIA-Replies sent/received: 0/0

Let’s take a look at a typical EIGRP topology table. R1#show ip eigrp topology IP-EIGRP Topology AS(100)/ID(11.1.1.1)

Table

for

Codes: P - ive, A - Active, U - Update, Q Query, R - Reply, r - reply Status, s - sia Status P 1.1.1.1/32, 1 successors, FD is 128256 via Connected, Loopback0 P 2.0.0.0/8, 1 successors, FD is 2297856 via 172.12.123.2 (2297856/128256), Serial0 via 172.12.123.3 (2323456/409600), Serial0 P 3.0.0.0/8, 1 successors, FD is 2297856 via 172.12.123.3 (2297856/128256), Serial0 via 172.12.123.2 (2323456/409600), Serial0 P 172.23.0.0/16, 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

EIGRP will keep up to six valid routes for any given destination. Those six routes don’t have to be made up of one successor and five feasible successors, either - when equal-cost load sharing is in effect as it is for the 172.23.0.0 /16 route in the above topology table, there will be multiple successor routes. “SIA” -- Stuck In Active Regarding those codes, notice that all the routes in this table have a

“P” next to them, indicating that these routes are ive. Another code shown is “A”, for Active. While an “active route” sounds like a good thing, we want to avoid them in EIGRP. If a route shows as Active in the EIGRP topology table, that means the successor for that route has been lost and that no feasible successor was immediately available in the topology table. When a route is ive, that means it’s not being recalculated and it’s a usable route.

Generally, an Active route will be that way for a very short time; by the time you repeat show ip eigrp topology, it’s likely that Active route has gone ive. That cutover from Active to ive is so fast that you can work with EIGRP for a long time without even seeing an Active route. Sometimes that cutover doesn’t happen at all, and the route becomes SIA - Stuck In Active. SIA routes begin innocently enough. When an EIGRP router loses a Successor route, it looks in its

topology table for a Feasible Successor. If there is no Feasible Successor, that router will send DUAL Query packets to its neighbors, asking them if they have a valid route to the nowunreachable destination.

If the router receiving the query doesn’t have a valid, loop-free route to the destination in question,

that router will in turn ask all of its neighbors for such a route - and they’ll ask two friends, and they’ll ask two friends, until a route is discovered or it’s determined that no queried router has a route. That default time is three minutes and can be changed with the timers active-time command in your EIGRP configuration. R1(config)#router eigrp 100 R1(config-router)#timers ? active-time EIGRP time limit for active state R1(config-router)#timers active-time ? <1-4294967295> EIGRP active-state time limit in minutes

disabled limit for active state

disable EIGRP time

R1(config-router)#timers active-time 5

Two things to note in this command: IOS Help shows us the numeric value is minutes. Always use IOS Help to the value of any time-based or unit-based (MB, GB, etc) command. With many Cisco commands, setting a numeric value to zero disables that particular feature

- but you can’t set this one to zero. To disable the time limit, use the disabled option. If R8 doesn’t answer that query within the timers active-time value, the route is Stuck In Active - SIA. From experience, I can tell you that troubleshooting SIA routes is more of an art form than a science, but there are four main reasons a route becomes SIA: The link is unidirectional, so the query can’t possibly be

answered. The queried router’s resources are unavailable, generally due to high U utilization. The queried router’s memory is corrupt or otherwise unable to allow the router to answer the query. The link between the two routers is of low quality, allowing just enough packets through to keep the neighbor

relationship intact, but not good enough to allow the replies through. To sum it up, routes generally become SIA when a neighbor either doesn’t answer a query, or either the query or reply took a wrong turn somewhere. Glad I could narrow that down for you. : ) In real-world networking, resolving SIA routes is much more of an art form than a science. A little

Googling will show you just what I mean. In my experience, the most common real-world causes of SIA are problems with the neighboring router - either that it’s just too busy to answer and it has no U to spare, or that it doesn’t have the memory to handle the query in the first place. What SIA Routes Look Like If you have eigrp log-neighborchanges running, the message you get to indicate a route is SIA looks

like this: Route 100.1.4.0/24 stuck-in-active state in IPEIGRP-100

With the same log command running, a neighbor that does not respond to a query will result in this log entry: neighbor 90.1.1.1 (Serial0) is down: stuck in active

Another method of spotting SIA issues is in the EIGRP topology table. If you see a lower-case “r” next to an IP address where the Active route is shown, that means a

query packet has been sent to that IP address and it has not yet been answered. This code is shown at the top of the EIGRP topology table. Codes: P - ive, A - Active, U - Update, Q Query, R - Reply, r - reply Status, s - sia Status

The Variance Command And Unequal-Cost Load Sharing Often, we’ll have two or more quality paths that we want EIGRP to use. If the metrics aren’t exactly the same, by default EIGRP will use only the successor, as shown here:

R1#show ip eigrp topology IP-EIGRP Topology AS(100)/ID(11.1.1.1)

Table

for

P 3.0.0.0/8, 1 successors, FD is 2297856 via 172.12.123.3 (2297856/128256), Serial0 via 172.12.123.2 (2323456/409600), Serial0 R1#show ip route eigrp 100 D 3.0.0.0/8 [90/2297856] via 172.12.123.3, 01:16:16, Serial0

We have two options for using that second path, which has been marked as a feasible successor by EIGRP. One is practical, and the

other, well, isn’t. We could try to change the metric to exactly 2297856, but this is almost impossible. Take a look at the formula EIGRP uses to calculate routes: EIGRP metric calculation: [(10*6 / smallest BW in kbps) + delay] * 256 This would be the impractical method. The best way to handle this situation is to use unequal-cost

load balancing via the variance command. Using the variance command is easy; it’s coming up with the value of this command that causes a little confusion. With practice, you’ll find this to be easy points on the ROUTE exam. We just need the answer to this question: ‘What is the smallest number, when multiplied by the metric of the successor, that is greater than the metric of the feasible successor?”

To put it a little more formally….what is “x” in the following? (x * [successor metric]) > feasible successor metric I know some of you are looking at that last paragraph and that formula and thinking, “This is the practical method?” It really is, and you’ll see that in just a moment. This is one of those concepts that looks ridiculously complicated in theory but is simple in execution.

Let’s use the same table we looked at earlier for an example. Question: What is the smallest number, multiplied by 2297856, that is greater than 2323456? Answer: Two. Easy! By using the variance 2 command, any route with a metric less than (2 * 2297856) will be placed into the routing table.

This doesn’t make the route with the higher metric a successor, but the route is placed into the routing table and will be used for unequal-cost load-balancing. R1#conf t R1(config)#router eigrp 100 R1(config-router)#variance 2 R1#show ip eigrp topology IP-EIGRP Topology AS(100)/ID(11.1.1.1)

Table

for

P 3.0.0.0/8, 1 successors, FD is 2297856 (There is still just one successor….) via 172.12.123.3 (2297856/128256), Serial0 via 172.12.123.2 (2323456/409600), Serial0

R1#show ip route eigrp 100 D 3.0.0.0/8 [90/2297856] via 172.12.123.3, 00:01:52, Serial0 [90/2323456] via 172.12.123.2, 00:01:53, Serial0 (… but now there are two routes in use to reach this network.)

When unequal-cost load balancing is in effect, the load each link carries is proportional to their metric. If one path’s metric indicates that it is twice as good as another, that path will carry roughly twice as much data. If you want only the best path(s) to

carry the traffic, use the trafficshare command with the min option. The default is balanced. R1(config)#router eigrp 100 R1(config-router)#traffic-share ? balanced Share inversely proportional to metric min All traffic shared among min metric paths R1(config-router)#traffic-share min ? across-interfaces Use different interfaces for equal-cost paths R1(config-router)#traffic-share min acrossinterfaces ? R1(config-router)#traffic-share min acrossinterfaces

Now I know what some of you are thinking….

“Why don’t I just put variance 25 in there or something like that, and then I’ll be using all of my available paths!” Good question. Here’s a good answer. Let’s say we have three valid paths to the same network with the following metrics: Path 1: 5000 Path 2: 7000

Path 3: 55000 Sounds like we have two pretty fast links and one sloooow one. Do you really want to load balance over that third path? Probably not. It’s better than having no third link at all, but I wouldn’t include it in load balancing. variance is an “all-or-nothing” command -- you can’t apply it to just a selected route in the topology table. In my experience, it’s a good idea to keep the variance command at the lowest value possible to avoid load balancing over paths

that may be loop free but aren’t exactly optimal. And note the values available with variance… R1(config-router)#variance ? <1-128> Metric variance multiplier

Setting variance to 1 is effectively disabling unequal-cost load balancing while retaining equalcost load balancing. You can’t set it to zero. Planning Your Load Balancing Enabling

both

equal-cost

and

unequal-cost load balancing is simple enough in EIGRP - the former is on by default, the latter is enabled with one simple command but you’ve got to do some planning and verification, too. I strongly recommend you create a network baseline before using the variance command. Besides, if you don’t know how much traffic your network is carrying, it’s hard to determine if your load balancing is working as desired! After you run the variance, we need to make sure of two things…

The load balancing is going as expected and desired Only the paths you wanted to use are being used When it comes to our old friends ping and traceroute, we tend to ping first and trace second… but when you’re testing your load balancing, you can leave the pings alone. Pings will show you that you do have connectivity to a given destination, but they don’t show you how we got there. Traceroutes do.

(And just in case - the ping and traceroute escape sequence, twice in rapid succession.) Once you’ve compared the new config’s baseline to the old, and you’re happy with the result document your changes. I know it’s no fun. I know you’d rather be doing something else. Do it anyway. : ) And one more thing - when testing and creating baselines for your EIGRP load balancing

configuration, that load balancing is only put into action for traffic that both enters and leaves that router - traffic actually generated by the local router is not subject to load balancing. DUAL Queries Let’s review the purpose of these packets… It is possible for an EIGRPspeaking router to have only a single path to a given network, which means we have one

successor and zero feasible successors. If that successor route is lost, that router will send DUAL Queries to all its neighbors. A DUAL Query is basically one neighbor asking another, “Hey, do you know how to get to this network I just lost my route to?” There’s no grey area here - either the downstream router has such a route, or it doesn’t. Here are the potential actions the downstream router can take: If that neighbor has a route, the query will be answered with

that route. Simple enough! If the neighbor doesn’t have such a route, that neighbor will ask its neighbors. The process continues until a downstream router replies with the desired route, or the EIGRP downstream routers run out of neighbors to ask. Just as it’s wise to limit the scope of broadcasts in our network, it’s a great idea to limit the scope of these Query packets as well. We have

two main weapons at our disposal for limiting the scope of Query packets: Manual route summarization EIGRP stub routing We’ll look at both later in this section. Feasible Distance and d Distance From all these views of the topology table, you’ve probably

noticed that there are two numbers in parenthesis following each nexthop IP address. P 172.23.0.0/16, 2 successors, FD is 2195456 via 172.12.123.2 (2195456/281600), Serial0 via 172.12.123.3 (2195456/281600), Serial0

The first number, 2195456, is the route’s feasible distance. This is the full metric of the route to the destination network. The second number, 281600, is the route’s d distance. This is simply the metric from the next-hop router to the destination network.

For the path to be considered valid, the d distance must be less than the feasible distance. This ensures that the next-hop router is indeed closer to the destination and acts as a routing loop prevention mechanism. These distances are also used by EIGRP to determine what routes can be feasible successors. Let’s look at our two routes to 3.0.0.0 /8 again. P 3.0.0.0/8, 1 successors, FD is 2297856 via 172.12.123.3 (2297856/128256), Serial0

via

172.12.123.2

(2323456/409600), Serial0

The second route can’t be a successor, because its FD (2323456) is higher than the FD of the successor (2297856). Can it be a feasible successor? Yes, because the d distance of that route (409600) is lower than the feasible distance of the successor (2297856). This is the Feasibility Condition. That route is then entered into the topology table as a feasible successor, and should the successor

go down, the feasible successor will become the successor. Let’s use some slightly smaller numbers to walk through an example without using show ip eigrp topology. We’ll assume a successor route and three possible feasible successors. Successor: FD 5, AD 4 Possible Feasible Successor #1: FD 9, AD 7 Possible Feasible Successor #2: FD 8, AD 6

Possible Feasible Successor #3: FD 6, AD 4 To decide if any of these three routes could be a feasible successor, just compare the AD of the route to the FD of the successor. Routes #1 and #2 could not be feasible successors, because their ADs are larger than the FD of the successor. Route #3’s AD of 4 is less than the successor’s FD of 5. As a result, Route #3 will be placed into the EIGRP topology table and marked

as a feasible successor. If the successor route goes down, Route #3 will then be named the successor. If the successor is lost and there is no feasible successor, the router takes two actions: The route is put into Active state, making the route unusable. The router sends DUAL Query packets to EIGRP neighbors, asking them if they have a

loop-free path to the destination in question.

Either the neighbors will answer this query with an alternate path (with a reply packet), or those neighbors will ask their neighbors if they have a path to the network. This query process continues until a router returns a path to that network, or no router can do so and the query process finally ends. We discussed SIA routes earlier, and another reason that routes

become Stuck In Active is the length of this query process. The query process can be limited with proper route summarization. (It bears repeating that the most common reason a route becomes SIA is the failure of a router to answer the query, whether that be a problem with the router or the link itself.) Let’s take another look at feasible distance, d distance, and the feasibility condition in action. You really have to watch these values, or what you think should happen with your network when a

successor goes down might not actually be what will happen. The Feasibility Action

Condition

In

R1 has three potential paths to R3. The feasible distances and

d distances for the paths from R1’s point of view are: R1 - R4 - R3: FD 40, AD 20 R1 - R2 - R3: FD 70, AD 20 R1 - R5 - R3: FD 115, AD 75 R1 will place the path through R4 into its routing table; since that route has the lowest FD, it is the successor. The successor is also placed into the topology table. R1 will consider the other two routes as potential feasible successors. The Feasibility Condition states that if a potential

feasible successor’s AD is less than the successor’s FD, the route is an FS. The AD of the path through R2 is 20; the FD of the successor is 40. The path through R2 is a feasible successor and will be placed into the EIGRP topology table. What about the third path? The AD of the path through R5 is 75, while the FD of the successor is 40. This indicates to EIGRP that the potential for a routing loop exists, so this route will not be made a feasible successor.

If the path through R4 went down, the router would immediately begin using the path through R2, which has already been tagged as a feasible successor. The path through R2 would then be named the successor route, but the path through R5 still would not be a feasible successor, as the path through R5 has an AD of 75 and the path through R2 has a FD of 70. The Feasibility Condition And The variance Command

The Feasibility Condition also impacts the use of the variance command. The value expressed with the variance command is essentially a multiplier that enables unequal-cost load balancing, but there’s more to it than that. You already know how to use the variance command, but it’s important to keep in mind that if a route doesn’t meet the Feasibility Condition, it can’t possibly be used in unequal-cost load balancing. Consider the network metrics from the last example:

R1 - R4 - R3: FD 40, AD 20 R1 - R2 - R3: FD 70, AD 20 R1 - R5 - R3: FD 115, AD 75 It’s very tempting to look at these metrics and think that we could use variance to use all three paths for unequal-cost load balancing. The problem is that you can’t use a path that doesn’t meet the Feasibility Condition. In the exam room and in the real world, make sure any routes you want to use in unequal-cost load balancing meet the Feasiblity

Condition, because if they don’t, you cannot use them no matter what the value of the variance command is. You should always write out the FD and AD of all routes in a network diagram before deciding whether the variance command will allow you to use all the paths. Let’s look at another example. How would you go about configuring unequal-cost load balancing in the following network?

The quick and obvious answer would be to just add up the metrics for each path, then figure out what variance value to use. The metric for the best path is 40; the metric for the lesser path is 115; therefore, we just run the command variance 3 (40 x 3 = 120, which will allow all valid routes with a metric of

less than 120 to be put into the routing table), and we’re all set, right? Wrong. The problem is not with our math, but with the Feasiblity Condition. Let’s look at the FD and AD for each path, using the values shown. R1-R2-R3: FD 40, AD 20 R1-R4-R5: FD 55, AD 35 R1-R6-R7: FD 115, AD 75 The successor will be R1-R2-R3; that route will be in both the route

and topology tables. R1-R4-R5 meets the Feasiblity Condition, since its AD of 35 is less than the FD of the successor, which is 40. That route is eligible for unequalcost load balancing and will be placed in the topology table. There’s a problem with R1-R6-R7, though. The AD of that path is 75, which is larger than the FD of the current successor; even if R1-R4R5 became the successor, R1-R6R7 still couldn’t meet the Feasiblity Condition. Therefore, the best solution is to run the command variance 2 to perform load sharing

over the single feasible successor. No matter the variance value, the third path cannot participate in unequal-cost load balancing. EIGRP istrative Distances The EIGRP routes you saw in the routing table earlier in this chapter were the EIGRP route type you learned about in your CCNA studies. These are EIGRP internal routes, and they have an istrative distance of 90. There are two other EIGRP route types, and they have different

istrative distances. Routes learned by EIGRP via route redistribution are external EIGRP routes and have an AD of 170. These routes are preceded in the routing table with the letters “D EX”. Keep in mind that redistributed routes don’t have to come from other routing protocols -- they can be connected or static routes as well. I’ve run into situations that had people scratching their heads over an AD value, so let’s take a look at one such configuration.

Both routers are in AS 100, and are connected via the Ethernet segment. One day, someone decides to the loopback interface on R2 (2.2.2.2 /32) to the rest of the EIGRP domain. You’ll generally use the network command for this. R2(config)#router eigrp 100 R2(config-router)#network 2.2.2.2 0.0.0.0

R3#show ip route eigrp 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/409600] via 172.23.23.2, 00:00:06, Ethernet0

That’s what we would expect to see, and that’s how R3 would then this network to downstream routers - as an internal route. What if redistribution were used on R2 instead of the network command? Let’s remove the network command on R2 and use redistribute connected instead. R2(config)#router eigrp 100 R2(config-router)#no network 2.2.2.2 0.0.0.0

R2(config-router)#redistribute connected R3#show ip route eigrp 2.0.0.0/32 is subnetted, 1 subnets D EX 2.2.2.2 [170/409600] via 172.23.23.2, 00:00:05, Ethernet0

The difference is significant! R3 now sees the same network as an external network, which means its AD is 170 instead of 90. R3 would then this network to downstream EIGRP routers as an external route. Even though there is no other AS or no other routing protocol involved, routes can still show up as external routes when you use route redistribution with

connected or static routes. To change the AD of external or internal EIGRP routes on a single router, use the distance eigrp command. Even if you’re only changing the distance of one route type, you still have to specify them both. R1(config)#router eigrp 100 R1(config-router)#distance ? <1-255> istrative distance eigrp IP-EIGRP distance R1(config-router)#distance eigrp ? <1-255> Distance for internal routes R1(config-router)#distance eigrp 45 ? <1-255> Distance for external routes R1(config-router)#distance eigrp 45 100

The third type of EIGRP route is an EIGRP summary route. The result of manual route summarization, these routes have an AD of 5 when viewed on the router actually performing the summarization. If you know where to look, that is. Stay tuned. EIGRP Route Summarization Automatic And Manual EIGRP has a default behavior involving route summarization that is almost always turned off at the very beginning of an EIGRP

deployment, and autosummarization.

that

is

EIGRP and RIPv2 automatically summarize routes when they are d across classful network boundaries. When you have discontiguous networks (subnets of the same major network number that are separated by another major network number), this behavior can result in suboptimal routing at its worst. Consider this network where subnets of the major network number 20.0.0.0 are separated by

another major network number, 172.16.0.0.

If EIGRP’s default autosummarization is left on, the hub router is going to get two ments for the major

network number 20.0.0.0 /8. Combined with another EIGRP default behavior, equal-cost load sharing, there is an excellent chance that half of the packets destined for any of the subnets of 20.0.0.0 are going to end up at the wrong spoke router. It’s easy enough to turn this behavior off: R1(config)#router eigrp 100 R1(config-router)#no auto-summary

Many real-world EIGRP deployments have no autosummary configured on every

router in the network. This doesn’t really hurt anything, but now that you’re training to be a CCNP, you need to know where the command is needed - and where it’s unnecessary. Disabling autosummarization on the spoke routers in this network will give the hub router a much more accurate picture of the network. , it’s not enough to know the command - you need to know where to configure the command. The no auto-summary command would have no effect on incoming updates if configured on the hub. In

this network, the command needs to be placed on each spoke.

Configuring any kind of manual summarization does NOT enable or disable auto-summarization -they’re two separate operations.

Route summarization isn’t always a bad thing -- configured at the right points in your network, it can be a great thing. Here are just a few reasons why… The routing tables are smaller, making the entire routing process faster. Since the tables are smaller, the load on the U from the routing process is lessened. The more-specific network numbers are hidden.

Routing updates are smaller. The impact of flapping routes on the rest of the network is lessened, and correct summarization helps to limit the number of EIGRP queries.

The key to success with real-world route summarization is that you, the network , should decide where summarization should take place -- not the router,

not the protocol. You. In this example, R1 has seven subnets of the major network number 100.0.0.0 that it’s advertising to R3:

R3’s EIGRP table shows all seven routes: R3#show ip route eigrp 100.0.0.0/16 is subnetted, 7 subnets

D 100.4.0.0 [90/2297856] via 00:00:00, Serial0 D 100.5.0.0 [90/2297856] via 00:00:00, Serial0 D 100.6.0.0 [90/2297856] via 00:00:00, Serial0 D 100.7.0.0 [90/2297856] via 00:00:00, Serial0 D 100.1.0.0 [90/2297856] via 00:00:00, Serial0 D 100.2.0.0 [90/2297856] via 00:00:00, Serial0 D 100.3.0.0 [90/2297856] via 00:00:00, Serial0

172.12.123.1, 172.12.123.1, 172.12.123.1, 172.12.123.1, 172.12.123.1, 172.12.123.1, 172.12.123.1,

With the help of manual route summarization, we can knock this table down to one line. First, we use our old friend binary math to convert the subnet numbers to

binary strings.

Believe it or not, that’s the hard part of summarizing routes. The next step in route summarization is to work from left to right and identify the common bits. From there, it’s easy: The decimal value of these bits is the summary route.

The number of common bits yields the summary mask. Here, the value of the common bits (bolded above) is 100.0.0.0. There are 13 common bits, expressed as /13 in prefix notation and 255.248.0.0 in dotted decimal. Now that we have the summary route and mask, this route and mask will be configured on the ethernet interface…. the physical interface that will be advertising the summary. R1(config)#interface ethernet0

R1(config-if)#ip summary-address eigrp 100 100.0.0.0 255.248.0.0 2d11h: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.3 (Serial0) is down: summary configured 2d11h: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.2 (Serial0) is down: summary configured

It’s important to keep in mind that when you configure EIGRP summary addresses, your neighbor relationships will be lost. When they come back up, R3 will have a single summary route instead of the seven more-specific routes it previously had.

R3#show ip route eigrp 100 100.0.0.0/13 is subnetted, 1 subnets D 100.0.0.0 [90/2297856] via 172.12.123.1, 00:03:33, Ethernet0

We saw the impact on R3 after route summarization, but there’s something of interest on R1 you should note. R1#show ip route < code table removed for clarity > 100.0.0.0/8 is variably subnetted, 8 subnets, 2 masks C 100.4.0.0/16 is directly connected, Loopback4 C 100.5.0.0/16 is directly connected, Loopback5 C 100.6.0.0/16 is directly connected, Loopback6 C 100.7.0.0/16 is directly connected,

Loopback7 D 100.0.0.0/13 is a 00:07:32, Null0 C 100.1.0.0/16 is directly Loopback0 C 100.2.0.0/16 is directly Loopback2 C 100.3.0.0/16 is directly Loopback3

summary, connected, connected, connected,

On R1, the summary route is seen as a route to Null0, which is basically a route to the trash can. If a packet comes into this router that doesn’t match one of the seven morespecific routes, it will be “blackholed” -dropped by the router. This default behavior of EIGRP route summarization helps to prevent

routing loops. This null route will only be seen on the router performing the manual summarization. The Mystery Of The AD5 One of the jumps from CCNA to CCNP in your EIGRP studies involves these three istrative distances: Internal: 90 External: 170 Summary: 5

We’ve seen that AD of 90 for internal EIGRP routes since the beginning of our studies; the AD of 170 has been seen in this section as well as the Redistribution section of the course. So what about that AD of 5 for EIGRP summary routes? When we looked at the summary route on the downstream router R3, we saw… R3#show ip route eigrp 100 100.0.0.0/13 is subnetted, 1 subnets D 100.0.0.0 [90/2297856] via 172.12.123.1, 00:03:33, Ethernet0

.. an AD of 90. Actually, that’s the value we should expect, since the summary route will have an AD of 5 only on the router that originates the summary. Great! Let’s take another look at R1’s routing table and that line for the summary route, and I’m sure we’ll see… D Null0

100.0.0.0/13 is a summary, 02:11:48,

… no AD at all. So where is it? After some information mining (a fancy way to say “I looked it up

again”), I found that you need to run the show ip route command followed by the network number. R1#show ip route 100.0.0.0 Routing entry for 100.0.0.0/8, 8 known subnets Attached (7 connections) Variably subnetted with 2 masks C 100.4.0.0/16 is directly connected, Loopback3 C 100.5.0.0/16 is directly connected, Loopback4 C 100.6.0.0/16 is directly connected, Loopback5 C 100.7.0.0/16 is directly connected, Loopback6 D 100.0.0.0/13 is a summary, 00:19:54, Null0 C 100.1.0.0/16 is directly connected, Loopback0 C 100.2.0.0/16 is directly connected,

Loopback1 C Loopback2

100.3.0.0/16 is directly connected,

Hmm. I still don’t see an AD. Do you? When all else fails, ask for directions from Mr. IOS Help: R1#show ip route 100.0.0.0 ? A.B.C.D Network mask longer-prefixes Show route matching the specified Network/Mask pair only | Output modifiers

Let’s try it with the mask:

R1#show ip route 100.0.0.0 255.248.0.0 Routing entry for 100.0.0.0/13 Known via “eigrp 100”, distance 5, metric 128256, type internal Redistributing via eigrp 100 Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 128256, traffic share count is 1 Total delay is 5000 microseconds, minimum bandwidth is 10000000 Kbit Reliability 255/255, minimum MTU 1514 bytes Loading 1/255, Hops 0

Ta da! Where Should Manual Route Summarization Be Performed?

Part of configuring anything Cisco, from manual route summarization to access lists, is figuring out the best point in your network to actually perform the operation. As you well know by this point in your Cisco studies, there’s rarely a “one-sizefits-all” solution to this question! When it comes to EIGRP route summarization, I’ve found the most efficient point to perform this operation is at the ASBR. We generally associate the term ASBR with OSPF, but an EIGRP router that performs route redistribution is also considered an ASBR. Just as

with OSPF, route summarization is more efficient when it’s configured on the ASBR. EIGRP Design Recommendations With networks growing and changing all the time, it’s impossible for anyone to give you a hard-and-fast set of design rules that will fit any network. Having said that, there are some solid general guidelines when it comes to EIGRP. Make sure you spend some

time and set up a solid address allocation scheme before you deploy your network. This pointer is the EIGRP equivalent of “measure twice, cut once”. Ensure that you’ll be able to perform manual route summarization where desired. Avoid discontiguous networks whenever possible. Make sure your routers have

sufficient memory and U to do their jobs. Your hub routers in any hub-and-spoke deployments will be the workhorses of your network.

Cisco has a few recommendations when it comes to EIGRP bandwidth allocations over the NBMA cloud. Your EIGRP traffic on each Virtual Circuit (VC) shouldn’t exceed the Committed Information Rate (CIR). (The CIR is the amount of

bandwidth the service provider guarantees to be available to us.) The total EIGRP traffic crossing all of your VCs should not be greater than the total capacity of the line. The bandwidth allocated to EIGRP on each VC should be the same on each interface. There are also some details to attend to when it comes to

allocating bandwidth over an NBMA network. The typical Serial interface is going to have multiple Virtual Circuits, so you have to know how EIGRP will run in that situation. The calculation for the bandwidth command varies according to two factors: the type of interface in use on the hub the CIR assigned to each circuit Just looking at these guidelines give

you an idea of some good questions to ask before you start configuring: What IS the current CIR? What are the current bandwidth values of the interfaces? Does the client have any special requests or policies that need to be taken into consideration - bandwidth maximums / minimums, stub routers, non-transient routers, etc.?

Let’s take a look at several different scenarios, beginning with a physical interface on the hub and three circuits all assigned the same CIR.

When there are no subinterfaces in

use and the CIR is the same for every VC, just add up the CIRs and you’ve got your bandwidth value. Doing this ensures that none of the circuits are overloaded, which could happen if we leave the bandwidth setting at the default. R1(config)#int serial0 R1(config-if)#bandwidth 768

Cisco has stated you can take the lowest CIR value and multiply it by the number of VCs. This isn’t the recommended solution, but it is valid. Using this solution, the bandwidth setting on R5’s Serial0 interface would be (3 x 56), or 168. R1(config)#int s0 R1(config-if)#bandwidth 168

This would prevent R7 from being overrun with packets, but it doesn’t allow R6 or R4 to work to capacity. A more viable solution involves

configuring point-to-point interfaces and asg individual bandwidth values, having those match the individual CIR of each VC. This is Cisco’s recommendation for this situation, and this allows each router to work more closely to capacity!

R1(config)#int serial0.1 point-to-point R1(config-subif)#ip address 255.255.255.0 R1(config-subif)#bandwidth 512

20.1.1.1

R1(config-subif)#int s0.2 point-to-point R1(config-subif)#ip address 40.1.1.1 255.255.255.0 R1(config-subif)#bandwidth 256 R1(config-subif)#int s0.3 point-to-point R1(config-subif)#ip address 50.1.1.1 255.255.255.0 R1(config-subif)#bandwidth 56

Multipoint Subinterfaces, VCs Using Different CIRs

Of course, you may have a multipoint subinterface on the hub router! In that case, simply add the CIR values for each circuit using that multipoint subinterface to arrive at the correct bandwidth setting. In the following example, there are

three circuits using the same multipoint interface. The CIRs are 512, 256, and 56 kbps; the bandwidth setting on R5’s multipoint interface should be set to 824 kbps. R1(config)#interface s0.467 multipoint R1(config-subif)#bandwidth 824

By default, EIGRP uses up to 50 percent of a given interface’s bandwidth as set by the bandwidth command. If you wish to change this default, it can be done with the interface-level command ip bandwidth-percent eigrp.

R1(config)#int s0 R1(config-if)#ip bandwidth-percent eigrp ? <1-65535> Autonomous system number R1(config-if)#ip bandwidth-percent eigrp 100 ? <1-999999> Maximum bandwidth percentage that EIGRP may use R1(config-if)#ip bandwidth-percent eigrp 100 300

In this command, the values look really strange. According to IOS Help, we can set the interface bandwidth usage to more than 100 percent! I set it to 300% here and didn’t get an error message of any kind. How in the world can I set EIGRP

100 to use 300% of an interface’s available bandwidth? There is always the chance that the actual physical speed of the interface exceeds the logical setting. You could take an interface with a 512 kbps capacity and give it a logical setting of 56 kbps. If you then wanted the line to allow EIGRP to use 168 kbps of the physical bandwidth, you’d set the bandwidth-percent value to 300, which allocates 300% of 56kbps to EIGRP traffic - which is 3 x 56, or

168. I know it sounds crazy, so here’s the proof that you can actually do this: R3(config)#interface serial0 R3(config-if)#bandwidth 56 R3(config-if)#ip bandwidth-percent eigrp ? <1-65535> Autonomous system number R3(config-if)#ip bandwidth-percent eigrp 100 ? <1-999999> Maximum bandwidth percentage that EIGRP may use R3(config-if)#ip bandwidth-percent eigrp 100 300

Watch that syntax - the first number is the EIGRP AS; the second number is the bandwidth percentage.

EIGRP Stub Routers Here’s a great method of limiting the size of some routing tables in your EIGRP deployment and the scope of DUAL Query packets. While EIGRP does not have the stub area options that OSPF does, EIGRP does allow a router to be configured as stub. This is commonly done with a hub-andspoke configuration where the spoke routers do not have the resources or the need to keep a full routing table.

Since the spoke’s next hop will always be the hub, all the spoke really needs is a default route. For this reason, the only neighbor an EIGRP stub router can have is the hub router -- two EIGRP stub routers cannot become neighbors. Configuring EIGRP stub routers also combats the SIA problem. EIGRP stub routers are not queried for routes when the hub does not have a feasible successor for a successor route that has gone down. This limits the scope of EIGRP Query packets and is a popular reason for configuring EIGRP stub

routing. By default, EIGRP stub routers information about two types of routes back to the hub directly connected networks and summary routes. Configuring an EIGRP router as stub is very simple: R1(config)#router eigrp 100 R1(config-router)#eigrp stub

To change this default, use the eigrp stub command followed by the types of routes you want the stub to back to the hub.

R1(config)#router eigrp 100 R1(config-router)#eigrp stub ? connected Do connected routes receive-only Set IP-EIGRP as receive only neighbor static Do static routes summary Do summary routes

The network we looked at earlier in

this section has several excellent candidates for EIGRP stub routers. As long as R4, R6, and R7 are each only neighbors with the hub, R5, they can be configured as stub routers. Those stub routers will then their directly connected networks and summary routes back to the hub and will receive only a default route back from the hub. If R5 loses a successor and has no feasible successor, it will not send a query packet to any of the stub routers.

Basically, what we’re doing is preventing R5 from asking a question of those other routers that they can’t possibly have an answer to in the first place. An EIGRP stub deployment can have more than one hub, as the following illustration shows. The important thing is that the spoke routers are not interconnected. The hub routers R5 and R8 are interconnected, but not the spokes R4, R6, and R7.

Just A Reminder… I know you this from your CCNA studies, but I’m going to tell you anyway - EIGRP assumes that a serial interface is connected to a T1 line, which runs at 1544 kbps (or 1.544 mbps). If this isn’t the case in your network,

the bandwidth command can be used to give EIGRP a more accurate reflection of the line speed. For example, if you have a serial interface connected to a 56 kbps line, it’s a good idea to tell EIGRP to reflect that in its routing calculations with the bandwidth command. R1(config)#int s0 R1(config-if)#bandwidth 56

Always use IOS Help to the unit of measurement for any value. There’s a big difference between entering bandwidth 56 and

bandwidth 56000 on that line! And Just Another Reminder… There’s some confusion out there as to whether the use of wildcard masks with EIGRP is required. I personally recommend you use wildcard masks every time you can, but it’s not required. R1(config)#router eigrp 100 R1(config-router)#network 10.0.0.0 ? A.B.C.D EIGRP wild card bits R1(config-router)#network 10.0.0.0

This IOS Help readout shows that you can configure wildcard bits

with this network command, and the indicates that it’s a legal command just the way it is. Pre12.0 IOS versions don’t EIGRP wildcard masks, so you should also be prepared for that possibility. I’ve seen one or two routers running at least 12.0 that didn’t seem to like wildcard masks either - that seems to have been an anomaly - the important point here is that their use is not required, but is recommended. What’s

So

ive

About

A

ive Interface? On occasion - say, maybe your CCIE lab date :) - you may want to a network via EIGRP, but not want to send EIGRP-related traffic out the interface you’re advertising. For example, let’s say you want to our Ethernet segment of 172.23.23.0 /24 to R1, but you don’t want any EIGRP traffic, Hellos or otherwise, to be sent out the interfaces on that segment. Configuring the Ethernet0 interfaces on R2 and R3 as ive will make

that happen. When you configure an EIGRPenabled interface as ive, that interface will not transmit Hello packets. Since the absence of Hello packets means no adjacencies, no other EIGRP packets will go out those interfaces. There are two approaches to configuring ive interfaces: Option 1: Use the ive-interface default command to make every EIGRP-enabled interface on the router ive, and then use the no

ive-interface command to indicate the interfaces that should not be ive. The following configuration will first enable EIGRP ive interface as the default, and the next command disables that same feature on Serial0. R1(config)#router eigrp 100 R1(config-router)#ive-interface ? BRI ISDN Basic Rate Interface Ethernet IEEE 802.3 Loopback Loopback interface Null Null interface Serial Serial default Suppress routing updates on all interfaces R1(config-router)#ive-interface default

R1(config-router)#no ive-interface ? BRI ISDN Basic Rate Interface Ethernet IEEE 802.3 Loopback Loopback interface Null Null interface Serial Serial default Suppress routing updates on all interfaces R1(config-router)#no ive-interface serial0

Option 2: Use the no iveinterface default command to disable this feature globally, and then use the ive-interface command to indicate interfaces that should be ive.

Naturally, as a result of making Serial0 ive, any existing adjacencies formed through that interface are lost - and the DUAL message tells you why. R2(config)#router eigrp 100 R2(config-router)#no ive-interface default R2(config-router)#ive-interface serial 0 R2(config-router)# 00:48:36: %DUAL-5-NBRCHANGE: IPEIGRP 100: Neighbor 172.12.123.1 (Serial0) is down: interface ive

When you realize you made the wrong interface ive, just use the no ive-interface command to make things right and the

adjacency should quickly reappear. R2(config-router)#no ive-interface serial 0 R2(config-router)# 00:50:08: %DUAL-5-NBRCHANGE: IPEIGRP 100: Neighbor 172.12.123.1 (Serial0) is up: new adjacency

Note that all commands discussed above are run in the EIGRP configuration, not at the interface level. Propagating A Default Route Via EIGRP First, the bad news: We don’t have OSPF’s default informationoriginate option in EIGRP

(“always” or otherwise). The good news: We can redistribute a static default route into EIGRP, or we can indicate a default network with the ip default-network command. To go with the static default option, just create a static default route with the ip route command and follow that with the redistribute command. R1(config)#ip route 0.0.0.0 0.0.0.0 ethernet0 R1(config)#router eigrp 100 R1(config-router)#redistribute static ? metric Metric for redistributed routes route-map Route map reference

R1(config-router)#redistribute static metric ? <1-4294967295> Bandwidth metric in Kbits per second R1(config-router)#redistribute static metric 1544 ? <0-4294967295> IGRP delay metric, in 10 microsecond units R1(config-router)#redistribute static metric 1544 10 ? <0-255> IGRP reliability metric where 255 is 100% reliable R1(config-router)#redistribute static metric 1544 10 255 ? <1-255> IGRP Effective bandwidth metric (Loading) where 255 is 100% loaded R1(config-router)#redistribute static metric 1544 10 255 1 ? <1-4294967295> IGRP MTU of the path R1(config-router)#redistribute static metric 1544 10 255 1 1500

Downstream routers will see this route as follows: R2#show ip route eigrp 100.0.0.0/13 is subnetted, 1 subnets D*EX 0.0.0.0/0 [170/2172416] via 172.12.123.1, 00:01:15, Serial0

You can use the network 0.0.0.0 command in the EIGRP config in lieu of the redistribute command. R2 will still see the default route, but it will have an AD of 90 rather than 170 since redistribution is not involved. R1(config)#router eigrp 100 R1(config-router)#network 0.0.0.0 ?

A.B.C.D EIGRP wild card bits R2#show ip route eigrp 100.0.0.0/13 is subnetted, 1 subnets D* 0.0.0.0/0 [90/2195456] via 172.12.123.1, 00:00:05, Serial0

Just one more option for redistribution (for now). the route to null0 that was placed in our routing table as a result of route summarization? That route can also be redistributed, but it can lead to some routing issues depending on your network topology. I’m personally not big on redistributing a route to null0, but it’s an

important option to keep in mind. Using The IP Default-Network Command You can a non-zero network number as the default route with the ip default-network command, but there’s just one thing to watch out for …. The router that originates this ment MUST have that network number in its IP routing table. The reason I’m making such a big

deal of that is with OSPF, we had the option of advertising a default route even when the router didn’t have such a default route in its routing table (“default informationoriginate always”). We have no such option with EIGRP. After removing the above default static route and the redistribute command, I’ll configure 20.0.0.0 as the default network for EIGRP… R1(config)#router eigrp 100 R1(config-router)#ip default-network ? % Unrecognized command

… or will I? Don’t try to use the ip defaultnetwork command in the EIGRP config itself - it’s a globally configured command. R1(config)#ip default-network 20.0.0.0

But on R2, no such network appears and there is no gateway of last resort. R2#show ip rout Gateway of last resort is not set 100.0.0.0/13 is subnetted, 1 subnets D 100.0.0.0 [90/2297856] via 172.12.123.1, 00:02:30, Serial0

172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0

Let’s go back to R1, remove the 20.0.0.0 network, and add the 10.0.0.0 network that does have an entry in the routing table: R1(config)#no ip default-network 20.0.0.0 R1(config)#ip default-network 10.0.0.0

The route is flagged as a candidate default in R1’s routing table.. C* Ethernet0

10.0.0.0/8 is directly connected,

… and is d via EIGRP to

downstream routers. R2#show ip route eigrp 100.0.0.0/13 is subnetted, 1 subnets D 100.0.0.0 [90/2297856] via 172.12.123.1, 00:02:46, Serial0 D* 10.0.0.0/8 [90/2195456] via 172.12.123.1, 00:01:37, Serial0

Authenticating Neighbors

Our

EIGRP

In today’s world, it’s not always a good idea to assume that all neighbors dynamically discovered by EIGRP are actually desirable neighbors. They could be rogue

routers that will have the ability to inject a malicious routing update into our network - and the resulting IP routing table could end up sending all of our network’s data to a rogue router. EIGRP neighbor authentication isn’t the most intuitive feature you’ll ever configure, and there are quite a few command options. Before you even get that far, though, you have to decide whether you’re going to use clear-text s or use MD5 authentication to encrypt those s….

… and while I’ll show you how to do both, in the real world that shouldn’t be much of a decision. If you’re going to the trouble to configure EIGRP neighbor authentication in the first place, go all the way and use MD5 authentication. Note that MD5 only encrypts the used for our neighbor authentication - it does not protect the payload of the packets. Since you’re much more likely to work with MD5 EIGRP authentication, let’s configure that

right now! First, define the and any other options such as start-time and end-time with the key chain command. Before setting any options, though, configure the actual with the key-string command. R3(config)#key chain ? WORD Key-chain name R3(config)#key chain EIGRPNEIGHBOR ? R3(config)#key chain EIGRPNEIGHBOR R3(config-keychain)#key ? <0-2147483647> Key identifier R3(config-keychain)#key 1 R3(config-keychain-key)#key-string ? <0-7> Encryption type (0 to disable

encryption, 7 for proprietary) LINE The key R3(config-keychain-key)#key-string KINISKI

You can define how long a particular should be sent and accepted with the send-lifetime and accept-lifetime commands. For your intro to this command, we’ll use the infinite option for the expiration date - which means that it never expires! R3(config-keychain-key)#? Key-chain key configuration commands: accept-lifetime Set accept lifetime of key default Set a command to its defaults exit Exit from key-chain key configuration mode

key-string Set key string no Negate a command or set its defaults send-lifetime Set send lifetime of key R3(config-keychain-key)#accept-lifetime ? hh:mm:ss Time to start local Specify time in local timezone R3(config-keychain-key)#accept-lifetime 10:00:00 ? <1-31> Day of the month to start MONTH Month of the year to start R3(config-keychain-key)#accept-lifetime 10:00:00 Jan 1 ? <1993-2035> Year to start R3(config-keychain-key)#accept-lifetime 10:00:00 Jan 1 2010 ? duration Set key lifetime duration hh:mm:ss Time to stop infinite Never expires R3(config-keychain-key)#accept-lifetime 10:00:00 Jan 1 2010 infinite R3(config-keychain-key)#send-lifetime 10:00:00 Jan 1 2010 infinite

You might expect that we would have lost our EIGRP adjacencies from R3, but that’s not the case yet we’ve just created the key, but we haven’t applied the key to the interface(s). In essence, we’ve forged the key but haven’t locked the door. That’s about to change. Let’s apply this authentication to the Ethernet segment over which R2 and R3 are exchanging EIGRP traffic. This actually requires two commands on each interface. On

R3, we’ll begin by configuring the MD5 authentication mode on that Ethernet interface, taking a look at the options along the way: R3(config)#int e0 R3(config-if)#ip authentication ? key-chain key-chain mode mode R3(config-if)#ip authentication mode ? eigrp Enhanced Interior Gateway Routing Protocol (EIGRP) R3(config-if)#ip authentication mode eigrp ? <1-65535> Autonomous system number R3(config-if)#ip authentication mode eigrp 100 ? md5 Keyed message digest R3(config-if)#ip authentication mode eigrp 100 md5 ? R3(config-if)#ip authentication mode eigrp 100 md5

R3(config-if)# 04:01:46: %DUAL-5-NBRCHANGE: EIGRP 100: Neighbor 172.23.23.2 (Ethernet0) is down: Auth failure

IP-

Almost immediately, the adjacency to R2 is dropped - “Auth failure”. Let’s finish the config with the ip authentication key-chain command and see if it comes back up! R3(config-if)#ip authentication ? key-chain key-chain mode mode R3(config-if)#ip authentication key-chain ? eigrp Enhanced Interior Gateway Routing Protocol (EIGRP) R3(config-if)#ip authentication key-chain eigrp ? <1-65535> Autonomous system number R3(config-if)#ip authentication key-chain eigrp

100 ? WORD name of key-chain R3(config-if)#ip authentication key-chain eigrp 100 EIGRPNEIGHBOR ? R3(config-if)#ip authentication key-chain eigrp 100 EIGRPNEIGHBOR

We have no chance of getting the adjacency back until we configure R2 with the same config, so I’ve done that as well - here’s the resulting configuration: key chain EIGRPNEIGHBOR key 1 key-string KINISKI accept-lifetime 10:00:00 Jan 1 2010 infinite send-lifetime 10:00:00 Jan 1 2010 infinite ! !

! interface Ethernet0 ip address 172.23.23.2 255.255.255.0 ip authentication mode eigrp 100 md5 ip authentication key-chain eigrp 100 EIGRPNEIGHBOR

And in just a few seconds…. 04:09:18: %DUAL-5-NBRCHANGE: IPEIGRP 100: Neighbor 172.23.23.2 (Ethernet0) is up: new adjacency

.. the adjacency is back! (Of course, trust but - I’d send a few pings to that neighbor.) There is a show verification command for the key chain that

gives you a very important piece of information at the very far right of the output: R2#show key chain Key-chain EIGRPNEIGHBOR: key 1 -- text “EIGRP” accept lifetime (10:00:00 UTC Jan 1 2010) - (infinite) [valid now] send lifetime (10:00:00 UTC Jan 1 2010) - (infinite) [valid now]

The key “KINISKI” is shown to be “valid now”. What if it wasn’t valid? Let’s create a key chain with the same name where I mistyped a single number:

R2(config)#key chain EIGRPNEIGHBOR R2(config-keychain)#key 1 R2(config-keychain-key)#key-string SPIDERS R2(config-keychain-key)#accept-lifetime 00:00:00 Jan 1 2020 infinite R2(config-keychain-key)#send-lifetime 00:00:00 Jan 1 2010 infinite

When you’re typing this many numbers, it’s easy to hit just one wrong key - so always with show key chain. If you’re expecting this key chain to be valid now, but you don’t see that phrase next to each line of the output… R2#show key chain Key-chain EIGRPNEIGHBOR:

key 1 -- text “SPIDERS” accept lifetime (00:00:00 UTC Jan 1 2020) - (infinite) send lifetime (00:00:00 UTC Jan 1 2010) - (infinite) [valid now]

.. you know you mistyped something. To fix this, don’t delete the entire key chain - just reenter the config mode and use the no option to remove the unwanted part of the config. Then enter what you meant to enter! :) Before you head to the advanced EIGRP section, watch these recommended videos from my

YouTube channel and my website! Video Practice Exam on EIGRP: http://www.youtube.com/watch? v=LPuXmiKznEI istrative Distance Lab And EIGRP: http://www.youtube.com/watch? v=yNgZwD8kXP0 Don’t miss this one - “The Mystery Of The AD 5”

http://www.youtube.com/watch? v=X9AzQCt7rCM Video Exam & Boot Camp Includes EIGRP: http://www.youtube.com/watch? v=f5_i2yEXj3s Free CCNP ROUTE Video Boot Camp on route redistribution: http://bit.ly/Arnhjq Enjoy! -- Chris B.

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

Link State Protocols & Single-Area OSPF

Link State Protocol Basics You’re familiar with link state protocol behaviors from your CCNA studies, but we’re going to review the important points here in just a moment. Avoid the temptation to skip the review. While quite a bit of it will be

familiar to you, there are many additional details you must master at the CCNP level. Those of you with your eyes on the CCIE will need to truly master the fundamentals of OSPF. When RIP sends routing updates, these updates contain the full routing table. By running debug ip rip, you can actually see the routes contained in the update, along with the route metrics. Link state protocols don’t work that way. Link state routers that have formed adjacencies exchange Link

State Updates (LSUs), which contain Link State ments (LSAs). It’s these LSAs that carry subnet masking information and allow OSPF to VLSM. These LSAs are placed into a link state database. The Dijkstra algorithm (also known as the Shortest Path First algorithm, or simply SPF) is run against the contents of this database to create the OSPF routing table. Routers should have synchronized link state databases. To see the contents of the database,

run show ip ospf database. This command shows the links and link types, sequence numbers, and how long it’s been since a particular LSA was received. This value is in seconds and is seen under the “age” column. The Dijkstra algorithm runs against the contents of the OSPF database… R1#show ip ospf database

… calculates the routes, and these routes are placed into the OSPF routing table. R1#show ip route ospf 6.0.0.0/32 is subnetted, 1 subnets O 6.6.6.6 [110/11] via 10.1.1.5, 02:32:53, Ethernet0 7.0.0.0/32 is subnetted, 1 subnets O 7.7.7.7 [110/11] via 10.1.1.5, 02:32:53, Ethernet0

The SPF algorithm actually calculates a shortest path tree, and

that tree is used to create the routing table. We don’t have to think much more about the SPF algorithm since it does a great job without our interference, but we have plenty of other details to attend to! LSA Sequence Numbers To ensure that OSPF routers receive the most recent information, these LSAs are assigned sequence numbers. When an OSPF-enabled router receives an LSA, that router checks its OSPF database to see if there is already an entry for that

link. If there is no entry for that link, the receiving router will make one *and* flood that LSA out every OSPF-enabled interface on the router except the one it came in on. If there is an entry, one of three situations exists. Either the incoming LSA has a sequence number that is the same, lower, or higher than the entry already in the database. If the sequence number is the same, the LSA is ignored and

no additional action is taken. If the sequence number is lower, the router will ignore the update and will then transmit an LSU containing that LSA back to the original sender. In this situation, the router with the more-recent information is telling the original sender, “The information you’re sending is outdated. Here’s what you should be sending.”

If the sequence number is higher, the router will add that LSA to its database and send an LSAcknowledgment. The router will then flood that LSA and will run the SPF algorithm in order to update its own routing table. When Are LSAs Exchanged? Distance vector protocols send updates at a regularly scheduled interval, regardless of whether there has actually been a change in the network topology. In a stable

network, this is a waste of network resources. Once the initial exchange of LSAs takes place between two OSPF neighbors, there will not be another exchange until there is a change in the network topology. An OSPF-speaking router will also send out a summary LSA every 30 minutes. Before this LSA exchange begins, routers must become neighbors by forming an adjacency. To form an adjacency, routers must agree on the area number, the hello and dead timer settings, and whether the area

is a stub area. If link authentication has been configured, it must be configured on both sides of the link. The OSPF process number itself is locally significant and does not affect the adjacency process. To check your router’s adjacencies, run show ip ospf neighbor or the less-common show ip ospf interface. That last command tends to be forgotten, but there’s a lot of great information there. Note that both of these commands tell you what neighbor relationships

currently exist, and only show ip ospf neighbor shows you the status of the database loading (FULL, 2WAY, etc)

R3#show ip ospf interface serial0 Serial0 is up, line protocol is up Internet Address 172.12.123.3/24, Area 0 Process ID 1, Router ID 3.3.3.3, Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DROTHER, Priority 0 Designated Router (ID) 1.1.1.1, Interface address 172.12.123.1 No backup designated router on this network Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5

Hello due in 00:00:16 Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 3 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 1.1.1.1 (Designated Router) Suppress hello for 0 neighbor(s)

show ip ospf interface gives you the local router’s OSPF RID, its role on that segment (DR, BDR, DROther), the RID of the DR and BDR for that segment, how many adjacencies the local router has formed on that segment, and a lot more. It’s an excellent starting point

for OSPF troubleshooting. The Role Of The DR and BDR A major drawback of distance vector protocol is slow convergence. Convergence refers to a network state where every router has a similar and accurate view of the network, particularly after a topology change such as a downed route. Distance vector protocols don’t converge quickly at all, which can lead to suboptimal routing and routing loops.

Link state protocols converge almost immediately upon a topology change. OSPF uses designated routers and backup designated routers to make network convergence a fast and orderly process. How DRs Changes

Flood

Network

When a router on an OSPF segment with a DR and BDR detects a change in the network, that router will not notify all neighbors. Instead, the detecting router will send a multicast to 224.0.0.6, the

address to which both the DR and BDR listen to learn about such changes. The DR will then send a multicast to 224.0.0.5 to notify all non-DR and non-BDR routers of the change. (Routers that are neither the DR or BDR for a network segment are called DROthers, as shown in the output of the command show ip ospf neighbor.) The DROthers will send an LSAcknowledgment, or LSAck, back to the DR to indicate receipt of the update. Two notes here:

Only the DR and BDR listen to 224.0.0.6. Only the DR will actually send the multicast to 224.0.0.5 to notify the DROTHERS of the network change. The BDR receives the original change notification, but does not notify other routers of that change. Listening to 224.0.0.6 allows the BDR to have the most recent database entries possible - and that’s important in case it has to quickly become the DR.

The DR/BDR Election Process Almost every OSPF network segment is going to contain a DR and BDR. As always, there are exceptions, and we’ll take a detailed look at those situations later in this section. For now, let’s take a close look at the rules regarding DR and BDR selection. Consider the following network diagram. (I could have put a switch in the middle of this particular diagram rather than a segment

labeled “ethernet”; be prepared to see either in network documentation.)

Four routers have interfaces on the Ethernet segment. One will become the DR, one will become the BDR, and the others will be DROthers. Before we look at how Cisco routers decide which routers will fill these roles, let’s take an overview of the OSPF DR/BDR election process. 1. All routers with an OSPF interface priority of 1 or higher are eligible for the election. (That priority of 1 is the default.) Setting the interface priority to 0 will eliminate that router from the election on that segment.

2. The router with highest priority is elected DR. 3. If there is a tie, the OSPF Router ID (RID) value will be the tiebreaker. The router with the highest RID wins. 4. This process is repeated to elect a new BDR. A single router cannot be the DR and BDR for the same segment. There will be some interesting behavior concerning DROthers on an ethernet segment, which we’ll discuss later in this section. For

now, the focus will remain on the DR / BDR election process with an examination of the OSPF RID. The OSPF RID Selection Process Obviously, the OSPF RID plays a huge part in the selection of the DR and BDR - but how is the RID value determined? By this set of rules: The OSPF RID of a router will be the highest IP address assigned to a loopback interface on that router, regardless of whether that

loopback interface is OSPFenabled. A loopback interface that is the OSPF RID is *NOT* automatically d by OSPF. If no loopback exists, the OSPF RID of a router will be the highest IP address assigned to a physical interface on that router, regardless of whether that interface is OSPFenabled. These rules can both be

overridden by setting the OSPF RID manually with the router-id command, but the router must be reloaded or the OSPF processes cleared before the command will take effect. It seems a little strange that a router can have a loopback address that isn’t being d by OSPF actually serve as the RID, doesn’t it? Let’s see this in action. R1 and R5 have formed an OSPF adjacency

over an Ethernet segment on network 10.1.1.0 /24. R5 has multiple loopbacks, and is only advertising two of them via OSPF: hostname R5 ! interface Loopback6 ip address 6.6.6.6 255.255.255.255 ! interface Loopback7 ip address 7.7.7.7 255.255.255.255 ! interface Loopback8 ip address 8.8.8.8 255.255.255.255 ! interface Ethernet0 ip address 10.1.1.5 255.255.255.0 ! router ospf 1 network 6.6.6.6 0.0.0.0 area 0

network 7.7.7.7 0.0.0.0 area 0 network 10.1.1.0 0.0.0.255 area 0

Knowing what you know about OSPF RIDs, what will R1 show as the RID for R5? Take a moment to look at the above configuration and figure that out. If you said 8.8.8.8, you’re right. To see the OSPF RID of a neighbor, run show ip ospf neighbor: R1#show ip ospf neighbor

The value shown under Neighbor ID is that neighbor’s RID.

To illustrate another important point regarding DRs and BDRs, let’s go back to our four-router example. The routers have the following addresses: RouterA: Loopback 1.1.1.1, ethernet0 172.1.1.1 RouterB: Loopback 2.2.2.2, ethernet0 172.1.1.2 RouterC: No loopback, ethernet0 172.1.1.3 RouterD: No loopback, ethernet0 172.1.1.4

The RIDs would be as follows: RouterA: 1.1.1.1 RouterB: 2.2.2.2

RouterC: 172.1.1.3 RouterD: 172.1.1.4

The RID process will always prefer a loopback interface IP address over a physical interface’s IP address. Summing up, we have three options when it comes to manipulating the DR selection: Changing the OSPF priority with ip ospf priority

Setting the OSPF Router ID manually with router-id Setting the OSPF Router ID to an appropriate value by configuring a loopback interface None of these choices are “wrong” or “right” - so know all three, and know that some reloading of routers or clearing of OSPF processes will be necessary in order to change the results of a DR election. What If The DR Goes Offline And

Then Back Online? If all four of those routers came up simultaneously and we have a fourway router election for DR and BDR, we would expect to see Router D become the DR and Router C become the BDR. But what happens if RouterD goes down and then comes back up? In RouterD’s absence, Router C becomes the DR. Router B would then become the BDR. And when Router D comes back up, those routers keep their roles.

This isn’t like Spanning-Tree Protocol (STP), where a new switch with a lower BID would become the root bridge. With OSPF, a DR/BDR election is not held when a new router comes online or when a router that was previously a DR or BDR comes back online. Let’s take an example where three routers are on an Ethernet segment. Router A has a priority of 100, Router B a priority of 50, and R3 a priority of 10. Router A has been elected DR and Router B the BDR.

All is well until Router A goes down. Router B will then become the DR, and Router C will be elected BDR.

Router A coming back on line is not a reason for a DR/BDR election to be held, even though Router A’s priority is higher than the DR and the BDR. When Router A comes back up, it will be a DROther.

For Router A to become the DR again, both the current DR and BDR have to go down! What will happen when Router B goes down?

Router C is promoted to DR and Router A is elected BDR. When Router B comes back up, it will become a DROther.

For Router A to finally become the DR again, now Router C will have to go down. Router A will then be promoted from BDR to DR, and Router B will become the BDR.

When Router C comes back up, it will be a DROther, and the network is finally the way it was before!

The OSPF Network Types Why OSPF Network Types Matter The default OSPF network type depends on the network segment

type. Different OSPF network types have different default hello and dead timers, and that’s one of the factors that must match between two routers for an adjacency to form. In addition, some of these networks do not have DRs and BDRs, and others that do have special considerations that must be observed. Other than that, they’re all the same, right? :) No worries, we’re going to build and cover each OSPF network type you need to master to the CCNP ROUTE exam right now!

Unless otherwise noted, each segment is being placed into Area 0 - the backbone area. The broadcast network’s subnet is 10.1.1.0 /24. The final octet of every IP address will be that router’s number. Every router has a loopback interface with its router number as each octet. (R1’s loopback is 1.1.1.1 /32, and so forth.) The OSPF Broadcast Network

An OSPF configuration on an Ethernet segment will default to an OSPF broadcast network, and a DR and BDR will be elected. If we wanted one particular router to become the DR or BDR, we could use the ip ospf priority command to rig the election. On a large segment, it’s a good idea to have your more powerful routers fill these roles - being the DR or BDR for a segment or segments does increase the load on the U. As always, everything we do on a Cisco router has a cost.

The output of show ip ospf interface ethernet0 on R1 displays the network type, as well as a great deal of other important information. Note the default hello and dead timers for a broadcast segment - 10 and 40 seconds, respectively. By default, the dead time will be four times the hello time. R1# show ip ospf interface ethernet0 Ethernet0 is up, line protocol is up Internet Address 10.1.1.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 8.8.8.8, Interface address 10.1.1.5

Backup Designated router (ID) 1.1.1.1, Interface address 10.1.1.1 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:04 Index 1/1, flood queue length 0

Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 2 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 8.8.8.8 (Designated Router) Suppress hello for 0 neighbor(s)

It’s not a requirement to have a certain router become the DR or

BDR on a broadcast segment, but that’s not true of our next network segment. The OSPF NBMA Network We’ll now add another network segment to the existing adjacency, this one running over a frame relay cloud. The new segment will use 172.12.123.0 /24. R1 has a frame relay PVC to both R2 and R3; there is no PVC between the spokes. All routers have their Serial0 interface in Area 0.

The serial interfaces in this new segment will default to the OSPF network type non-broadcast multiaccess, or NBMA. Since there is no full mesh through the frame cloud (no PVC between R2 and R3), the hub router R1 has to be the DR and there can be no BDR. Why? Because the DR or any potential BDR must be able to get a multicast through to all other routers on that network. With a huband-spoke topology, a spoke router will not be able to get a multicast or

broadcast to the other spoke, since all spoke-to-spoke traffic will go through the hub - and routers do not forward broadcasts or multicasts! Before configuring any OSPF configuration over frame relay, make sure your frame map statements have the broadcast option enabled! Otherwise, OSPF packets will not be sent across the frame. R1(config-if)#frame map ip 172.12.123.2 122 broadcast R1(config-if)#frame map ip 172.12.123.3 123 broadcast

R1#show frame map Serial0 (up): ip 172.12.123.2 dlci 122(0x7A,0x1CA0), static, broadcast, CISCO, status defined, active Serial0 (up): ip 172.12.123.3 dlci 123(0x7B,0x1CB0), static, broadcast, CISCO, status defined, active

It’s not enough to make sure R1 wins the DR election - we’ve got to prevent the spoke routers R2 and R3 from having a chance to win! To prevent R2 and R3 from participating in the DR/BDR election, change the OSPF priority from its default of 1 to zero.

R2(config)#int s0 R2(config-if)#ip ospf priority 0 R3(config)#int s0 R3(config-if)#ip ospf priority 0

The router with the highest priority set on an OSPF-enabled interface will become the DR. If there is a tie, the router with the highest OSPF Router ID (RID) wins the election. Basically, we’re rigging the DR election so there’s no chance the spokes can possibly win, even if the hub disappears! Setting the spoke priorities to zero prevents one of

the spokes from becoming the DR in case the hub router reloads. The “NB” in NBMA stands for non-broadcast, so the hub router must be configured with manual neighbor statements, as shown below. No neighbor statements are needed on the spokes. R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router ospf 1 R1(config-router)#network 172.12.123.0 0.0.0.255 area 0 R1(config-router)#neighbor 172.12.123.2 R1(config-router)#neighbor 172.12.123.3 R1#show ip ospf interface serial0

Serial0 is up, line protocol is up Internet Address 172.12.123.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 1.1.1.1, Interface address 172.12.123.1 No backup designated router on this network Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 Hello due in 00:00:11 Index 2/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 2 Last flood scan time is 4 msec, maximum is 4 msec Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 3.3.3.3 Adjacent with neighbor 2.2.2.2 Suppress hello for 0 neighbor(s)

You can have an NBMA network where there is both a DR and BDR, but they still both have to be hub routers. A network with two hubs could have one as the DR and the other as the BDR. Every DR or BDR in an NBMA network must have static neighbor statements; they are not needed on the other routers. (If you have multiple hub routers, you can have one of them become the BDR.) Note the default hello and dead timers for an NBMA network - 30 and 120 seconds, respectively. The dead timer is again four times the

hello timer by default. Serial interfaces default to NBMA, but you can also change an interface’s OSPF network type to NBMA with the ip ospf network command. R1(config-if)#ip ospf network ? broadcast Specify OSPF broadcast multi-access network non-broadcast Specify OSPF NBMA network point-to-multipoint Specify OSPF point-tomultipoint network point-to-point Specify OSPF point-topoint network

The OSPF Point-To-Point And

Point-To-Multipoint Types

Network

We’ll now add a direct connection between R1 and R3, but put it into Area 13. The network number is 172.12.13.0 /27. Both routers are placing their interface Serial1 into Area 13.

All non-backbone areas must contain a router that has a physical or logical interface in Area 0. Area 13 has two such routers, so the configuration is legal. show ip ospf interface serial1 shows this OSPF segment defaulted to the OSPF network type point-topoint. This output also shows the default hello and dead timers for this network type - 10 and 40 seconds, respectively. R3#show ip ospf interface serial1

Serial1 is up, line protocol is up Internet Address 172.12.13.3/27, Area 13 Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:08 Index 1/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 1.1.1.1 Suppress hello for 0 neighbor(s)

Note that no DR or BDR is listed. On a point-to-point link, there are

only two routers on the link. Therefore, there’s no reason to even have a DR or BDR, and none will be elected. show ip ospf neighbor displays a dash where the role of the neighbor would usually be seen. The entire DR/BDR election process is byed with point-to-point and point-to-multipoint networks. No neighbor statements are necessary with these network types. Below, R3 sees R1 as the DR on the NBMA segment while not seeing R1 in any role on the point-to-point network.

The dash next to FULL/ for that adjacency indicates the neighbor is neither a DR, BDR, or DROther, which means there was no DR/BDR election in the first place. You would see the same situation on a point-to-multipoint OSPF network, which OSPF considers to be a collection of point-to-point links. For example, we could go back and configure the frame relay OSPF network as a point-to-multipoint network by running the ip ospf

network point-to-multipoint command on R1’s serial interface. There would be no DR or BDR elected, and no neighbor statements would be necessary. The OSPF network type point-tomultipoint now offers both a broadcast and nonbroadcast option. We’ll now configure the frame relay network as point-topoint broadcast and then point-topoint nonbroadcast. Point-to-Multipoint Broadcast Network Configuration

This network type doesn’t require use of the neighbor statement, but you can use it to define a cost for a given neighbor. R1(config-if)#ip ospf network point-to-multipoint ? non-broadcast Specify non-broadcast pointto-mpoint network

Note that there is no option for “broadcast” here; that’s because broadcast is the default for point-tomultipoint. R1(config-if)#router ospf 1 R1(config-router)#neighbor 172.12.123.2 ?

OSPF cost

cost

databasefilter

pollinterval

priority

point-tomultipoint neighbor Filter OSPF LSA during synchroniza and floodin for point-to multipoint neighbor

OSPF dead router polli interval OSPF prior of nonbroadcast

neighbor R1(config-router)#neighbor 172.12.123.2 cost ? <1-65535> metric R1(config-router)#neighbor 172.12.123.2 cost 20

Point-to-Multipoint Nonbroadcast Configuration

Network

On the other hand, use of the pointto-multipoint nonbroadcast network type does require the neighbor statement. You can assign costs to

neighbors if you choose, but the neighbors must be statically defined with this network type. R1(config-if)#ip ospf network point-to-multipoint non-broadcast R1(config-router)#neighbor 172.12.123.2 cost 15 R1(config-router)#neighbor 172.12.123.3 cost 25

Running OSPF Networks Over Topologies:

Broadcast NBMA

Just Because You Can Do Something Doesn’t Mean You

Should! We could have used the ip ospf network broadcast command on all the routers connected to the frame network, and as long as there’s a full mesh, technically the network should work and the routers would act as though they were actually communicating through a LAN. In the real world, using the OSPF broadcast network type on an NBMA segment can lead to unpredictable results, and I personally wouldn’t do it. Why spend your time troubleshooting

when you can just stick with the default? The OSPF Virtual Link The OSPF network running over the frame cloud has been restored to the default NBMA and it will remain that type for the remainder of this section. We’ll now add R4 to the network. R4 and R3 will have an adjacency through Area 34, and R4 will have its loopback placed into Area 4. The network segment between R3

and R4 is 172.12.34.0 /24 and runs over an ethernet segment.

This configuration will result in incomplete routing tables, and that brings us to our final OSPF network type. There is no problem with Area 34, since one router with an interface in that area also has a physical interface in Area 0 (R3). However, no router with an interface in Area 4 has a physical interface in Area 0. This means a logical connection to Area 0, a virtual link, must be built. Since R3 has a physical interface in

Area 0, building a virtual link between R3 and R4 will allow full IP connectivity throughout the network. One problem with the current topology is that R1 has no route for R4’s loopback, even though that interface has been placed into the OSPF configuration. R4: router ospf 1 network 4.4.4.4 0.0.0.0 area 4 network 172.23.23.0 0.0.0.31 area 34 R1#show ip route ospf 6.0.0.0/32 is subnetted, 1 subnets O 6.6.6.6 [110/11] via 10.1.1.5, 01:05:45, Ethernet0 172.23.0.0/27 is subnetted, 1 subnets O IA 172.23.23.0 [110/74] via 172.12.123.3, 00:04:14, Serial0

7.0.0.0/32 is subnetted, 1 subnets O 7.7.7.7 [110/11] via 10.1.1.5, 01:05:45, Ethernet0

The area through which the virtual link is built, the transit area, cannot be a stub area of any kind - stub, total stub, or not-so-stubby stub. (If you’re rusty on those, don’t worry there’s a lot of information on these areas coming later in the course!) Here’s the command to create a virtual link: R4(config)#router ospf 1 R4(config-router)#area 34 virtual-link 3.3.3.3

A virtual link must be configured on both ends of the transit area. We’ll go over to R3 now and finish the config. R3(config)#router ospf 1 2d07h: %OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must be virtual-link but not found from 172.23.23.4, Ethernet0 R3(config)#router ospf 1 R3(config-router)#area 34 virtual-link 4.4.4.4 R3(config-router)#^Z 2d07h: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on OSPF_VL0 from LOADING to FULL, Loading Done

A few details worth noting… The virtual link command uses

the remote device’s OSPF RID, not necessarily the IP address on the interface that’s in the transit area. Watch that it’s a very common error. Check that RID! Also, don’t worry about that error message you see in the output from R3. That’s normal and you’ll see it on R3 until you finish building the virtual link. If you see it after you’ve completed the virtual link, you do have a problem.

Always confirm the virtual link with show ip ospf virtual-link. If you’ve configured it correctly, the VL should come up in a matter of seconds. R3#show ip ospf virtual-link Virtual Link OSPF_VL0 to router 4.4.4.4 is up Run as demand circuit DoNotAge LSA allowed. Transit area 34, via interface Ethernet0, Cost of using 10 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:00 Adjacency State FULL (Hello suppressed) Index 2/4, retransmission queue length 1,

number of retransmission 1 First 0x2C8F8E(15)/0x0(0) Next 0x2C8F8E(15)/0x0(0) Last retransmission scan length is 1, maximum is 1 Last retransmission scan time is 0 msec, maximum is 0 msec Link State retransmission due in 3044 msec

Virtual links are actually simple to configure, but for some reason they seem to intimidate people. It’s my experience that the error message highlighted in R3’s output causes a lot of panic, but the only thing that message means is that you’re not finished configuring the virtual link

yet. Knowledge destroys fear and panic. There are three main misconfigurations that cause 99% of virtual link configuration issues: Using the wrong OSPF RID value Trying to use a stub area as the transit area Failure to configure authentication on the virtual

link when Area 0 is using authentication I put that third cause in bold for a good reason. That last one is the one that gets forgotten! A virtual link is really an extension of Area 0, and if Area 0 is running authentication, the virtual link must be configured for it as well. We’ve looked at a lot of OSPFcentric commands in this section, but don’t forget our old friend show ip protocols. Regardless of the network type, that command will

show you the networks being routed, link authentication information, and much more. This is a great command to start with when you’re t-shooting any routing protocol.

Why Not Just Use One Big Area 0 ?

After you hear about the importance of Area 0 for the 10,000th time, you might start thinking, “Why not just put all the routers into one big Area 0? That way, you wouldn’t have to worry about design issues, virtual links, or anything! After all, RIP doesn’t use areas.” That’s true, and it’s also one reason you don’t see RIP in use on many WANs. The use of OSPF areas allows the creation of a hierarchy. Now that sounds great, and Cisco exams love the word “hierarchical”…. but what does it

mean? Here’s the definition of “hierarchical”: adj : classified according to various criteria into successive levels or layers The Benefits OSPF

Of

Multi-Area

That’s what OSPF areas allow you to do - build a layered network. This does help reduce the wear on router resources such as U and memory. Thanks to this layered approach, sometimes a router doesn’t need a huge routing table.

An unnecessarily large routing table can be quite a drain on router resources -- and if there’s only one way for packets to get from a router to multiple destinations, why have a full routing table when a default route will do? A single-area OSPF deployment has other drawbacks. Logically dividing an OSPF network into areas helps in limiting LSU and LSA traffic, since notification of changes in a multi-area OSPF network can be limited to that area only. This limiting of LSAs helps to limit route table recalculations by

the Dijkstra algorithm as well. Summing up, OSPF areas bring us these benefits: More efficient routing via “complete yet concise” routing tables Fewer overall SPF recalculations Less LSU / LSA traffic and associated overhead

Speaking of SPF recalculations, you can see how many times this algorithm has run with the show ip ospf command. If you continually see this number rising, there is an unstable segment in that OSPF area. (There is a lot of output with this command, and it’s worth knowing.) R3#show ip ospf Routing Process “ospf 1” with ID 3.3.3.3 s only single TOS(TOS0) routes s opaque LSA It is an area border router SPF schedule delay 5 secs, Hold time between two SPFs 10 secs Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs Number of external LSA 0. Checksum Sum 0x000000

Number of opaque AS LSA 0. Checksum Sum 0x000000 Number of DCbitless external and opaque AS LSA 0 Number of DoNotAge external and opaque AS LSA 0 Number of areas in this router is 3. 3 normal 0 stub 0 nssa External flood list length 0 Area BACKBONE(0) Number of interfaces in this area is 2 Area has no authentication SPF algorithm executed 10 times Area ranges are Number of LSA 12. Checksum Sum 0x06DBEB Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 3

Flood list length 0 Area 13 Number of interfaces in this area is 1 Area has no authentication SPF algorithm executed 4 times Area ranges are Number of LSA 14. Checksum Sum 0x0822C6 Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 Area 34 Number of interfaces in this area is 1 Area has no authentication SPF algorithm executed 6 times Area ranges are Number of LSA 15. Checksum Sum

0x06BDFB Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0

We’ll take an in-depth look at multiarea OSPF in the next section. OSPF Path Cost Determination When you look at an OSPF routing table, you’ll see two numbers contained in brackets. The first is the istrative distance of OSPF, which is 110. The second

number is the metric used by OSPF, the cost of the path. R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 2d03h, Serial0 33.0.0.0/32 is subnetted, 1 subnets O IA 33.33.33.33 [110/65] via 172.12.123.3, 2d02h, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 2d03h, Serial0 15.0.0.0/24 is subnetted, 1 subnets

OSPF assigns a cost to every OSPF-enabled interface. The interface cost is based on the port’s speed. The default formula OSPF uses to calculate the interface cost

is: 100,000,000 / Bandwidth in bps (NOT kbps!) You’ll see some documentation that lists the first part of that formula as 10 to the 8th power, but I feel it’s easier to 100,000,000 (one hundred million). If you have reason to perform this calculation manually, that the expression for bandwidth here is bits per second (bps), not thousands of bits per second (kbps). Here are some default OSPF

interface costs interface speeds:

for

common

56 kbps = 1785 T1 line = 64 Ethernet = 10 16 MBPS Token Ring = 6 FDDI and 100 MBPS Ethernet =1 In your CCNA studies, you learned that the interface-level bandwidth command can be used to give EIGRP a more accurate picture of the bandwidth of a serial link. This command can also be used with

OSPF. For example, if serial1 on a router was running at 512 kbps rather than the assumed serial link speed of 1544 kbps, the bandwidth command can be used to give OSPF a truer picture of the link speed. OSPF will recalculate the path cost almost immediately after using this command. The cost of an interface can be seen with the show ip ospf interface command. Note that this serial port is shown with an OSPF cost of 64, meaning that OSPF is assuming the

interface is connected to a T1 line. If it were actually connected to a 512 kbps line, the bandwidth command can be used on the interface to reflect this, after which OSPF will recalculate the cost. R1#show ip ospf interface serial0 Serial0 is up, line protocol is up Internet Address 172.12.123.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64 R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#interface serial0 R1(config-if)#bandwidth 512 R1#show ip ospf interface serial0

Serial0 is up, line protocol is up Internet Address 172.12.123.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 195

The new bandwidth setting is about one-third of the T1 speed OSPF was assuming, so the new cost is roughly three times the original cost. The OSPF path with the lowest cost is preferred. Like RIP, OSPF will load-balance over four equal-cost paths by default. You can actually change the value that OSPF uses to base its path cost

calculation on. If you have a very good reason to change it from 100,000,000, you can use the ospf auto-cost reference-bandwidth command to do so. To add to the fun, note that this command asks you to enter the new bandwidth reference value in MBPS: R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#router ospf 1 R2(config-router)#auto-cost referencebandwidth ? <1-4294967> The reference bandwidth in of Mbits per second

One very good reason can be the

addition of Fast and GigEthernet interfaces to your network. Since those interfaces weren’t even around when the costs we spoke of earlier were developed, you may (very) occasionally need to adjust this reference bandwidth especially with GigEthernet interfaces. Comparing OSPF To RIP OSPF is generally considered superior to RIP. Here are just a few of the reasons.

OSPF’s metric is a better measurement of the actual distance to a remote network. OSPF uses a composite metric, cost, where RIP uses the sole metric of hop count. OSPF does not impose a limit on when networks are “reachable” or “unreachable”, where RIP has a maximum hop count of 15 to combat the counting to infinity issue. OSPF s VLSM, where RIPv1 does not. RIPv2 does,

though. VLSM allows a protocol to have more efficient utilization of IP addresses than a protocol that does not. OSPF utilizes network bandwidth much more efficiently than RIP. OSPF multicasts updates only upon initial adjacency, a network change, or expiration of a 30-minute period where there have been no network changes. RIPv1 broadcasts full routing tables every 30

seconds. RIPv2 does use multicasting, but still sends full routing tables every 30 seconds. (A single RIP update can contain a maximum of only 25 routes, so a larger network would require multiple update packets.) OSPF converges much more quickly than either version of RIP. OSPF allows you to create a hierarchical scheme by using multiple areas. Neither version of RIP offers this capability.

The main drawback of OSPF, especially in comparison to RIP, is that OSPF can be a lot harder on router resources. OSPF operations requires more U and memory than RIP does. Troubleshooting Adjacencies

OSPF

You know from your CCNA studies that OSPF adjacencies go through the following states: Down, Attempt, Init, 2-Way, Exstart, Exchange, Loading, and Full.

Here’s a quick review of what’s going on in each state: Down - No hellos received from that neighbor Attempt - Unicast hello packets are being sent to the neighbor. You’ll only see this in OSPF NBMA networks, since they’re configured with neighbor commands. Init - First Hello packet has been received from this neighbor. 2-Way - Each router has received a Hello packet containing its own

RID, meaning that bidirectional communication is in place. When a router receives a Hello packet containing its own RID, that’s the remote router’s way of saying “I received the Hello packet you sent me earlier.” Exstart - Following DR / BDR election, the exchange of link state database information can begin. The router with the highest OSPF RID will begin the exchange and increment the initial sequence number, which is determined during this stage.

Exchange - Database descriptor (DBD) packets are exchanged; these packets contain a description of the link state database. Loading - Routers now send Link State Request (LSR) packets to their potential neighbor. Full - Router databases are synchronized and the adjacency has been formed. Always use the show ip neighbor and show ip interface commands to ensure OSPF adjacencies reach the

ospf ospf your Full

stage. You can see neighbor adjacencies with either command. Show ip ospf neighbor gives you the basic information regarding the adjacency, while the interface command gives you more detailed information.

R1#show ip ospf interface ethernet 0 Ethernet0 is up, line protocol is up Internet Address 100.1.1.1/24, Area 0 Process ID 1, Router ID 10.1.1.1, Network Type BROADCAST,Cost: 10 Transmit Delay is 1 sec, State BDR, Priority 1

Designated Router (ID) 19.1.1.1, Interface address 100.1.1.5 Backup Designated router (ID) 10.1.1.1, Interface address 100.1.1.1 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:06 Index 2/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 19.1.1.1 (Designated Router) Suppress hello for 0 neighbor(s)

Show ip ospf interface is excellent for spotting issues related to hello

and dead timers. If you don’t see the problem with the show command, you can run debug ip ospf adj to see the adjacencies form - or not form! Here is just part of the output from this command, and you can see the different OSPF states the adjacency goes through on the way to Full. 4d22h: OSPF: Rcv DBD from 10.1.1.1 on Serial1 seq 0x5DD opt 0x42 flag 0x7 len 32 mtu 1500 state INIT 4d22h: OSPF: 2 Way Communication to 10.1.1.1 on Serial1, state 2WAY 4d22h: OSPF: Send DBD to 10.1.1.1 on Serial1 seq 0x14EC opt 0x42 flag 0x7 len 32

4d22h: OSPF: First DBD and we are not SLAVE 4d22h: OSPF: Rcv DBD from 10.1.1.1 on Serial1 seq 0x14EC opt 0x42 flag 0x2 len 9 2 mtu 1500 state EXSTART 4d22h: OSPF: NBR Negotiation Done. We are the MASTER 4d22h: OSPF: Send DBD to 10.1.1.1 on Serial1 seq 0x14ED opt 0x42 flag 0x3 len 92 4d22h: OSPF: Database request to 10.1.1.1 4d22h: OSPF: sent LS REQ packet to 13.13.13.1, length 12 4d22h: OSPF: Rcv DBD from 10.1.1.1 on Serial1 seq 0x14ED opt 0x42 flag 0x0 len 3 2 mtu 1500 state EXCHANGE 4d22h: OSPF: Send DBD to 10.1.1.1 on Serial1 seq 0x14EE opt 0x42 flag 0x1 len 32 4d22h: OSPF: Rcv DBD from 10.1.1.1 on

Serial1 seq 0x14EE opt 0x42 flag 0x0 len 3 2 mtu 1500 state EXCHANGE 4d22h: OSPF: Exchange Done with 10.1.1.1 on Serial1 R22h: OSPF: Synchronized with 10.1.1.1 on Serial1, state FULL 4d22h: %OSPF-5-ADJCHG: Process 1, Nbr 10.1.1.1 on Serial1 from LOADING to FULL, Loading Done 4d22h: OSPF: Build router LSA for area 0, router ID 172.12.123.3, seq 0x80000005

In short, for OSPF adjacencies to form, the following must be agreed upon by the potential neighbors: Hello and dead timers

The Area ID Stub area flag setting (on or off) Link authentication (use is optional, but if used, both neighbors must agree on the ) The process number does not have to be agreed upon - that value is locally significant only. (Yeah, I know I said that before. I’m saying it again. :) ) Adjacency Behavior With Multiple OSPF Routers On A Broadcast Segment

When you have more than two OSPF routers on a broadcast segment, you’ll get some interesting adjacency results. I get asked about this one often in Facebook and Twitter (@ccie12933, by the way), so I thought I’d include it here.

The election has already taken

place, with R1 as the DR, R2 as the BDR, and R3 and R4 as the DROTHERS. The OSPF neighbor tables on R1 and 2 look like you would expect, but the DROthers’ tables look a little odd.

You’ll hear about OSPF adjacencies “stuck in 2-way”, and many people think that’s what is happening here, but it’s not. The

DROTHERS are never going to finish forming that adjacency. We could come back tomorrow and they would still be in 2-way! This is actually a default behavior of OSPF that helps to cut down on the number of LSAs being transmitted on a broadcast segment with more than 2 routers. The only routers that will have an adjacency to all other routers on the segment are the DR and BDR. Each DROther will have a full adjacency with both the DR and BDR, but never with another DROther.

For this reason, any router that detects a change in the network will multicast news of this change to the DR and BDR only - the remaining DROthers will then learn about it from the DR. Now that fundamentals cold…

we have the of OSPF down

… let’s tackle multiarea OSPF! Recommended Videos:

OSPF

YouTube

OSPF Router Types: http://www.youtube.com/watch? v=QNQCy-LQLFY OSPF Hub-And-Spoke Checklist http://www.youtube.com/watch? v=46x--GIiKZk OSPF Total Stub Areas: http://www.youtube.com/watch? v=DwZIRMfTaE4

OSPF Stub Areas In Action: http://www.youtube.com/watch? v=rHNXyNJpfpM OSPF ASBRs: http://www.youtube.com/watch? v=hGrbyb6p4MI My YouTube Channel Page:

http://www.youtube.com//ccie12 Free CCNP ROUTE Video Boot

Camp on OSPF stub areas and route redistribution: http://www.udemy.com/ccnp-routeboot-camp-redistribution-and-ospfstub-areas/

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

Multi-Area OSPF And Route Summarization

OSPF Design Guidelines Just about every OSPF configuration you work with in the real world is going to be a multiarea setup, for reasons we touched on in the previous section and that we’ll add to here. Cisco exam success lies in knowing the details, and that applies

especially to OSPF, because there are a lot of details to learn with multi-area OSPF. As with all things Cisco, learning it “piece by piece” instead of looking at this section as a whole will help you master those details for your exam and your career. Those of you with an eye on the CCIE will truly have to master the details of OSPF! Before we begin to build our multiarea OSPF configuration, there are some design rules that Cisco would like you to keep in mind. Design

rules are generally subjective, but these OSPF design rules are particularly important since they are designed to keep the demand on the router’s U and memory resources to a reasonable level. (The term “reasonable level” is subjective as well - generally, your more powerful routers will be at the core of your network while the lesser routers will be at the outskirts.) No router should be in more than three areas.

No area should contain more than 50 routers. No router should have more than 60 neighbors. A router can be a DR or BDR for more than one network segment, but be careful that the router is not overworked by doing so. Do not run more than one OSPF process on an Area Border Router.

Of all the OSPF design rules, it’s my experience that you really have to watch the one regarding having too many routers in a single area. This ends up causing more LSA traffic than you really need, which in turn means you’ve got more routers having to recalculate their routing tables more and more often, which in turn puts an unnecessary load on the U of the routers. Why Build Multiple Areas? Using a hierarchical, multi-area

approach to OSPF delivers these benefits: Route summarization is made possible (and simpler) through a layered approach to address allocation. In turn, route summarization helps keep routing tables concise yet complete, which lessens the load on a router’s U during the routing process. Smaller routing tables are better than larger routing tables, but they still have to be

complete! Using multiple OSPF areas helps us accomplish that. By creating multiple areas, LSA flooding upon a change in the network is localized. For example, LSA Types 1 and 2 don’t leave the local area. This results in fewer Link State Updates traveling across the OSPF network as a whole. (If you’re rusty on LSA types, don’t worry, we’ll go over those in this section!)

As a result, fewer Shortest Path First (SPF) recalculations are needed. Let’s look at how the creation of OSPF stub and total stub areas help to deliver these benefits. Stub And Total Stub Areas Area 0 is the backbone area of an OSPF configuration. When creating a multi-area OSPF network, every non-backbone area must contain a router that has a physical or logical connection (virtual link) to Area 0.

Traffic going from one nonbackbone area to another nonbackbone area must cross Area 0. For that reason, Area 0 is generally going to be found at the center, or core, of the network. The network we will build in this section will have Area 0 at the very center. We’ll start by placing the serial0 interface on R1, R2, and R3 into Area 0. The network 172.12.123.0 /24 is running over the frame, with each router using its router number as the 4th octet. The loopback of each router will be placed into an

area numbered using the router number; that is, R1’s loopback, 1.1.1.1, will be placed into Area 1, and so forth. This is a hub-and-spoke network, so the special considerations you learned for this topology in the “LS Protocols And Single-Area OSPF” sections must be put into action: The hub will need neighbor statements The hub must become the DR

The spokes must not take part in the DR/BDR election If you’re running this lab, be sure to check your connectivity across the frame network before applying the OSPF config - that can save you a lot of unnecessary troubleshooting.

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

R2(config)#interface serial0 R2(config-if)#ip ospf priority 0

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

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

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

with show ip ospf neighbor.

Both R2 and R3 see R1 as the DR, and R1 sees both R2 and R3 as “DROTHER”, indicating those two routers are neither the DR nor the

BDR. Also note that the neighbor IDs are the neighbor’s RIDs, and as we would expect at this point, the RID for each router is the router’s single loopback address. Since our three non-backbone areas all have a router physically connected to Area 0, the configuration is valid and each router has a route to both remote loopback addresses. R1#show ip route ospf 2.0.0.0/32 is subnetted, 1 subnets O AI 2.2.2.2 [110/65] via 172.12.123.2, 00:00:00, Serial0 3.0.0.0/32 is subnetted, 1 subnets O AI 3.3.3.3 [110/65] via 172.12.123.3,

00:00:00, Serial0 R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O AI 1.1.1.1 [110/65] via 172.12.123.1, 00:00:23, Serial0 3.0.0.0/32 is subnetted, 1 subnets O AI 3.3.3.3 [110/65] via 172.12.123.3, 00:00:23, Serial0 R3#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O AI 1.1.1.1 [110/65] via 172.12.123.1, 00:01:59, Serial0 2.0.0.0/32 is subnetted, 1 subnets O AI 2.2.2.2 [110/65] via 172.12.123.2, 00:00:07, Serial0

The routes to the remote loopbacks are all marked “O IA”. The “O” refers to OSPF, and the “IA” refers

to an inter-area route - a route to a destination located in another OSPF area. Since each router borders Area 0 and connects another area to Area 0, each router in the current network is an ABR - an Area Border Router. This is confirmed in this abbreviated output of show ip ospf : R1#show ip ospf Routing Process “ospf 1” with ID 1.1.1.1 s only single TOS(TOS0) routes s opaque LSA It is an area border router

R2#show ip ospf Routing Process “ospf 1” with ID 2.2.2.2

s only single TOS(TOS0) routes s opaque LSA It is an area border router

R3#show ip ospf Routing Process “ospf 1” with ID 3.3.3.3 s only single TOS(TOS0) routes s opaque LSA It is an area border router

Now we’ll bring in another router and another area. R4 is connected to R3 via the segment 172.34.34.0 /24, and both will have their Ethernet interfaces placed into Area 34.

R3(config)#router ospf 1 R3(config-router)#network 0.0.0.255 area 34

R4(config)#router ospf 1 R4(config-router)#network

172.34.34.0

172.34.34.0

0.0.0.255 area 34

Always new adjacencies!

R4 now has an adjacency with R3. Let’s take a look at R4’s OSPF routing table: R4#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/75] via 172.34.34.3, 00:01:03, Ethernet0 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/75] via 172.34.34.3, 00:01:03, Ethernet0 3.0.0.0/32 is subnetted, 1 subnets

O IA 3.3.3.3 [110/11] via 172.34.34.3, 00:01:03, Ethernet0 172.12.0.0/24 is subnetted, 1 subnets O IA 172.12.123.0 [110/74] via 172.34.34.3, 00:01:03, Ethernet0

All the OSPF routes on R4 are OSPF inter-area routes, as indicated by O IA. We can also see that the next-hop IP address is the same for all four routes. It would have to be, since there’s only one exit point for any data R4 sends to any of these destinations. It seems like a bit of a waste of time to have all of these specific routes in the routing table when they’ve all got

the same next-hop IP address, doesn’t it? Let’s keep that in mind. We’re also going to bring some more routes into this OSPF configuration via route redistribution. Route redistribution is the process of taking routes known by another method -whether that be another routing protocol, another instance of the same protocol, or a connected / static route - and placing them into another protocol.

Routes that are being redistributed into another protocol are sometimes referred to as being injected into that domain. R5 will now be added to our network. R5 and R1 are both on the 15.0.0.0 /8 network, and are both running RIP version 2. R5 has three loopback addresses - 5.1.1.1 /8, 6.1.1.1 /8, and 7.1.1.1. /8. R5 will all its loopback addresses via RIPv2. R1 will run RIP only on the 15.0.0.0/8 network.

R5(config)#router rip R5(config-router)#version 2 R5(config-router)#no auto-summary

R5(config-router)#network 5.0.0.0 R5(config-router)#network 6.0.0.0 R5(config-router)#network 7.0.0.0 R5(config-router)#network 15.0.0.0 R1(config)#router rip R1(config-router)#version 2 R1(configrouter)#no auto R1(config-router)#network 15.0.0.0

R1 will see all of R5’s loopbacks in its RIP routing table. R1 also has a route to R2’s loopback, R3’s loopback, and the 172.34.34.0 /24 network in its OSPF table. R1#show ip route rip R 5.0.0.0/8 [120/1] via 15.1.1.5, 00:00:03, Serial1 R 6.0.0.0/8 [120/1] via 15.1.1.5, 00:00:03, Serial1 R 7.0.0.0/8 [120/1] via 15.1.1.5, 00:00:03,

Serial1

R1#show ip route ospf 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/65] via 172.12.123.2, 00:04:17, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 00:04:17, Serial0 172.34.0.0/24 is subnetted, 1 subnets O IA 172.34.34.0 [110/74] via 172.12.123.3, 00:04:17, Serial0

On R1, the RIP routes and 15.0.0.0/8 (a directly connected network) will be redistributed into OSPF, and the OSPF routes along with 172.12.123.0 /24 (a directly connected network) will be

redistributed into RIP. The directly connected routes have to be redistributed along with the dynamically learned routes, or hosts in the RIP domain could not ping host addresses in the OSPF domain. Forgetting to redistribute the connected networks is a common error in route redistribution. The remote protocol’s routes will be seen, but pings won’t go through. R1(config)#router ospf 1 R1(config-router)#redistribute connected % Only classful networks will be redistributed R1(config-router)#redistribute connected

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

Note that when the connected networks and RIP routes were redistributed into OSPF, the subnets option had to be used to allow subnet redistribution. Also, when redistributing connected networks and OSPF routes into RIP, a seed metric had to be supplied. The seed metric is a “starting metric” for the paths being

redistributed and is required for routes being redistributed into RIP and EIGRP. OSPF uses a default seed metric of 20, so no metric has to be set for the connected and RIP subnets redistributed into OSPF. The OSPF router that redistributes routes into the OSPF domain is the Autonomous System Border Router (ASBR). If a router is an ABR and / or ASBR, you’ll see that in the output of show ip ospf. You’ll also see the source of the routes being redistributed. Note that a router can be both an ABR and ASBR, as R1 is here.

R1#show ip ospf Routing Process “ospf 1” with ID 1.1.1.1 s only single TOS(TOS0) routes s opaque LSA It is an area border and autonomous system boundary router Redistributing External Routes from, connected, includes subnets in redistribution rip, includes subnets in redistribution

To see all the ABRs and ASBRs, run show ip ospf border-routers. Running this command on R3 verifies that R2 is an ABR and R1 is an ABR/ASBR: R3#show ip ospf border-routers OSPF Process 1 internal Routing Table

Codes: i - Intra-area route, I - Inter-area route i 1.1.1.1 [64] via 172.12.123.1, Serial0, ABR/ASBR, Area 0, SPF 38 i 2.2.2.2 [64] via 172.12.123.2, Serial0, ABR, Area 0, SPF 38

At this point, R5 should have all the OSPF routes in its routing table, and should be able to ping any address in the OSPF configuration. Here is R5’s RIP routing table, followed by pings of all remote loopback interfaces and R4’s Ethernet0 interface. Note there is no special code for routes being introduced into RIP via route redistribution. “R” is “R”.

R5#show ip route rip 1.0.0.0/32 is subnetted, 1 subnets R 1.1.1.1 [120/1] via 15.1.1.1, 00:00:20, Ethernet0 2.0.0.0/32 is subnetted, 1 subnets R 2.2.2.2 [120/1] via 15.1.1.1, 00:00:20, Ethernet0 3.0.0.0/32 is subnetted, 1 subnets R 3.3.3.3 [120/1] via 15.1.1.1, 00:00:20, Ethernet0 172.34.0.0/24 is subnetted, 1 subnets R 172.34.34.0 [120/1] via 15.1.1.1, 00:00:20, Ethernet0 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks R 172.12.123.0/24 [120/1] via 15.1.1.1, 00:00:20, Ethernet0

R5# ping 1.1.1.1

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

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

R5#ping 3.3.3.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.3.3.3,

timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/70/72 ms


R5 can indeed see the OSPF routes and can ping all three remote loopbacks. Notice that there’s no special code next to a RIP route that

was originally learned via redistribution - the only RIP route code is “R”. Let’s take a look at R4’s OSPF routing table, and see if R4 can ping R5’s loopbacks. R4#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/75] via 172.34.34.3, 00:33:33, Ethernet0 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/75] via 172.34.34.3, 00:33:33, Ethernet0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/11] via 172.34.34.3, 00:33:33, Ethernet0 5.0.0.0/32 is subnetted, 1 subnets O E2 5.1.1.1 [110/20] via 172.34.34.3,

00:33:21, Ethernet0 6.0.0.0/32 is subnetted, 1 subnets O E2 6.1.1.1 [110/20] via 172.34.34.3, 00:33:21, Ethernet0 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks O IA 172.12.123.0/24 [110/74] via 172.34.34.3, 00:33:33, Ethernet0 7.0.0.0/32 is subnetted, 1 subnets O E2 7.1.1.1 [110/20] via 172.34.34.3, 00:33:21, Ethernet0 15.0.0.0/24 is subnetted, 1 subnets O E2 15.1.1.0 [110/20] via 172.34.34.3, 00:33:32, Ethernet0

R4#ping 5.1.1.1 Type escape sequence to abort.

(Ever notice the router doesn’t tell

you the ping escape sequence? It’s TWICE, in rapid succession.) Sending 5, 100-byte ICMP Echos to 5.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/72 ms

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

R4#ping 7.1.1.1

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

In addition to the O IA routes, we now see some O E2 routes as well. O E2 routes are OSPF External Type 2 routes, and these are routes that were originally learned via redistribution. We’ll concentrate on the size of this routing table, what impact that could have, and how we can possibly shrink this table a bit without sacrificing connectivity.

Examining R4’s OSPF routing table, we see that every single one of the external routes has one thing in common -- the next-hop IP address. O E2 5.1.1.1 [110/20] via 172.34.34.3, 00:33:21, Ethernet0 6.0.0.0/32 is subnetted, 1 subnets O E2 6.1.1.1 [110/20] via 172.34.34.3, 00:33:21, Ethernet0 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks O E2 7.1.1.1 [110/20] via 172.34.34.3, 00:33:21, Ethernet0 15.0.0.0/24 is subnetted, 1 subnets O E2 15.1.1.0 [110/20] via 172.34.34.3, 00:33:32, Ethernet0

It’s a waste of time and resources

for R4 to look through all these routes for packets with a destination external to OSPF, because the next hop is going to be the same -172.34.34.3. OSPF allows us to substitute a single default route for all external destinations by making Area 34 a stub area. Configuring an area as stub prevents LSA Type 5s from flooding the stub area. It’s not enough to configure Area 34 as a stub on R4 or R3. Every router in the area must agree that this is a stub area, or adjacencies will drop.

Configuring an area as stub is referred to as “setting the stub flag” or “setting the stub bit”. Watch what happens when an area is configured as stub on R3, but not R4: R3#conf t Enter configuration commands, one per line. End with CNTL/Z. R3(config)#router ospf 1 R3(config-router)#area 34 stub 4d06h: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Ethernet0 from FULL to DOWN, Neighbor Down: Dead timer expired

Configuring the area as stub on R4 will bring the adjacency back up: R4#conf t Enter configuration commands, one per line. End

with CNTL/Z. R4(config)#router ospf 1 R4(config-router)#area 34 stub

Area 34 is now a stub area. Look at R4’s OSPF routing table: R4#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/75] via 172.34.34.3, 00:01:07, Ethernet0 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/75] via 172.34.34.3, 00:01:07, Ethernet0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/11] via 172.34.34.3, 00:01:07, Ethernet0 172.12.0.0/24 is subnetted, 1 subnets O IA 172.12.123.0 [110/74] via

172.34.34.3, 00:01:07, Ethernet0 O*IA 0.0.0.0/0 [110/11] via 00:01:07, Ethernet0

172.34.34.3,

With that simple config, the size of the routing table has been cut in half. The E2 routes have been replaced with a single default route, as indicated by the asterisk. R5’s loopback addresses can still be pinged: R4#ping 5.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/71/80 ms



The cost for the default route can be adjusted with the default-cost command. On R3, we’ll change the

OSPF metric for the default route to 20, which should give it a total cost of 30 on R4: R3(config)#router ospf 1 R3(config-router)#area 34 default-cost 20

R4#show ip route ospf O*IA 0.0.0.0/0 [110/30] via 30.1.1.3, 00:00:09, Ethernet0

The routing table is half its previous size while still allowing full connectivity. We can take this one step further, since the four nondefault inter-area routes all have the same next-hop IP address as well. OSPF allows the configuration of a

total stub area, where all external and inter-area routes are replaced with a single default route. One single addition to R3 will do this. The no-summary option added to the ABR of the stub area will make this a total stub area. Making an area a total stub prevents LSA types 3, 4, and 5 from flooding into the area. The ABR is the only router that needs the no-summary option enabled. no-summary doesn’t have to be added to the other routers in the area, but they still have to be

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

A little “theory vs. real-world” discussion is merited here. In the real world, you’ll often see OSPF total stub areas that have every router in the total stub configured with no-summary. That doesn’t hurt anything, but only the ABR needs that option enabled. Personally, on the exam and in real life, I would only configure nosummary on the ABR.

Where R4 had nine OSPF inter-area and external routes, it now has a single default route for all those destinations: R4#show ip route ospf O*IA 0.0.0.0/0 [110/30] 00:07:26, Ethernet0

via

172.34.34.3,

Now we’ve seen that with an OSPF stub area, you can have routes to other destinations in the area (O), inter-area routes (O IA), and a default inter-area route to reach the external destinations (O *IA). With a total stub area, you’ll see only routes to other networks in the

total stub area (O) and a single default route used to reach all other destinations (O *IA). If we add a loopback to R3 in this configuration and place it in Area 34, R4 will see it as an intra-area route and it will have a specific entry in the OSPF table. R3(config)#int loopback33 R3(config-if)#ip address 33.33.33.33 255.255.255.255 R3(config-if)#router ospf 1 R3(config-router)#network 33.33.33.33 0.0.0.0 area 34 R4#show ip route ospf 33.0.0.0/32 is subnetted, 1 subnets O 33.33.33.33 [110/11] via 172.34.34.3, 00:00:03, Ethernet0

O*IA 0.0.0.0/0 [110/30] 00:00:03, Ethernet0

via

172.34.34.3,

You can take a good idea too far, though. If stub areas are so great, let’s make Area 0 a stub! After all, R2 and R3 only have one possible next hop to the external destinations, and that’s through R1. So let’s try that… R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router ospf 1 R1(config-router)#area 0 stub OSPF: Backbone can not be configured as stub area

Whoops.

One of the things I like most about Cisco equipment is that nine out of ten times, the router or switch is going to stop you from doing something you really shouldn’t do. Or at the very least, you’ll be warned! Here, the router won’t let you make Area 0 a stub area, because Area 0 is prohibited from being a stub or total stub. The CCNP ROUTE exam probably won’t be so kind as to tell you that. “Not So Stubby Stub Areas”

The final OSPF area type is an NSSA, short for “not-so-stubby stub area”. An NSSA is a stub area that contains a limited number of external routes. An NSSA is the only area that will use a Type 7 LSA, which you’ll read more about in the LSA review later in this section. This is a highly specialized OSPF area type, and it’s not common, but they are out there. Let’s take a look at the commands to configure a stub NSSA and total stub NSSA. We’ll now add another loopback to

R3 and inject it into the OSPF domain with the redistribute connected subnets command. R3(config)#int loopback14 R3(config-if)#ip address 255.255.255.255

14.14.14.14

R3(config)#router ospf 1 R3(config-router)#redistribute subnets

connected

R1 will see the route as an E2 route… R1#show ip route ospf 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/65] via 172.12.123.2, 00:03:11, Serial0 33.0.0.0/32 is subnetted, 1 subnets

O IA 33.33.33.33 [110/65] via 172.12.123.3, 00:03:11, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 00:03:11, Serial0 172.34.0.0/24 is subnetted, 1 subnets O IA 172.34.34.0 [110/74] via 172.12.123.3, 00:03:12, Serial0 14.0.0.0/32 is subnetted, 1 subnets O E2 14.14.14.14 [110/20] via 172.12.123.3, 00:01:48, Serial0

…but R4 will not, since R4 is in a total stub area. R4#show ip route ospf 33.0.0.0/32 is subnetted, 1 subnets O 33.33.33.33 [110/11] via 172.34.34.3, 01:02:10, Ethernet0 O*IA 0.0.0.0/0 [110/30] via 172.34.34.3, 01:02:10, Ethernet0

We’ll remove the total stub statement from R3 and the stub statement from R4, and replace both statements with area 34 nssa, which will make Area 34 a not-sostubby stub area. Note that the adjacencies reset during this process. R3(config-router)#no area 34 stub no-summary 01:40:26: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Ethernet0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset R3(config-router)#area 34 nssa R4(config)#router ospf 1 R4(config-router)#no area 34 stub

R4(config-router)#area 34 nssa 01:41:20: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Ethernet0 from LOADING to FULL, Loading Done

R4 now sees the route as N2, which is an NSSA External route. R4#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/75] via 172.34.34.3, 00:00:14, Ethernet0 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/75] via 172.34.34.3, 00:00:14, Ethernet0 33.0.0.0/32 is subnetted, 1 subnets O 33.33.33.33 [110/11] via 172.34.34.3, 00:00:14, Ethernet0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/11] via 172.34.34.3, 00:00:14, Ethernet0

172.12.0.0/24 is subnetted, 1 subnets O IA 172.12.123.0 [110/74] via 172.34.34.3, 00:00:14, Ethernet0 14.0.0.0/32 is subnetted, 1 subnets O N2 14.14.14.14 [110/20] via 172.34.34.3, 00:00:14, Ethernet0

We can configure Area 34 as a “not-so-stubby total stub” area by adding the no-summary command to R3’s NSSA statement. Note that the adjacency again goes down. R3(config)#router ospf 1 R3(config-router)#area 34 nssa ?

defaultinformationoriginate

Origina Type 7 default NSSA a

noredistribution

no-summary

No redistri into this NSSA a Do not summar LSA int NSSA

R3(config-router)#area 34 nssa no-summary 01:43:51: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Ethernet0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset 01:43:53: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Ethernet0 from LOADING to FULL, Loading Done

R4 now has a default route in addition to the N2 route. R4#show ip route ospf 33.0.0.0/32 is subnetted, 1 subnets O 33.33.33.33 [110/11] via 172.34.34.3, 00:00:25, Ethernet0 14.0.0.0/32 is subnetted, 1 subnets O N2 14.14.14.14 [110/20] via 172.34.34.3, 00:00:25, Ethernet0 O*IA 0.0.0.0/0 [110/30] via 172.34.34.3, 00:00:25, Ethernet0

OSPF Route Types You saw several different OSPF route types in the previous section. Taking a look at the following partial output of show ip route, let’s

go over the meaning of each type. 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

O - A route to a destination in the same area. A loopback with IP address 33.33.33.33 has been added to Area 34, and R4 sees it as an “O” route. R4#show ip route ospf 33.0.0.0/32 is subnetted, 1 subnets O 33.33.33.33 [110/11] via

172.34.34.3, 00:00:03, Ethernet0

O IA - A route to a destination in another OSPF area. Before making Area 34 a total stub area, R4 had a few of these: R4#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/75] via 172.34.34.3, 00:01:03, Ethernet0 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/75] via 172.34.34.3, 00:01:03, Ethernet0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/11] via 172.34.34.3, 00:01:03, Ethernet0 172.12.0.0/24 is subnetted, 1 subnets O IA 172.12.123.0 [110/74] via 172.34.34.3, 00:01:03, Ethernet0

O E2 AND O E1: Both codes indicate external routes. OSPF external routes are routes learned via redistribution. Before making Area 34 a stub area, R4 had these E2 routes: O E2 5.1.1.1 [110/20] via 172.34.34.3, 00:33:21, Ethernet0 6.0.0.0/32 is subnetted, 1 subnets O E2 6.1.1.1 [110/20] via 172.34.34.3, 00:33:21, Ethernet0 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks O E2 172.12.21.0/30 [110/20] via 172.34.34.3, 00:33:32, Ethernet0 O E2 7.1.1.1 [110/20] via 172.34.34.3, 00:33:21, Ethernet0 15.0.0.0/24 is subnetted, 1 subnets O E2 15.1.1.0 [110/20] via 172.34.34.3,

00:33:32, Ethernet0

The difference between E2 and E1 routes is that the metric of an E2 route only reflects the cost of the path between the ASBR and the final destination. The cost between R4 and the ASBR (R1) is not considered in the metric. The metric of an E1 route reflects the OSPF cost of the entire path from the local router to the final destination. To see the difference, we’ll look at two of the original external routes

in R4’s routing table. E2 is the default: O E2 5.1.1.1 [110/20] via 172.34.34.3, 00:33:21, Ethernet0 O O E2 6.1.1.1 [110/20] via 172.34.34.3, 00:33:21, Ethernet0

The metric is 20. This is the cost from the ASBR to the destination. The cost of the path from R4 to the ASBR, R1, is not included in this metric. To redistribute routes into OSPF as E1 routes, use the metric-type option: R1(config)#router ospf 1

R1(config-router)#redistribute rip subnets metric-type ? 1 Set OSPF External Type 1 metrics 2 Set OSPF External Type 2 metrics R1(config-router)#redistribute metric-type 1

rip

subnets

Look at the same two routes in R4’s routing table, which are now displayed as E1 routes: O E1 5.1.1.1 [110/94] via 172.34.34.3, 00:04:13, Ethernet0 6.0.0.0/32 is subnetted, 1 subnets O E1 6.1.1.1 [110/94] via 172.34.34.3, 00:04:14, Ethernet0

The routes now show a larger metric - 94. That’s because this is

the OSPF cost for the entire path from R4 to each of the destination networks. There are two other route types in that OSPF table that merit discussion: N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 These route types will obviously be found only in NSSAs. It can be a little confusing to keep up with the different route types that can be found in stub, total stub, and not-sostubby areas, so here’s a summary:

Stub areas can contain O, O IA, and O* IA routes. Total stub areas can contain O and O* IA routes only. NSSAs can contain O, O IA, O N2, O* N2, O N1, and O* N1 routes. OSPF Router Types We’ve mentioned the ABR and ASBR, but there are several other OSPF router types you must know and be able to identify by sight. Commands such as show ip ospf

help us identify ABRs and ASBRs on a working network, but since you can’t carry a router into the CCNP ROUTE exam room, we better know these router types by sight. You must be able to look at a network diagram and determine the OSPF router type(s) - and notice the (s). An OSPF router can fill more than one role. Using our current OSPF network, let’s take a look at each OSPF router type.

Internal Routers and Backbone

Routers These two definitions are simple, but similar. An OSPF internal router is a router that has all its interfaces in a single area. That area does not have to be Area 0. In this network, R4 is an internal router. If we configure a loopback on R4 and place it in any area other than Area 4, R4 would no longer be an internal router. Backbone routers have at least one interface in Area 0. That’s the only requirement. Our OSPF network contains three backbone routers;

R1, R2, and R3. It’s important to that routers can fill both of these roles. Here is an example of a network where both routers are internal routers and backbone routers:

Both routers have all their interfaces in a single area, so they’re both internal routers. They also have at least one interface in Area 0, so they’re both backbone routers. Area Border Routers An ABR is a router that has one interface in Area 0 and another in a non-backbone area. In our OSPF network, R1, R2, and R3 are all ABRs. All ABRs are backbones, but not all backbones are ABRs. Be careful when identifying OSPF router types!

Autonomous Routers

System

Border

An ASBR is an OSPF router that takes routes learned via another source and places those routes into the OSPF domain. In our OSPF network, R1 is an ASBR. Any route redistribution involving OSPF must be configured manually. You can see the ABRs and ASBRs of any given OSPF area by running show ip ospf border-routers. OSPF LSA Types

With all the different OSPF configurations and area types, it won’t surprise you to find that there are different LSA types being sent around an OSPF network. The contents of a router’s OSPF database are displayed with show ip ospf database and are sorted by area and LSA type. The OSPF database contents shown in this section are from the previous lab. R3#show ip ospf database

OSPF LSA Type 1:

These router link ments are generated by each router for every area the router has a link in. These are flooded to a single area only. The name is the recipe - LSA Type 1s contain the “router link states” for this particular router. OSPF LSA Type 2:

Type 2 LSAs are sent out by the DR

only. You can see that the only Type 2 R3 has is from Advertising Router 1.1.1.1, the OSPF RID of R1. Since LSA types 1 and 2 are confined to a single area, this is another way in which multiple-area OSPF helps to reduce the load on router resources. If you have one large OSPF area, every router in the area would receive every single Type 1 and Type 2 LSA. OSPF LSA Type 3:

These summary link ments are generated by ABRs and describe inter-area routes (notice that none of these links are in Area 0). They summarize the networks from one area to another. Type 3 LSAs are not flooded into a total stub area. OSPF LSA Type 4:

Type 4 LSAs are generated by ABRs only and describe the path to the ASBR. Type 4 LSAs are not flooded into a total stub area. OSPF LSA Type 5:

Type 5 LSAs describe links external to the OSPF domain. Notice that these four links are the links in the RIP domain and the advertising router is the ASBR, R1. A Type 5 LSA is generated by an

ASBR and is flooded to all areas except stub and total stub areas. If we look at the entire OSPF database of R4, which is in a total stub area, there are no Type 5 LSAs:

This is really a small OSPF database, but it still allows R4 to reach every destination in our OSPF network. Not only does configuring Area 34 as a total stub

make the OSPF routing table smaller, it also keeps the database smaller. That’s another way multiarea OSPF lessens the load on a router’s memory and U. LSA Type 6s are a “specialty” kind of LSA that are generated only by routers using Multicast Extensions To OSPF (MOSPF). MOSPF isn’t in widespread use, but it doesn’t hurt to know about LSA Type 6 while we’re learning all the other ones! Type 7 LSAs are generated only by an ASBR into a not-so-stubby area.

NSSAs act as stub areas, but have some of the more-specific routes rather than just a default route. These Type 7 LSAs are flooded throughout the NSSA, but don’t leave that area; they are actually converted into Type 5 LSAs and are then sent out of the NSSA. Here’s a summary of what router types send the different LSA types: LSA Type 1: All routers LSA Type 2: All DRs LSA Type 3, 4: All ABRs LSA Type 5, 7: ASBRs only

LSA Type 6: Reserved for MOSPF OSPF Route Summarization It’s a great idea to keep your routing table complete and concise. OSPF stub and total stub areas help us do that by replacing external and interarea routes with default routes, but it’s not always possible to configure stub and total stub areas. Area 0 can never be a stub or total stub, and if an area is serving as a transit area for a virtual link, that area can’t be a stub or total stub.

The routing table can still be made smaller via route summarization. In your CCNA studies, you learned how to summarize routes in RIP and EIGRP with the interface-level summary-address command. There are actually two ways to summarize routes in OSPF, and the method to use is dependent on the OSPF router type in use. (OSPF does not perform autosummarization when routes are sent across classful network boundaries, as RIPv2 and EIGRP do.) We’ll

now

configure

route

summarization with the area range command. This is configured only on an ABR. We’ll use the following network:

Four loopback addresses have been added to R1; they have all been placed into Area 1.

interface Loopback8 ip address 8.1.1.1 255.0.0.0 ! interface Loopback9 ip address 9.1.1.1 255.0.0.0 ! interface Loopback10 ip address 10.1.1.1 255.0.0.0 ! interface Loopback11 ip address 11.1.1.1 255.0.0.0 R1(config)#router ospf 1 R1(config-router)#network 0.255.255.255 area 1 R1(config-router)#network 0.255.255.255 area 1 R1(config-router)#network 0.255.255.255 area 1 R1(config-router)#network 0.255.255.255 area 1

8.0.0.0 9.0.0.0 10.0.0.0 11.0.0.0

All four of the new routes appear on R2 and R3, as shown here on R2: R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 2d01h, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 2d01h, Serial0 8.0.0.0/32 is subnetted, 1 subnets O IA 8.1.1.1 [110/65] via 172.12.123.1, 00:02:44, Serial0 9.0.0.0/32 is subnetted, 1 subnets O IA 9.1.1.1 [110/65] via 172.12.123.1, 00:02:34, Serial0 10.0.0.0/32 is subnetted, 1 subnets O IA 10.1.1.1 [110/65] via 172.12.123.1, 00:02:34, Serial0 11.0.0.0/32 is subnetted, 1 subnets

O IA 11.1.1.1 [110/65] via 172.12.123.1, 00:02:24, Serial0

R2 and R3 are both adjacent with R1 through Area 0, so using a stub or total stub to condense this routing table is out of the question. Route summarization will allow us to replace those four routes with a single route. First, we have to convert those four subnets to binary strings -and for a CCNA and future CCNP, that is no problem. 8.0.0.0 00001000 00000000 00000000

00000000

9.0.0.0

00000000

00001001

00000000 00000000 10.0.0.0 00001010 00000000 00000000

00000000

11.0.0.0 00001011 00000000 00000000

00000000

To come up with the summary route, work from left to right and draw a line where the four addresses no longer have a bit in common. Here, that is between the 6th and 7th bit in the first octet. (The common bits are highlighted in the above example.) Then just determine the value of the bits to the left of that line, with all

bits to the right of the line set to 0: 00001000 00000000 00000000 00000000 Converted back to decimal, that is 8.0.0.0. Since the first six bits were the same in all four addresses, those bits will be set to “1” in the accompanying summary mask, with all other bits set to “0”: 11111100 00000000 00000000 00000000 The mask is 252.0.0.0.

Now we can apply this summary route on R1. Using IOS Help, we see this command can only be used on area border routers. I would not depend on the CCNP ROUTE exam telling you that.

R2 now has a single summary route in place of the four individual entries in its routing table, and R2

can still ping all four of the loopbacks by using that summary route. R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 2d02h, Serial0 33.0.0.0/32 is subnetted, 1 subnets O IA 33.33.33.33 [110/65] via 172.12.123.3, 2d01h, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 2d02h, Serial0 O IA 8.0.0.0/6 [110/65] via 172.12.123.1, 00:00:15, Serial0

R2#ping 8.1.1.1 Sending 5, 100-byte ICMP Echos to 8.1.1.1,

timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms

R2#ping 9.1.1.1 Sending 5, 100-byte ICMP Echos to 9.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/69/72 ms

R2#ping 10.1.1.1 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/69/72 ms

R2#ping 11.1.1.1

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

Note that the number between area and range is the number of the area containing the routes to be summarized, not the area to which the summary is being sent. The other type of OSPF route summarization is performed by an ASBR to summarize routes as they’re redistributed into OSPF. In the following network, R5 has four loopbacks it is advertising via RIP:

4.1.1.1, 5.1.1.1, 6.1.1.1, and 7.1.1.1, all with a 32-bit mask. Those routes are being redistributed into the OSPF domain by the ASBR, R1.

R2 and R3 will see these external routes as four separate routes. These routes are being redistributed into OSPF as E1 routes; that the default is E2. The metrictype 1 option has been configured with the redistribute rip command to inject these routes into the OSPF domain as E1 routes. R1: router ospf 1 log-adjacency-changes area 1 range 8.0.0.0 252.0.0.0 redistribute connected subnets redistribute rip metric-type 1 subnets

network 1.1.1.1 0.0.0.0 area 1 network 8.0.0.0 0.255.255.255 area 1 network 9.0.0.0 0.255.255.255 area 1 network 10.0.0.0 0.255.255.255 area 1 network 11.0.0.0 0.255.255.255 area 1 network 172.12.123.0 0.0.0.255 area 0 neighbor 172.12.123.2 neighbor 172.12.123.3

R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 2d02h, Serial0 33.0.0.0/32 is subnetted, 1 subnets O IA 33.33.33.33 [110/65] via 172.12.123.3, 2d01h, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 2d02h, Serial0 4.0.0.0/32 is subnetted, 1 subnets O E1 4.1.1.1 [110/84] via

172.12.123.1, 00:06:31, Serial0 5.0.0.0/32 is subnetted, 1 subnets O E1 5.1.1.1 [110/84] via 172.12.123.1, 00:08:33, Serial0 6.0.0.0/32 is subnetted, 1 subnets O E1 6.1.1.1 [110/84] via 172.12.123.1, 00:08:33, Serial0 7.0.0.0/32 is subnetted, 1 subnets O E1 7.1.1.1 [110/84] via 172.12.123.1, 00:08:33, Serial0 15.0.0.0/24 is subnetted, 1 subnets O E2 15.1.1.0 [110/20] via 172.12.123.1, 00:08:33, Serial0 (The segment connecting R1 and R5. We left the connected routes at the default of E2.) O IA 8.0.0.0/6 [110/65] via 172.12.123.1, 00:16:48, Serial0

Again, the addresses to summarize will be broken down into binary strings:

4.0.0.0 00000100 00000000 00000000

00000000

5.0.0.0 00000101 00000000 00000000

00000000

6.0.0.0 00000110 00000000 00000000

00000000

7.0.0.0 00000111 00000000 00000000

00000000

Working from left to right, draw a line where the four addresses no longer have a bit in common. In this example, this occurs between the sixth and seventh bits, where the top

two addresses have a “0” and the bottom two have a “1”. Then determine the value of the resulting string, setting all bits to the right of the line to “0”: 00000100 00000000 00000000 00000000 This binary string converts to the dotted decimal value 4.0.0.0. Since the first six bits were the same in all four addresses, those bits will be set to “1” in the accompanying summary mask, with all other bits set to “0”:

11111100 00000000 00000000 00000000 The resulting summary mask is 252.0.0.0. Now we’ve got the summary address and mask; these values are applied to the ASBR with the summary-address command. R1(config)#router ospf 1 R1(config-router)#summary-address 252.0.0.0

4.0.0.0

R2 and R3 will now have this summary in their routing table, rather than the four individual routes. R2 can ping all four of the

loopbacks on R5. R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 2d03h, Serial0 33.0.0.0/32 is subnetted, 1 subnets O IA 33.33.33.33 [110/65] via 172.12.123.3, 2d01h, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 2d03h, Serial0 15.0.0.0/24 is subnetted, 1 subnets O E2 15.1.1.0 [110/20] via 172.12.123.1, 00:16:07, Serial0 O E1 4.0.0.0/6 [110/84] via 172.12.123.1, 00:00:07, Serial0 O IA 8.0.0.0/6 [110/65] via 172.12.123.1, 00:24:22, Serial0 R2#ping 4.1.1.1

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

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

When summarizing OSPF routes, the router will help you out by not allowing you to misuse the summary-address and area range commands. The CCNP ROUTE exam questions won’t be that kind, so make sure you know when these commands can and cannot be used. summary-address: Use on ASBR to summarize routes being redistributed into OSPF. area range: Use on ABR to

summarize routes d from one area to another. Area number used in the command is the area the routes are being d from. And Don’t Forget… You’ve got a lot of new and detailed commands to learn with OSPF, but don’t forget our old friend show ip protocols. Here is the command output on R1:

Information regarding the ACLs configured on this router, the OSPF RID, whether the router is an ABR and/or ASBR, redistribution information, the number of areas, the current maximum-paths setting

for equal-cost load balancing, the networks being routed and their areas, and the sources of routing information are all found here. Be very familiar with this command for the exam and for your job. Configuring OSPF Authentication

Neighbor

OSPF adjacencies can be authenticated using either clear-text (“simple”) or MD5 (MessageDigest 5). I personally never use clear-text anything unless an exam makes me do so, but it’s a great

idea to be familiar with the commands for both neighbor authentication methods and to know how to troubleshoot both authentication types. Clear-text protection for OSPF adjacencies is configured with the ip ospf authentication-key and ip ospf authentication commands. These two commands are very similar, so it’s a good idea to know exactly how they’re used. We’ll use them both to authenticate an adjacency between R1, R2, and R3 in Area 0. R1 is the hub router

of an OSPF NBMA network running over a frame relay cloud. R1 has an adjacency with both R2 and R3, the spoke routers of this configuration. The command ip ospf authentication-key defines the actual . Obviously, this has to be the same on all routers involved. There’s a classic “gotcha” with this command that you should be familiar with. I’ll configure a of ccnptestexam on the serial interface and then look at the router’s configuration to make sure I typed it correctly.

R1(config-if)#ip ospf authentication-key ? <0-7> Encryption type (0 for not yet encrypted, 7 for proprietary) LINE The OSPF (key) R1(config-if)#ip ccnptestexam

ospf

authentication-key

R1#show config interface Serial0 ip address 172.12.123.1 255.255.255.0 encapsulation frame-relay ip ospf authentication-key ccnptest

The was cut off after eight characters. That’s because this command has a limit of eight characters, and for some reason the IOS doesn’t tell us that when we

enter a longer one! This behavior changed with IOS 12.4 (the router now gives a warning regarding length), but since there are routers out there not running 12.4 or later, you should be prepared to see a in the config that may be shorter than the one you typed in! Once the is defined, clear-text authentication must be enabled. As always, we can use IOS Help to see our options… but there’s no specific listing for cleartext authentication.

R1(config)#int serial0 R1(config-if)#ip ospf authentication ? message-digest Use message-digest authentication null Use no authentication

For clear-text authentication, use the basic command with no options. R1(config-if)#ip ospf authentication

We’ll now configure the same commands on R2 and R3, because we have to in order to get the adjacencies to form again! Here are the messages I received on R1 shortly after configuring that router for neighbor authentication:

R1# 00:25:38: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.2 on Serial0 from FULL to DOWN, Neighbor Down: Dead timer expired R1# 00:25:58: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.3 on Serial0 from FULL to DOWN, Neighbor Down: Dead timer expired R1#

If you the dead time for OSPF NBMA networks, you know about how long that took! When OSPF neighbor authentication is configured on an interface, it must be configured on all neighbors reached through that interface or the adjacencies will drop when the dead timer expires.

R2(config)#interface serial0 R2(config-if)#ip ospf authentication-key ccnptest R2(config-if)#ip ospf authentication R3(config)#interface serial0 R3(config-if)#ip ospf authentication-key ccnptest R3(config-if)#ip ospf authentication

We go back to R1 to check the adjacencies just in time to get a message that the adjacency to R3 is back up. show ip ospf neighbor verifies that both adjacencies are back. 00:31:58: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.3 on Serial0 from LOADING to FULL, Loading Done

MD5 neighbor authentication is configured with the ip ospf message-digest-key and ip ospf authentication message-digest commands. Again, the commands sound a great deal alike, and we need to know exactly what each command does. To demonstrate, we’ll configure MD5 neighbor authentication over the ethernet segment connecting R2 and R3. A good first step is to the adjacency exists before trying to configure neighbor authentication!

The adjacency to R3 via Ethernet0 is present. We’ll authenticate that adjacency with the CCIE. The ip ospf message-digest-key command is rather long, so we’ll use IOS Help to see the options as we go along. R2(config)#int e0 R2(config-if)#ip ospf authentication messagedigest R2(config-if)#ip ospf message-digest-key ? <1-255> Key ID R2(config-if)#ip ospf message-digest-key 1 ? md5 Use MD5 algorithm

R2(config-if)#ip ospf message-digest-key 1 md5 ? <0-7> Encryption type (0 for not yet encrypted, 7 for proprietary) LINE The OSPF (key) R2(config-if)#ip ospf message-digest-key 1 md5 CCIE

Note that you have to specify a key number, MD5 authentication, and then finally the itself! Since the default dead time of this link is only 40 seconds, the adjacency should come down pretty quickly. By the time I saved this config and got over to R3, the adjacency was already gone.

The adjacency will come back quickly after configuring authentication on R3’s ethernet0 interface. R3(config)#int e0 R3(config-if)#ip ospf authentication messagedigest R3(config-if)#ip ospf message-digest-key 1 MD5 CCIE 00:24:09: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.2 on Ethernet0 from LOADING to FULL, Loading Done

And there it is! Troubleshooting OSPF Neighbor

Authentication The two main reasons authentication fails:

OSPF

Authentication is configured on only one neighbor is misspelled Luckily, these problems are both easy to spot with debug ip ospf adj. “adj” is obviously short for “adjacency”, but if I had a nickel for every time I entered “adjacency” with this command… I’d have a lot of nickels. You have

to use “adj”, because the full word doesn’t work with this debug!

R3#debug ip ospf adj OSPF adjacency events debugging is on

For the first debug example, I’ve removed message-digest authentication from R3’s ethernet interface and replaced it with cleartext authentication. As expected, the adjacency goes down quickly. R3(config)#int e0 R3(config-if)#ip ospf authentication

R3(config-if)# 00:52:44: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.23.2 on Ethernet0 from FULL to DOWN, Neighbor Down: Dead timer expired

But if you didn’t know the reason, how would you find the reason for the downed adjacency? By running debug ip ospf adj. R3#debug ip ospf adj OSPF adjacency events debugging is on R3# 00:54:04: OSPF: Rcv pkt from 172.12.23.2, Ethernet0 : Mismatch Authentication type. Input packet specified type 2, we use type 1 R3#undebug all All possible debugging has been turned off

The debug pays off right away, as we get a message that there’s a mismatch in the authentication type. The incoming Hello is using “type 2” authentication (MD5). Since R3’s ethernet0 interface is running “type 1” (clear-text), we have a mismatch. By changing R3’s type back to MD5, the adjacency will form again. And once you see what the problem is, always turn your debugs off with undebug all! R3(config)#interface e0 R3(config-if)#ip ospf authentication messagedigest R3(config-if)#^Z R3#

00:56:50: %SYS-5-CONFIG_I: Configured from console by console R3# 00:56:54: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.23.2 on Ethernet0 from LOADING to FULL, Loading Done

If the authentication type matches but the does not, the debug will give a different result. I’ll remove the initial key from R3’s E0 interface and replace it with a different . R3(config)#int e0 R3(config-if)#no ip ospf message-digest-key 1 MD5 CCIE R3(config-if)#ip ospf message-digest-key 1 MD5 CCIEE

00:27:59: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.23.2 on Ethernet0 from FULL to DOWN, Neighbor Down: Dead timer expired

What does a debug reveal? R3# 00:28:49: OSPF: Rcv pkt from 172.12.23.2, Ethernet0 : Mismatch Authentication Key Message Digest Key 1

That’s about as self-explanatory as a debug gets! Knowing your debugs truly means the difference between just “trying something” and knowing what to do. With OSPF, debug ip ospf adj is the king of debugs and the first command to use to

diagnose most OSPF issues. Default-Information (Always?)

Originate

This section will be repeated in the Route Redistribution section, since we’re redistributing a default route here - I want you to see it now as well since it ties in so closely to the topics in this section. 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 one. If

there is no default route to , 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 do so: R1(config-router)#default-information ? originate Distribute a default route R1(config-router)#default-information originate ? always Always default route metric OSPF default metric metric-type OSPF metric type for default

routes route-map

Route-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. Recommended From TBA:

YouTube

Videos

OSPF ASBR 3-Minute Boot Camp:

http://www.youtube.com/watch? v=hGrbyb6p4MI OSPF ABR 3-Minute Boot Camp: http://www.youtube.com/watch? v=cZityXoLmgI Video Practice Exam: Link State Protocols http://www.youtube.com/watch? v=yTBYdICOHGM OSPF Over Frame Relay: Practice

Exam and Tutorial: http://www.youtube.com/watch? v=VfILkf9s5OE OSPF Video Practice Exam: http://www.youtube.com/watch? v=jQAQFk3Xseo OSPF Stub Areas and Route Redistribution Video Boot Camp http://www.udemy.com/ccnp-routeboot-camp-redistribution-and-ospfstub-areas/


BGP

Introduction To BGP BGP is like nothing you’ve studied to this point. BGP is an external routing protocol used primarily by Internet Service Providers (ISPs). Unless you work for an ISP today or in the future, you may have little or no prior exposure to BGP. Understanding BGP is a great addition to your skill set – and you have to know the basics well to

the CCNP ROUTE exam. Note that I said “the basics”. BGP is a very complex protocol, and when you pursue your CCIE, you’ll see what I’m talking about. As with all things Cisco, though, when broken down into smaller pieces, BGP becomes quite understandable. BGP defined: An Internet protocol that enables groups of routers (called autonomous systems) to share routing information so that efficient, loop-free routes can be

established. BGP is commonly used within and between Internet Service Providers (ISPs). There are a couple of in there that apply to the protocols you’ve mastered so far in your studies. The term “autonomous system” applies to EIGRP as well as BGP -- you’ll be indicating a BGP AS in your configurations just as you did with EIGRP. And just like EIGRP, “autonomous system” simply refers to a group of routers that is managed by a single istrative body.

An AS will use Exterior Gateway Protocols (EGP) to exchange updates with other ASes. As you’ll soon see, BGP is one such EGP!

Interior Gateway Protocols such as OSPF and EIGRP have their place as well, and that place is inside an AS. Routes learned via BGP can be redistributed into an IGP, and vice versa - but you have to be extremely careful in doing so.

Extremely careful. More on that later. BGP shares some characteristics with some routing protocols you’ve already studied: BGP s VLSM and summarization. BGP will send full updates when two routers initially become neighbors and will send only partial updates after that.

BGP does create and maintain neighbor relationships before exchanging routes, and keepalives are sent to keep this relationship alive. You’ll hear BGP referred to as a path-vector protocol. As opposed to distance-vector protocols that exchange relatively simple information about available routes, BGP routers will exchange extensive information about networks to allow the routers to make more intelligent routing decisions.

This additional BGP path information comes in the form of attributes, and these path attributes are contained in the updates sent by BGP routers. Attributes themselves are broken up into two classes, well-known and optional. BGP also keeps a routing table separate from the IP routing table. As with any set of design requirements, it’s almost impossible to come up with a strict set of rules as to when to use and not to use BGP. Having said that, here are some general Cisco best

practices with BGP. When Should BGP Be Used? Some circumstances under which BGP should be used: If your company is connecting to more than one AS or ISP, decisions on which links to use can be made by using BGP path attributes. If the routing policy of your organization and your ISP are different, path attributes can again be helpful.

If your company is an ISP to begin with, traffic from other autonomous systems will use your AS as a transit domain, so BGP will be needed. The first and third reasons listed are the major reasons organizations run BGP. In short, if your AS has more than one connection to other ASes, or other ASes are using your AS as a transit area, BGP is practically a necessity. When Should BGP Not Be Used?

Some general guidelines on when not to use BGP: When there is a single connection to the Internet or to another autonomous system. No redundant link to the internet is present. Situations where you don’t really care which path is used to reach a route in another AS. When router resources are a

concern (memory and U). When there is a lowbandwidth connection between multiple autonomous systems. In this situation, static and default routing may be a better choice if any of these circumstances exist. The BGP Peering Process Like T, BGP is connectionoriented (“reliable”). An underlying connection between two BGP speakers is established before any

routing information is exchanged. This connection takes place on T port 179. As with EIGRP and OSPF, keepalive messages are sent out by the BGP speakers in order to keep this relationship alive. Hint: T port 179 is a good port to leave unblocked by ACLs. Once the connection is established, the BGP speakers exchange routes and synchronize their tables. After this initial exchange, a BGP speaker will only send further updates upon a change in the network topology.

The IGP protocols that use Autonomous Systems, IGRP and EIGRP, require prospective neighbors to be in the same AS. This is not true with BGP. Routers can be in different Autonomous Systems and still exchange routes. A BGP peer that is in the same AS as the local router is an Internal BGP (iBGP) peer, where a BGP peer in another AS is an External BGP (eBGP) peer. That little “i” or “e” makes a big difference when it comes to advertising routes and other BGP behaviors - so watch that letter!

A sample iBGP configuration (same AS): Router bgp 100 Neighbor 10.1.1.2 remote-as 100

A sample eBGP (different AS):

configuration

Router bgp 100 Neighbor 10.1.1.2 remote-as 200

Cisco recommends that eBGP peers be directly connected. iBGP peers are not required to be directly connected and generally aren’t. Before we get too deep into BGP theory, let’s get a configuration

started. You’ll use the router bgp command to configure a router as a BGP speaker. Right after that, the neighbor command will be used to identify this BGP speaker’s potential neighbors. (The “peer” and “neighbor” are interchangeable in BGP, but it’s the neighbor statement that is used to statically define neighbors. BGP is not capable of discovering neighbors dynamically.) what I mentioned about BGP being a complex protocol? Take a look at all the possible

options for the neighbor command: R1(config)#router bgp 100 R1(config-router)#neighbor 172.12.123.3 ?

activate

-map

mentinterval

Enabl Addre for thi Neigh specif map fo condit adver Minim interv sendin routin Accep

allowas-in defaultoriginate description disableconnectedcheck

distribute-list

with m presen Origin route neighb Neigh specif descri One-h EBGP using addre

Filter to/from neighb Allow

ebgp-multihop

filter-list local-as maximumprefix

next-hop-self

neighb direct conne netwo Establ filters Speci as num Maxim numbe accep peer

Disab hop ca for thi

Propa

next-hopunchanged peer-group prefix-list remote-as

removeprivate-AS

iBGP next h uncha this ne Set a p Memb peer-g Filter to/from neighb Speci neighb

Remo AS nu outbou update

route-map routereflector-client sendcommunity shutdown softreconfiguration timers

Apply to neig Config neighb Route client Send C attribu neighb shut d neighb Per ne soft reconf

BGP p

translateupdate

unsuppressmap

update-source version

neighb Transl Updat MBGP Route select unsup suppre routes Sourc routin Set the versio a neig

Set de weigh

weight

routes neighb

Do not panic! You don’t have to know every single one of these to the CCNP ROUTE exam. I’m just showing them to you to reinforce the fact that BGP is a whole new world! And the key to learning what every one of those commands do? Mastering one at a time. Let’s start with the basics and configure R1 and R3 as eBGP

peers. We’ll place R1 into AS 100 and R3 into AS 200. The routers are on the 172.12.123.0 /24 network.

R1(config-router)#neighbor 172.12.123.3 % Incomplete command. R1(config-router)#neighbor remote-as 200

172.12.123.3

While almost all of the neighbor options are just that -- optional -you do have to specify the BGP AS of the remote router. BGP has no mechanism to dynamically discover neighbors. , BGP speakers do not have to be in the same AS to become peers. To that the remote BGP speaker has become a peer, run show ip bgp neighbor. R1#show ip bgp neighbor BGP neighbor is 172.12.123.3, remote AS 200, external link BGP version 4, remote router ID 0.0.0.0 BGP state = Active Last read 00:01:39, hold time is 180,

keepalive interval is 60 seconds Received 0 messages, 0 notifications, 0 in queue Sent 0 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Default minimum time between ment runs is 30 seconds

The output here can be a little misleading the first time you read it. The first highlighted line shows 172.12.123.3 is a BGP neighbor, is located in AS 200, and is an external link, indicating that the neighbor is in another AS entirely. The second highlighted line shows the BGP state as Active. This sounds great, but it actually means

that a BGP peer connection does not yet exist with the prospective neighbor. Before we continue with this example, let’s look at the different BGP states: Idle is the initial state of a BGP connection. The BGP speaker is waiting for a start event, generally either the establishment of a T connection or the re-establishment of a previous connection. Once the connection is established, BGP moves to the next state. There’s nothing wrong with this state, but we don’t want to stay

there. If you note a connection has gone to idle and stayed there, check two things: The IP address in the neighbor statement (this is usually the issue). While we’re at it, make sure you have a neighbor statement for that remote router. Make sure your local router knows how to get to that same address.

Connect is the next state. In this state, a T connection request has been sent but a response has not yet been received. If the T connection completes, BGP will move to the OpenSent stage; if the connection does not complete, BGP goes to Active. Active indicates that the BGP speaker is continuing to create a peer relationship with the remote router - basically, this is the halfway point of the connection. The local router has successfully sent a BGP Open packet to the address in the neighbor statement,

but it hasn’t heard anything back yet. As with Idle, there’s nothing wrong with this state - unless your connection stays there. If the connection goes Active and stays there, it’s really a mirror image of the Idle issue we spoke of earlier, so… Check the remote router’s neighbor statement Be sure the remote router knows how to get the

OpenConfirm packet back to the local router (OpenConfirm is BGP’s ACK) And my personal favorite make sure your AS numbers are correct, especially if the connection is flapping between Idle and Active. OpenSent indicates that the BGP speaker has received an Open message from the peer. BGP will determine whether the peer is in the same AS (iBGP) or a different AS

(eBGP) in this state. In OpenConfirm state, the BGP speaker is waiting for a keepalive message. If one is received, the state moves to Established, and the neighbor relationship is complete. It is in the Established state that update packets are actually exchanged. So even though the show ip bgp neighbor output indicated that this is an Active neighbor relationship, that’s not as good as it sounds. Of course, the reason the peer relationship hasn’t been established

is that we haven’t configured R3 yet! R3(config)#router bgp 200 R3(config-router)#neighbor remote-as 100

172.12.123.1

the peer establishment with show ip bgp neighbor: R3#show ip bgp neighbor BGP neighbor is 172.12.123.1, remote AS BGP version 4, remote router ID 172.12 BGP state = Established, up for 00:01:18 Last read 00:00:17, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: d and received(old & new) Address family IPv4 Unicast: d

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 ment runs is 30 seconds Local host: 172.12.123.3, Local port: 179

(BGP uses T Port 179) Foreign host: 172.12.123.1, Foreign port: 110077

The peer relationship between R1 and R3 Another handy command to view BGP peer information is show ip bgp summary. While most of the information in this command deals with the local router, a BGP peer

summary table is shown at the very end of the command output. If you just want to see if peer relationships are in place and how long they’ve been up, I find this command to be more helpful than the show ip bgp neighbor command. R1#show ip bgp summary BGP router identifier 172.12.123.1, local AS number 100 BGP table version is 2, main routing table version 2 1 network entries and 1 paths using 133 bytes of memory 1 BGP path attribute entries using 60 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP activity 1/1 prefixes, 1/0 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 172.12.123.2 4 100 83 84 2 0 0 01:19:03 0 172.12.123.3 4 200 104 103 2 0 0 01:39:24 1

BGP peers do not have to be in the same AS, and whether they are in the same or a different AS determines whether they become iBGP or eBGP peers. That may not sound like a big deal, but it is.

In the following configuration, R1 has two peers, one sharing AS 100 and the other in AS 200. (Also note what happens if you use the local router’s own IP address as a BGP peer address!)

R1(config)#router bgp 100 R1(config-router)#neighbor 172.12.123.3 remote-as 200 R1(config-router)#neighbor 172.12.123.1 remote-as 100 % Cannot configure the local system as neighbor R1(config-router)#neighbor 172.12.123.2 remote-as 100

R1#show ip bgp neighbor BGP neighbor is 172.12.123.2, remote AS 100, internal link BGP version 4, remote router ID 172.12.123.2 BGP neighbor is 172.12.123.3, remote AS 200, external link BGP version 4, remote router ID 172.12.123.3

Using Loopback Addresses To Create eBGP Adjacencies When you were introduced to loopback interfaces in your CCNA studies, your first question was likely “Why do we create imaginary interfaces on Cisco routers?”

The frustrating thing for both teacher and student in the CCNA is that you’re shown how to create those interfaces, but not really given many reasons why. Here’s one excellent reason why - and a classic BGP “gotcha” you must be aware of. Using loopback addresses for BGP adjacencies allows us to keep those adjacencies even if physical interfaces go down for any reason. Sounds good, right? Now here’s that “gotcha”:

Loopback interfaces are not considered directly connected even if they share a common subnet. The ebgp-multihop command is necessary to configure eBGP peering relationships where the addresses used to form the adjacency are not on the same segment. You’ll also need the update-source loopback command when loopbacks are used to create eBGP adjacencies. Static routes can also play a role in

eBGP adjacencies. If you use loopback addresses for eBGP adjacencies, you may also need to configure a static route on each router that points to the remote router’s loopback. After all, for this config to work, the router needs to know how to get to the address used in the neighbor command. Let’s drive all of these concepts home by creating an adjacency between R1 and R3 using their respective loopback addresses as shown in the following config.

R1(config)#int loopback1 R1(config-if)#ip address 1.1.1.1 255.255.255.255 R1(config-if)#router bgp 100 R1(config-router)#no auto R1(config-router)#no synch R1(config-router)#neighbor 3.3.3.3 remote-as 200 R1(config-router)#neighbor 3.3.3.3 ebgpmultihop 2 R1(config-router)#neighbor 3.3.3.3 updatesource loopback1 R3(config)#int loopback1 R3(config-if)#ip address 255.255.255.255

3.3.3.3

R3(config-if)#router bgp 200 R3(config-router)#no auto R3(config-router)#no synch R3(config-router)#neighbor 1.1.1.1 remote-as 100 R3(config-router)#neighbor 1.1.1.1 ebgpmultihop 2 R3(config-router)#neighbor 1.1.1.1 updatesource loopback1

The neighbor statements look good, the ebgp-multihop command is in place, and the update-source command is as well. But is the adjacency in place?

Both routers show an adjacency state of Active, and we could wait a long, long time and they’d still be shown as Active. Just as with EIGRP, Active is not good when it lasts. The issue is that neither router has a route to the loopback address the remote router is using to form the adjacency.

Or in this case, not forming it. By configuring static routes on each router that point to the remote router’s loopback address, the BGP adjacency will form. We’ll use two host static routes here to get the job done. R3(config)#ip route 1.1.1.1 255.255.255.255 serial1 R1(config)#ip route 3.3.3.3 255.255.255.255 serial1

The adjacencies come up just a few seconds after these static routes are configured. Note that though the

desired state of each neighbor relationship is Established, that word doesn’t actually appear where we saw Active just a few minutes ago - at the utmost right of the show ip bgp summary output.

No route to the address in the neighbor statement = no neighbor! If the address is on a directly connected subnet, that works, and

we can get the route from an IGP but don’t forget about a simple default route. Naturally, those static routes have to stay there; if they’re removed, the adjacencies will time out. To demonstrate, I removed the static route from R3: R3(config)#no ip route 1.1.1.1 255.255.255.255 serial1

A few minutes later, the result is a lost adjacency. R3# 00:22:24: %BGP-5-ADJCHANGE: neighbor

1.1.1.1 Down BGP Notification sent R3# 00:22:24: %BGP-3-NOTIFICATION: sent to neighbor 1.1.1.1 4/0 (hold time expired)0 bytes

In short, there are three main reasons why BGP peerings fail to form or are torn down after they’re built. The AS number is incorrectly identified in the config. If you do this, trust me, you’re not the first and you won’t be the last! :) A peering has been configured

for an eBGP router that is not directly connected, and the ebgp-multihop option has been omitted. An ACL is blocking T port 179. Opening that port right back up will allow the adjacencies to reform, but you will have some anxious moments in the meantime!

Advertising Routes In BGP We use the network command in

BGP, but not quite the same way we did with RIP, EIGRP, and OSPF. It will look the same, but the BGP network command identifies the networks that will be d by BGP, where the network command with IGPs identifies the interfaces that will be enabled with that protocol. The network specified in the BGP network command must be an exact match for a network contained in the IP routing table, and that includes the mask. A real-world note here (and it

couldn’t hurt on the exam) -- using the mask in the network statement is not required, but I highly recommend you use it. If you’re called on to troubleshoot a BGP configuration and it’s missing the masks on the network statements, that could well be the issue. Use the masks or you’ll end up only with the classful networks.

Here, we’ll R3’s loopback (3.3.3.3 /32) in BGP. R3(config)#router bgp 200 R3(config-router)#network 255.255.255.255

3.3.3.3

mask

R1 quickly sees the route:

For the route to be usable, you must see that asterisk. The best route is indicated with a combination of an asterisk and the “>” 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 d 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 d 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 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 d to other routers,

the Partial bit will be set and the attribute d 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 ed 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) d 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) d 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 d 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) d 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) d 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 ment. 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 ed between the two autonomous systems, but the value is not ed 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 ed 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 “Lorf” 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) d 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) d 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 d 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 T 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 its loopback network, 3.3.3.3/32, to R2 via iBGP. R2 will then 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 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 s 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 about this BGP attribute: Cisco-proprietary value locally significant to a router is never d 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 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 ed through. The Community Attribute This attribute allows us to logically group routers that have a common configuration, making them 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 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 d 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 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 ment 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 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 ?

-

16.0.0.0

Set conditi

map

as-set attributemap

route-map

summaryonly

to 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 d 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 d, 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 T 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 T session itself is reset: R1#clear ip bgp * R1# 09:18:36: %BGP-5-ADJCHANGE: neighbor 10.1.1.5 Down reset 09:18:36: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Down reset 09:18:36: %BGP-5-ADJCHANGE: neighbor

172.12.123.3 Down 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 T 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 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 d 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 d to is an eBGP router.

iBGP routers do not 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 d. 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 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 a route until every router in the transit AS has the route in its IGP routing table. R4 will not send an ment for network 200.20.0.0 to R5 until R4 hears an ment 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 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, U).

A full mesh is going to require a large number of T 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 T

connections for a 20-router AS! Add this to the istrative 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 T 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 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. how we would need 190 separate T 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 T connections being needed. That’s a huge reduction in the overhead caused by all those T 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 T 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 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 that route to other iBGP peers. The same thing happens if R2 s its loopback to R1. R1 can put the route in its BGP table, but cannot 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 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 d 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 T 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 istrative 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 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 . 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 T 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 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: d Address family IPv4 Unicast: d 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 ment 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 d 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 d… … or maybe the routes you don’t want d.

BGP gives us several tools with which to control the flow of network ments, and the first of these is the prefix list. Cisco states several reasons for the use of prefix lists…. 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. 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 d 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 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 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. , 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 U workload is fine with me! This is a very powerful concept and you’ll definitely see this anywhere you work with BGP. Peer group 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 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 of this peer group. Finally, the 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 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 ed 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 s. 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 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 d to an eBGP peer.

NO-: Taking the previous community one step further, this community attribute prevents the route from being d 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 U 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 U (and yes, “plenty” is an

arbitrary term), you should be okay getting specific routes from the ISPs. If memory and U 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 ? <1-65535> 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 d 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: d and received(new) Address family IPv4 Unicast: d 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 ment 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 d 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

T

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: d 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 reset 20:32:34: BGP: 15.1.1.5 reset due to reset 20:32:34: %BGP-5-ADJCHANGE: neighbor 15.1.1.5 Down reset 20:32:34: BGP: 172.12.123.2 reset due to reset 20:32:34: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Down reset 20:32:34: BGP: 172.12.123.3 reset due to reset

R1# 20:32:34: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Down 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 ments:

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 and on DVD!


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 that are sometimes used interchangeably, but they don’t refer to the same feature. Let’s take a close look at these . 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 you should know. We’ll review the 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 . 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 ing s 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 !) 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 ed 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 ? <1-10000> 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 ? <60-86400> 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 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 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 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 ?

<165535>

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 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 s - 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, 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 name and to the Server.

We can use several methods to set up this authentication: Local (using the name/ 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 s.

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 (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 name / 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 NAT and PAT, but with a twist. According to Cisco documentation, Client will autoconfigure the necessary NAT and PAT commands and access-lists; the 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.


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 s. 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 s’ 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 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 ’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 is sharing bandwidth with a lot of other s, which can be a problem if the provider doesn’t have enough bandwidth to go around. The end 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 , 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 will more information than they send, and for the average Internet , that’s a safe assumption. The connection speed from the provider to the is going to be 3 - 4 times faster than

the speed from the to the provider. For example, an ADSL connection of 512 kbps will give the 384 KBPS capabilities, but only 128 kbps ing capability. ADSL actually offers speeds of up to 8 mbps and 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 and 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 and 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 Excellent for single- 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-name CCNP ISCW

I configured PAP here, but that PAP sends s in clear text. I personally prefer to use CHAP, which sends a hash result rather than a clear-text . 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 dh command allows an interface to acquire an

address via DH. 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 DH on this router, and allow it to serve as the DH server for the inside hosts. Configuring a Cisco router as a DH 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 dh excluded-address 172.1.1.1 172.1.1.100 ip dh pool 1 network 172.1.1.0 255.255.255.0 lease 30

To reiterate, you’ll have many options with DH 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 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 istrative 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 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.


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!)

DH is still available, but IPv6 nodes can assign themselves an address without the help of a DH 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 ing the CCNP ROUTE exam. You 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 ing 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 . 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 DH; 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 DH, that’s because it is DHv6, actually! You hear the term stateful autoconfiguration more often than “DHv6”, though, but you should know they’re one and the same. The key phrase there is “from a server”. If the DHv6 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 ment

(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 ment (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 DH for addressing information If DH is in use, the RA tells the host where the DH serer is If not, the RA contains the prefix and prefix lifetime information If DH 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 ?

<1-65535>

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

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- 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

[istratively

Serial0/0 [istratively down/down] unassigned FastEthernet0/1 [up/up] FE80::20F:F7FF:FE69:8D21 5DDE:EEEE:1::1 Serial0/1 [istratively 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 s 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 it 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 s 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 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

? <0-16777214> 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 , 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 d 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 s 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 istrative

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 istrative 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 ? <1-255> istrative 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 ?

<1-99>

<13001999>

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 one. If there is no default route to , 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 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 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 d 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 d 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 ? <1-4294967295> Bandwidth metric in Kbits per second R3(config-router)#redistribute rip metric 1544 ?

<0-4294967295> IGRP delay metric, in 10 microsecond units R3(config-router)#redistribute rip metric 1544 10 ? <0-255> IGRP reliability metric where 255 is 100% reliable R3(config-router)#redistribute rip metric 1544 10 255 ? <1-255> IGRP Effective bandwidth metric (Loading) where 255 is 100% loaded R3(config-router)#redistribute rip metric 1544 10 255 1 ? <1-4294967295> 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 ? <1-255> istrative distance eigrp IP-EIGRP distance

R2(config-router)#distance eigrp ? <1-255> Distance for internal routes R2(config-router)#distance eigrp 90 ? <1-255> 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. ing 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.

ive Interfaces ive interfaces can be a big help in controlling routing updates and or/ routing control traffic, depending on which protocol you’re dealing with: RIP: ive interfaces do not send routing updates, but will accept them. RIP adjacencies aren’t affected by ive interfaces since RIP doesn’t have adjacencies in the

first place. In the following example, R1’s Ethernet0 interface has been configured as ive. R1’s loopback 10.1.1.1 /24 is d 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 ive-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 ive 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 ive 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 ive interface. If an adjacency exists on an interface that is then

made ive, the adjacency is dropped. A subnet running a ive interface can be d. 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 ive? Let’s find out!

The first impact is the lost adjacency between R1 and R5. EIGRP ive 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 ive interfaces do not send Hellos, but the subnet running on that ive interface can still be d via the network command. OSPF: ive interfaces do not send OSPF Hellos, so no adjacency

can be formed, and existing adjacencies are lost on interfaces that are then configured as ive. Additionally, the subnet running on the ive interface will be d 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 ive and watch the results. We know what the first result is going to be… R1(config)#router ospf 1 R1(config-router)#ive-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 d 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 ive interface is lost, but the subnet is still d via the network command.

You can set all interfaces on a router as ive for a given protocol with the ive-interface default command. R3(config)#router ospf 1 R3(config-router)#ive-interface default

To set the interfaces back to their default, just use the no iveinterface default command. R3(config-router)#no ive-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

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 d via a certain interface without making that interface ive and losing the adjacency. Let’s use an EIGRP topology that we used earlier in this section, but

we’ll 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 ive, 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


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 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


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 d 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

<065535>

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 ? <0-65535> 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. (, 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 ?

<0-

Sequence to insert to/delete

65535>

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 ?

<1199> <13002699> 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 ?

<1199> <13002699> 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


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 ?

+/-<metric>

<04294967295>

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 - 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 d 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 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

either - or both! - with show ip policy. R2#show ip policy

Interface local Serial0 And here’s ….

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


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 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 s 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 istrative 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 ? <1-4294967295> Bandwidth in Kbits per

second R2(config-router)#default-metric 1544 ? <0-4294967295> Delay metric, in 10 microsecond units R2(config-router)#default-metric 1544 10 ? <0-255> Reliability metric where 255 is 100% reliable R2(config-router)#default-metric 1544 10 255 ? <1-255> Effective bandwidth metric (Loading) where 255 is 100% loaded R2(config-router)#default-metric 1544 10 255 1 ? <1-4294967295> 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 ? <1-16777214> 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 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 s, 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 -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 s it! RIPv2, OSPF, EIGRP, and BGP all 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 deg 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 deg 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. , 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.


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. , 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 . 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


Ccnp Route Guide 6k523r

Overview 26281t

More details 6y5l6z

Related Documents 3h463d

Ccnp Route Guide 6k523r

Ccnp-route-workbook.pdf 4v391w

Ccnp Route Notes 136260

Ccnp Route Cheatsheet 36k6m

Sikandar Ccnp Route Final.pdf 5v5s1y

Ccnp Route Notes - Updated 4w1338

More Documents from "Cesar Morera Alpizar" 85w6n

300-101 Ccnp Route Exam Questions 451o6q

Ccnp Route Guide 6k523r

Nissan Frontier Factory Service Manual 3y5g2c

4p345f

Resumen De Sociales 2 5y6p1e

Carta A Una Amiga 2k343c