Describe the routing concepts

The term routing refers to taking a packet from one device and sending it through the network to another device on a different network. Routers don't really care about hosts—they only care about networks and the best path to each one of them. The logical network address of the destination host is key to get packets through a routed network. It's the hardware address of the host that's used to deliver the packet from a router and ensure it arrives at the correct destination host. In the following sections, we'll take a close look at how routing works.

Packet Handling along the Path through a Network

The IP routing process is fairly simple and doesn't change, regardless of the size of your network. For a good example of this fact, I'll use Figure 3.1 to describe step-by-step what happens when Host A wants to communicate with Host B on a different network.

In Figure 3.1 a user on Host A pinged Host B's IP address. Routing doesn't get any simpler than this, but it still involves a lot of steps, so let's work through them now:

1. Internet Control Message Protocol (ICMP) creates an echo request payload, which is simply the alphabet in the data field.
2. ICMP hands that payload to Internet Protocol (IP), which then creates a packet. At a minimum, this packet contains an IP source address, an IP destination address, and a Protocol field with 01h. Don't forget that Cisco likes to use 0x in front of hex characters, so this could also look like 0x01. This tells the receiving host to whom it should hand the payload when the destination is reached—in this example, ICMP.
3. Once the packet is created, IP determines whether the destination IP address is on the local network or a remote one.
4. Since IP has determined that this is a remote request, the packet must be sent to the default gateway so it can be routed to the remote network. The Registry in Windows is parsed to find the configured default gateway.
5. The default gateway of Host A is configured to 172.16.10.1. For this packet to be sent to the default gateway, the hardware address of the router's interface Ethernet 0, which is configured with the IP address of 172.16.10.1, must be known. Why? So the packet can be handed down to the Data Link layer, framed, and sent to the router's interface that's connected to the 172.16.10.0 network. Because hosts communicate only via hardware addresses on the local LAN, it's important to recognize that for Host A to communicate to Host B, it has to send packets to the Media Access Control (MAC) address of the default gateway on the local network.
6. Next, the Address Resolution Protocol (ARP) cache of the host is checked to see if the IP address of the default gateway has already been resolved to a hardware address.

   If it has, the packet is then free to be handed to the Data Link layer for framing. Remember that the hardware destination address is also handed down with that packet. To view the ARP cache on your host, use the following command:

   C:>arp -a

   Interface: 172.16.10.2 --- 0x3

     Internet Address      Physical Address      Type

     172.16.10.1          00-15-05-06-31-b0     dynamic

   If the hardware address isn't already in the ARP cache of the host, an ARP broadcast will be sent out onto the local network to search for the 172.16.10.1 hardware address. The router then responds to the request and provides the hardware address of Ethernet 0, and the host caches this address.

7. Once the packet and destination hardware address are handed to the Data Link layer, the LAN driver is used to provide media access via the type of LAN being used, which is Ethernet in this case. A frame is then generated, encapsulating the packet with control information. Within that frame are the hardware destination and source addresses plus, in this case, an Ether-Type field, which identifies the specific Network layer protocol that handed the packet to the Data Link layer. In this instance, it's IP. At the end of the frame is something called a Frame Check Sequence (FCS) field that houses the result of the cyclic redundancy check (CRC). A CRC calculation ensures that the contents of the frame have not changed during transmission. The frame would look something like what I've detailed in Figure 3.2. It contains Host A's hardware (MAC) address and the destination hardware address of the default gateway. It does not include the remote host's MAC address—remember that!

   

8. Once the frame is completed, it's handed down to the Physical layer to be put on the physical medium (in this example, twisted-pair wire) one bit at a time.
9. Every device in the collision domain receives these bits and builds the frame. They each run a CRC and check the answer in the FCS field. If the answers don't match, the frame is discarded.
   • If the CRC matches, then the hardware destination address is checked to see if it matches (which, in this example, is the router's interface Ethernet 0).
   • If it's a match, then the Ether-Type field is checked to find the protocol used at the Network layer.
10. The packet is pulled from the frame, and what is left of the frame is discarded. The packet is handed to the protocol listed in the Ether-Type field—it's given to IP.
11. IP receives the packet and checks the IP destination address. Since the packet's destination address doesn't match any of the addresses configured on the receiving router itself, the router will look up the destination IP network address in its routing table.
12. The routing table must have an entry for the network 172.16.20.0 or the packet will be discarded immediately and an ICMP message will be sent back to the originating device with a destination network unreachable message.
13. If the router does find an entry for the destination network in its table, the packet is switched to the exit interface—in this example, interface Ethernet 1. The following output displays the Lab A router's routing table. The C means “directly connected.” No routing protocols are needed in this network since all networks (all two of them) are directly connected.

    Lab A>sh ip route

    C       172.16.10.0 is directly connected,    Ethernet0

    L       172.16.10.1/32 is directly connected, Ethernet0

    C       172.16.20.0 is directly connected,    Ethernet1

    L       172.16.20.1/32 is directly connected, Ethernet1

14. The router packet-switches the packet to the Ethernet 1 buffer.
15. The Ethernet 1 buffer needs to know the hardware address of the destination host and first checks the ARP cache.
    • If the hardware address of Host B has already been resolved and is in the router's ARP cache, then the packet and the hardware address will be handed down to the Data Link layer to be framed. Let's take a look at the ARP cache on the Lab A router by using the show ip arp command:

      Lab A#sh ip arp

      Protocol  Address     Age(min) Hardware Addr  Type   Interface

      Internet  172.16.20.1   -     00d0.58ad.05f4  ARPA   Ethernet1

      Internet  172.16.20.2   3     0030.9492.a5dd  ARPA   Ethernet1

      Internet  172.16.10.1   -     00d0.58ad.06aa  ARPA   Ethernet0

      Internet  172.16.10.2  12     0030.9492.a4ac  ARPA   Ethernet0

      The dash (-) signifies that this is the physical interface on the router. This output shows us that the router knows the 172.16.10.2 (Host A) and 172.16.20.2 (Host B) hardware addresses. Cisco routers will keep an entry in the ARP table for 4 hours.

    • Now if the hardware address hasn't already been resolved, the router will send an ARP request out E1 looking for the 172.16.20.2 hardware address. Host B responds with its hardware address, and the packet and destination hardware addresses are then both sent to the Data Link layer for framing.
16. The Data Link layer creates a frame with the destination and source hardware addresses, Ether-Type field, and FCS field at the end. The frame is then handed to the Physical layer to be sent out on the physical medium one bit at a time.
17. Host B receives the frame and immediately runs a CRC. If the result matches the information in the FCS field, the hardware destination address will then be checked next. If the host finds a match, the Ether-Type field is then checked to determine the protocol that the packet should be handed to at the Network layer—IP in this example.
18. At the Network layer, IP receives the packet and runs a CRC on the IP header. If that passes, IP then checks the destination address. Since a match has finally been made, the Protocol field is checked to find out to whom the payload should be given.
19. The payload is handed to ICMP, which understands that this is an echo request. ICMP responds to this by immediately discarding the packet and generating a new payload as an echo reply.
20. A packet is then created including the source and destination addresses, Protocol field, and payload. The destination device is now Host A.
21. IP then checks to see whether the destination IP address is a device on the local LAN or on a remote network. Since the destination device is on a remote network, the packet needs to be sent to the default gateway.
22. The default gateway IP address is found in the Registry of the Windows device, and the ARP cache is checked to see if the hardware address has already been resolved from an IP address.
23. Once the hardware address of the default gateway is found, the packet and destination hardware addresses are handed down to the Data Link layer for framing.
24. The Data Link layer frames the packet of information and includes the following in the header:
    • The destination and source hardware addresses
    • The Ether-Type field with 0x0800 (IP) in it
    • The FCS field with the CRC result in tow
25. The frame is now handed down to the Physical layer to be sent out over the network medium one bit at a time.
26. The router's Ethernet 1 interface receives the bits and builds a frame. The CRC is run, and the FCS field is checked to make sure the answers match.
27. Once the CRC is found to be okay, the hardware destination address is checked. Since the router's interface is a match, the packet is pulled from the frame and the Ether-Type field is checked to determine which protocol the packet should be delivered to at the Network layer.
28. The protocol is determined to be IP, so it gets the packet. IP runs a CRC check on the IP header first and then checks the destination IP address.

    Since the IP destination address doesn't match any of the router's interfaces, the routing table is checked to see whether it has a route to 172.16.10.0. If it doesn't have a route over to the destination network, the packet will be discarded immediately. I want to take a minute to point out that this is exactly where the source of confusion begins for a lot of administrators because when a ping fails, most people think the packet never reached the destination host. But as we see here, that's not always the case. All it takes for this to happen is for even just one of the remote routers to lack a route back to the originating host's network and—poof!—the packet is dropped on the return trip, not on its way to the host!

29. In this case, the router happens to know how to get to network 172.16.10.0—the exit interface is Ethernet 0—so the packet is switched to interface Ethernet 0.
30. The router then checks the ARP cache to determine whether the hardware address for 172.16.10.2 has already been resolved.
31. Since the hardware address for 172.16.10.2 is already cached from the originating trip to Host B, the hardware address and packet are then handed to the Data Link layer.
32. The Data Link layer builds a frame with the destination hardware address and source hardware address and then puts IP in the Ether-Type field. A CRC is run on the frame and the result is placed in the FCS field.
33. The frame is then handed to the Physical layer to be sent out onto the local network one bit at a time.
34. The destination host receives the frame, runs a CRC, checks the destination hardware address, then looks into the Ether-Type field to find out to whom to hand the packet.
35. IP is the designated receiver, and after the packet is handed to IP at the Network layer, it checks the Protocol field for further direction. IP finds instructions to give the payload to ICMP, and ICMP determines the packet to be an ICMP echo reply.
36. ICMP acknowledges that it has received the reply by sending an exclamation point (!) to the user interface. ICMP then attempts to send four more echo requests to the destination host.

You've just experienced Todd's 36 easy steps to understanding IP routing. The key point here is that if you had a much larger network, the process would be the same. It's just that the larger the internetwork, the more hops the packet goes through before it finds the destination host.

It's super-important to remember that when Host A sends a packet to Host B, the destination hardware address used is the default gateway's Ethernet interface. Why? Because frames can't be placed on remote networks—only local networks. So packets destined for remote networks must go through the default gateway.

Let's take a look at Host A's ARP cache now:

C: >arp -a

Interface: 172.16.10.2 --- 0x3

  Internet Address      Physical Address      Type

  172.16.10.1           00-15-05-06-31-b0     dynamic

  172.16.20.1           00-15-05-06-31-b0     dynamic

Did you notice that the hardware (MAC) address that Host A uses to get to Host B is the Lab A E0 interface? Hardware addresses are always local, and they never pass through a router's interface. Understanding this process is as important as air to you, so carve this into your memory!

Forwarding Decision Based on Route Lookup

Before moving on into some of the more advanced aspects of IP routing, let's look at another issue. Take a look at the output of this router's routing table:

Corp#sh ip route

[output cut]

R    192.168.215.0 [120/2] via 192.168.20.2, 00:00:23, Serial0/0

R    192.168.115.0 [120/1] via 192.168.20.2, 00:00:23, Serial0/0

R    192.168.30.0 [120/1] via 192.168.20.2, 00:00:23, Serial0/0

C    192.168.20.0 is directly connected, Serial0/0

L    192.168.20.1/32 is directly connected, Serial0/0

C    192.168.214.0 is directly connected, FastEthernet0/0

L    192.168.214.1/32 is directly connected, FastEthernet0/0

What do we see here? If I were to tell you that the corporate router received an IP packet with a source IP address of 192.168.214.20 and a destination address of 192.168.22.3, what do you think the Corp router will do with this packet?

If you said, “The packet came in on the FastEthernet 0/0 interface, but because the routing table doesn't show a route to network 192.168.22.0 (or a default route), the router will discard the packet and send an ICMP destination unreachable message back out to interface FastEthernet 0/0,” you're a genius! The reason that's the correct answer is because that's the source LAN where the packet originated from.

Frame Rewrite

Recall step 16 in the IP routing process illustrated in the section “Packet Handling along the Path through a Network”:

16. The Data Link layer creates a frame with the destination and source hardware addresses, Ether-Type field, and FCS field at the end. The frame is then handed to the Physical layer to be sent out on the physical medium one bit at a time.

The process described in step 16 is called the frame rewrite process. It simply refers to the change in the layer 2 header information that occurs at each hop in the path to the destination. This occurs because at each hop, while the source and destination IP addresses will not change, the source and destination MAC addresses will change.

Exam Essentials

Describe the basic IP routing process. You need to remember that the frame changes at each hop but that the packet is never changed or manipulated in any way until it reaches the destination device (the TTL field in the IP header is decremented for each hop, but that's it!).

Interpret the components of a routing table

Figure 3.3 shows a simple network.

Lab A has four interfaces. By using the command show ip route on a router, we can see the routing table (map of the internetwork) that Lab A has used to make its forwarding decisions:

Lab A#sh ip route

Codes: L - local, C - connected, S - static,

[output cut]

        10.0.0.0/8 is variably subnetted, 6 subnets, 4 masks

C       10.0.0.0/8 is directly connected, FastEthernet0/3

L       10.0.0.1/32 is directly connected, FastEthernet0/3

C       10.10.0.0/16 is directly connected, FastEthernet0/2

L       10.10.0.1/32 is directly connected, FastEthernet0/2

C       10.10.10.0/24 is directly connected, FastEthernet0/1

L       10.10.10.1/32 is directly connected, FastEthernet0/1

S*      0.0.0.0/0 is directly connected, FastEthernet0/0

The C in the routing table output means that the networks listed are “directly connected,” and until we add a routing protocol like RIPv2, OSPF, etc. to the routers in our internetwork, or enter static routes, only directly connected networks will show up in our routing table. But wait—what about that L in the routing table—that's new, isn't it? Yes it is, because in the new Cisco IOS 15 code, Cisco defines a different route, called a local route. Each local route has a /32 prefix, defining a route just for the one address. So in this example, the router has relied upon these routes that list their own local IP addresses to more efficiently forward packets to the router itself. Let's continue our discussion by looking at the parts of the routing table.

Prefix

Recall in the previous section that each network listed in the output has a number following a forward slash. This number is the prefix and indicates the number of bits in the subnet mask. For example, a /24 prefix indicates the mask 255.255.255.0.

Network Mask

The network mask, or subnet mask, indicates the number of bits in the network portion of an IP address. Recall that this portion of two IP addresses must match for the two addresses to be in the same network. The mask is indicated in the routing table though the use of the prefix, which by indicating the number of bits in the subnet mask, also indicates the length of the network ID.

Next Hop

The next-hop field in a table entry indicates the next IP address in the path to the destination. In some cases, there is no next-hop address. Rather, the network in these entries is directly connected to the router, as indicated by an entry like the following:

C       10.10.0.0/16 is directly connected, FastEthernet0/2

Routing Protocol Code

A letter next to each entry indicates how the router learned the route. It might indicate that the network is directly connected or that the network was entered manually. In cases where the route was learned through a routing protocol, the protocol will be listed. A legend at the beginning of the output of the show ip route command indicates what each letter stands for. It appears as follows:

Router# show ip route

 

Codes: L - local, C - connected, S - static, 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

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route, H - NHRP

       + - replicated route, % - next hop override

Administrative Distance

The administrative distance (AD) is used to rate the trustworthiness of routing information received on a router from a neighbor router. An administrative distance is represented as an integer from 0 to 255, where 0 is the most trusted and 255 means no traffic will be passed via this route.

If a router receives two updates listing the same remote network, the first thing the router checks is the AD. If one of the advertised routes has a lower AD than the other, then the route with the lowest AD will be chosen and placed in the routing table.

Table 3.1 shows the default administrative distances that a Cisco router uses to decide which route to take to a remote network.

Table 3.1 Default administrative distances

If a network is directly connected, the router will always use the interface connected to the network. If you configure a static route, the router will then believe that route over any other ones it learns about. You can change the administrative distance of static routes, but by default, they have an AD of 1.

If you have a static route, an RIP-advertised route, and an EIGRP-advertised route listing the same network, which route will the router go with? That's right—by default, the router will always use the static route unless you change its AD—which we did!

Metric

If both advertised routes to the same network have the same AD, then routing protocol metrics like hop count and/or the bandwidth of the lines will be used to find the best path to the remote network. The advertised route with the lowest metric will be placed in the routing table, but if both advertised routes have the same AD as well as the same metrics, then the routing protocol will load-balance to the remote network, meaning the protocol will send data down each link. In the following example, the metric is indicated by the value on the right side of the slash within the brackets (30720).

D        10.1.34.0/24 [90/30720] via 10.1.36.3, 00:07:32, FastEthernet0/1

Gateway of Last Resort

While host devices can be configured with default gateways, routers can also be configured with them. On routers, these are called gateways of last resort. They are configured by creating a default route. This default route is used by IP to forward any packet with a destination not found in the routing table, which is why it is also called a gateway of last resort. When a default route is present in the table, it will be indicated in two ways. First, there will be a statement at the beginning of the table, and second, there will be a route to the 0.0.0/0 network, as shown in the following output:

Gateway of last resort is 172.16.10.5 to network 0.0.0.0

172.16.0.0/30 is subnetted, 1 subnets

C       172.16.10.4 is directly connected, Serial0/0/1

L       172.16.10.6/32 is directly connected, Serial0/0/1

C    192.168.20.0/24 is directly connected, FastEthernet0/0

L    192.168.20.0/32 is directly connected, FastEthernet0/0

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

Exam Essentials

View and interpret the routing table of a router. Use the show ip route command to view the routing table. Each route will be listed along with the source of the routing information. A C to the left of the route will indicate directly connected routes, and other letters next to the route can also indicate a particular routing protocol that provided the information, such as, for example, R for RIP.

Describe how a routing table is populated by different routing information sources

In the previous section entitled “Administrative Distance” you learned how the routing table is developed by the router. For a review of the process by which a router populates the routing table, see that section.

Admin Distance

I also introduced and explained administrative distance in detail in the section “Administrative Distance.” Please refer to that section for more on the router's use of administrative distance.

Exam Essentials

Understand administrative distance and its role in the selection of the best route. Administrative distance (AD) is used to rate the trustworthiness of routing information received on a router from a neighbor router. Administrative distance is represented as an integer from 0 to 255, where 0 is the most trusted and 255 means no traffic will be passed via this route. All routing protocols are assigned a default AD, but it can be changed at the CLI.

Configure, verify, and troubleshoot inter-VLAN routing

Hosts in a VLAN live in their own broadcast domain and can communicate freely. VLANs create network partitioning and traffic separation at layer 2 of the OSI, and as I said when I told you why we still need routers, if you want hosts or any other IP-addressable device to communicate between VLANs, you must have a layer 3 device to provide routing.

For this, you can use a router that has an interface for each VLAN or a router that supports ISL or 802.1q routing. The least expensive router that supports ISL or 802.1q routing is the 2600 series router. You'd have to buy that from a used-equipment reseller because they are end-of-life, or EOL. I'd recommend at least a 2800 as a bare minimum, but even that only supports 802.1q; Cisco is really moving away from ISL, so you probably should only be using 802.1q anyway. Some 2800s may support both ISL and 802.1q; I've just never seen both supported.

Anyway, if you had two or three VLANs, you could get by with a router equipped with two or three FastEthernet connections. And 10Base-T is okay for home study purposes, and I mean only for your studies, but for anything else I'd highly recommend Gigabit interfaces for real power under the hood!

What we see in Figure 3.4 is that each router interface is plugged into an access link. This means that each of the routers' interface IP addresses would then become the default gateway address for each host in each respective VLAN.

If you have more VLANs available than router interfaces, you can configure trunking on one FastEthernet interface or buy a layer 3 switch, like the Cisco 3560 or a higher-end switch like a 3750. You could even opt for a 6500 if you've got money to burn!

Instead of using a router interface for each VLAN, you can use one FastEthernet interface and run ISL or 802.1q trunking. Figure 3.5 shows how a FastEthernet interface on a router will look when configured with ISL or 802.1q trunking. This allows all VLANs to communicate through one interface. Cisco calls this a router on a stick (ROAS).

I really want to point out that this creates a potential bottleneck, as well as a single point of failure, so your host/VLAN count is limited. To how many? Well, that depends on your traffic level. To really make things right, you'd be better off using a higher-end switch and routing on the backplane. But if you just happen to have a router sitting around, configuring this method is free, right?

Figure 3.6 shows how we would create a router on a stick using a router's physical interface by creating logical interfaces—one for each VLAN.

Here we see one physical interface divided into multiple subinterfaces, with one subnet assigned per VLAN, each subinterface being the default gateway address for each VLAN/subnet. An encapsulation identifier must be assigned to each subinterface to define the VLAN ID of that subinterface. In the next section, where I'll configure VLANs and inter-VLAN routing, I'll configure our switched network with a router on a stick and demonstrate this configuration for you.

But wait, there's still one more way to go about routing! Instead of using an external router interface for each VLAN, or an external router on a stick, we can configure logical interfaces on the backplane of the layer 3 switch; this is called inter-VLAN routing (IVR), and it's configured with a switched virtual interface (SVI). Figure 3.7 shows how hosts see these virtual interfaces.

In Figure 3.7, it appears there's a router present, but there is no physical router present as there was when we used router on a stick. The IVR process takes little effort and is easy to implement, which makes it very cool! Plus, it's a lot more efficient for inter-VLAN routing than an external router is. To implement IVR on a multilayer switch, we just need to create logical interfaces in the switch configuration for each VLAN.

Router on a Stick

By default, only hosts that are members of the same VLAN can communicate. To change this and allow inter-VLAN communication, you need a router or a layer 3 switch. I'm going to start with the router approach.

To support ISL or 802.1q routing on a FastEthernet interface, the router's interface is divided into logical interfaces—one for each VLAN—as was shown in Figure 3.6. These are called subinterfaces. From a FastEthernet or Gigabit interface, you can set the interface to trunk with the encapsulation command:

ISR#config t

ISR(config)#int f0/0.1

ISR(config-subif)#encapsulation ?

  dot1Q  IEEE 802.1Q Virtual LAN

ISR(config-subif)#encapsulation dot1Q ?

  <1-4094>  IEEE 802.1Q VLAN ID

Notice that my 2811 router (named ISR) only supports 802.1q. We'd need an older-model router to run the ISL encapsulation, but why bother?

The subinterface number is only locally significant, so it doesn't matter which subinterface numbers are configured on the router. Most of the time, I'll configure a subinterface with the same number as the VLAN I want to route. It's easy to remember that way since the subinterface number is used only for administrative purposes.

It's really important that you understand that each VLAN is actually a separate subnet. True, I know—they don't have to be. But it really is a good idea to configure your VLANs as separate subnets, so just do that. Before we move on, I want to define upstream routing. This is a term used to define the router on a stick. This router will provide inter-VLAN routing, but it can also be used to forward traffic upstream from the switched network to other parts of the corporate network or Internet.

Now, I need to make sure you're fully prepared to configure inter-VLAN routing as well as determine the IP addresses of hosts connected in a switched VLAN environment. And as always, it's also a good idea to be able to fix any problems that may arise. To set you up for success, let me give you a few examples.

First, start by looking at Figure 3.8 and read the router and switch configuration within it. By this point in the book, you should be able to determine the IP address, masks, and default gateways of each of the hosts in the VLANs.

The next step is to figure out which subnets are being used. By looking at the router configuration in the figure, you can see that we're using 192.168.10.0/28 for VLAN1, 192.168.1.64/26 with VLAN 2, and 192.168.1.128/27 for VLAN 10.

By looking at the switch configuration, you can see that ports 2 and 3 are in VLAN 2 and port 4 is in VLAN 10. This means that Host A and Host B are in VLAN 2 and Host C is in VLAN 10.

But wait—what's that IP address doing there under the physical interface? Can we even do that? Sure we can! If we place an IP address under the physical interface, the result is that frames sent from the IP address would be untagged. So what VLAN would those frames be a member of? By default, they would belong to VLAN 1, our management VLAN. This means the address 192.168.10.1/28 is my native VLAN IP address for this switch.

Here's what the hosts' IP addresses should be:

Host A: 192.168.1.66, 255.255.255.192, default gateway 192.168.1.65

Host B: 192.168.1.67, 255.255.255.192, default gateway 192.168.1.65

Host C: 192.168.1.130, 255.255.255.224, default gateway 192.168.1.129

The hosts could be any address in the range—I just chose the first available IP address after the default gateway address. That wasn't so hard, was it?

Now, again using Figure 3.8, let's go through the commands necessary to configure switch port 1 so it will establish a link with the router and provide inter-VLAN communication using the IEEE version for encapsulation. Keep in mind that the commands can vary slightly depending on what type of switch you're dealing with.

For a 2960 switch, use the following:

2960#config t

2960(config)#interface fa0/1

2960(config-if)#switchport mode trunk

That's it! As you already know, the 2960 switch can only run the 802.1q encapsulation, so there's no need to specify it. You can't anyway. For a 3560, it's basically the same, but because it can run ISL and 802.1q, you have to specify the trunking encapsulation protocol you're going to use.

Let's take a look at Figure 3.9 and see what we can determine. This figure shows three VLANs, with two hosts in each of them. The router in Figure 3.9 is connected to the Fa0/1 switch port, and VLAN 4 is configured on port Fa0/6.

When looking at this diagram, keep in mind that these three factors are what Cisco expects you to know:

• The router is connected to the switch using subinterfaces.
• The switch port connecting to the router is a trunk port.
• The switch ports connecting to the clients and the hub are access ports, not trunk ports.

The configuration of the switch would look something like this:

2960#config t

2960(config)#int f0/1

2960(config-if)#switchport mode trunk

2960(config-if)#int f0/2

2960(config-if)#switchport access vlan 2

2960(config-if)#int f0/3

2960(config-if)#switchport access vlan 2

2960(config-if)#int f0/4

2960(config-if)#switchport access vlan 3

2960(config-if)#int f0/5

2960(config-if)#switchport access vlan 3

2960(config-if)#int f0/6

2960(config-if)#switchport access vlan 4

Before we configure the router, we need to design our logical network:

VLAN 1: 192.168.10.0/28

VLAN 2: 192.168.10.16/28

VLAN 3: 192.168.10.32/28

VLAN 4: 192.168.10.48/28

The configuration of the router would then look like this:

ISR#config t

ISR(config)#int fa0/0

ISR(config-if)#ip address 192.168.10.1 255.255.255.240

ISR(config-if)#no shutdown

ISR(config-if)#int f0/0.2

ISR(config-subif)#encapsulation dot1q 2

ISR(config-subif)#ip address 192.168.10.17 255.255.255.240

ISR(config-subif)#int f0/0.3

ISR(config-subif)#encapsulation dot1q 3

ISR(config-subif)#ip address 192.168.10.33 255.255.255.240

ISR(config-subif)#int f0/0.4

ISR(config-subif)#encapsulation dot1q 4

ISR(config-subif)#ip address 192.168.10.49 255.255.255.240

Notice I didn't tag VLAN 1. Even though I could have created a subinterface and tagged VLAN 1, it's not necessary with 802.1q because untagged frames are members of the native VLAN.

The hosts in each VLAN would be assigned an address from their subnet range, and the default gateway would be the IP address assigned to the router's subinterface in that VLAN.

Now, let's take a look at another figure and see if you can determine the switch and router configurations without looking at the answer—no cheating! Figure 3.10 shows a router connected to a 2960 switch with two VLANs. One host in each VLAN is assigned an IP address. What would your router and switch configurations be based on these IP addresses?

Since the hosts don't list a subnet mask, you have to look for the number of hosts used in each VLAN to figure out the block size. VLAN 2 has 85 hosts and VLAN 3 has 115 hosts. Each of these will fit in a block size of 128, which is a /25 mask, or 255.255.255.128.

You should know by now that the subnets are 0 and 128; the 0 subnet (VLAN 2) has a host range of 1–126, and the 128 subnet (VLAN 3) has a range of 129–254. You can almost be fooled since Host A has an IP address of 126, which makes it almost seem that Host A and Host B are in the same subnet. But they're not, and you're way too smart by now to be fooled by this one!

Here is the switch configuration:

2960#config t

2960(config)#int f0/1

2960(config-if)#switchport mode trunk

2960(config-if)#int f0/2

2960(config-if)#switchport access vlan 2

2960(config-if)#int f0/3

2960(config-if)#switchport access vlan 3

Here is the router configuration:

ISR#config t

ISR(config)#int f0/0

ISR(config-if)#ip address 192.168.10.1 255.255.255.0

ISR(config-if)#no shutdown

ISR(config-if)#int f0/0.2

ISR(config-subif)#encapsulation dot1q 2

ISR(config-subif)#ip address 172.16.10.1 255.255.255.128

ISR(config-subif)#int f0/0.3

ISR(config-subif)#encapsulation dot1q 3

ISR(config-subif)#ip address 172.16.10.254 255.255.255.128

I used the first address in the host range for VLAN 2 and the last address in the range for VLAN 3, but any address in the range would work. You would just have to configure the host's default gateway to whatever you make the router's address. Also, I used a different subnet for my physical interface, which is my management VLAN router's address.

Now, before we go on to the next example, I need to make sure you know how to set the IP address on the switch. Since VLAN 1 is typically the administrative VLAN, we'll use an IP address from out of that pool of addresses. Here's how to set the IP address of the switch (not nagging, but you really should already know this!):

2960#config t

2960(config)#int vlan 1

2960(config-if)#ip address 192.168.10.2 255.255.255.0

2960(config-if)#no shutdown

2960(config-if)#exit

2960(config)#ip default-gateway 192.168.10.1

Yes, you have to execute a no shutdown on the VLAN interface and set the ip default-gateway address to the router.

One more example, and then we'll move on to IVR using a multilayer switch—another important subject that you definitely don't want to miss! In Figure 3.11 there are two VLANs, plus the management VLAN 1. By looking at the router configuration, what's the IP address, subnet mask, and default gateway of Host A? Use the last IP address in the range for Host A's address.

If you really look carefully at the router configuration (the hostname in this configuration is just Router), there's a simple and quick answer. All subnets are using a /28, which is a 255.255.255.240 mask. This is a block size of 16. The router's address for VLAN 2 is in subnet 128. The next subnet is 144, so the broadcast address of VLAN 2 is 143 and the valid host range is 129–142. So the host configuration would be this:

IP address: 192.168.10.142

Mask: 255.255.255.240

Default gateway: 192.168.10.129

SVI

I'll use Figure 3.12 to demonstrate configuring inter-VLAN routing (IVR) with a multilayer switch, which is often referred to as a switched virtual interface (SVI). I'll use this IP address scheme: 192.168.x.0/24, where x represents the VLAN subnet. In my example this will be the same as the VLAN number.

The hosts are already configured with the IP address, subnet mask, and default gateway address using the first address in the range. Now I just need to configure the routing on the switch, which is pretty simple actually:

S1(config)#ip routing

S1(config)#int vlan 10

S1(config-if)#ip address 192.168.10.1 255.255.255.0

S1(config-if)#int vlan 20

S1(config-if)#ip address 192.168.20.1 255.255.255.0

And that's it! Enable IP routing and create one logical interface for each VLAN using the interface vlan number command and voilà! You've now accomplished making inter-VLAN routing work on the backplane of the switch!

Exam Essentials

Remember how to create a Cisco router on a stick to provide inter-VLAN communication. You can use a Cisco FastEthernet or Gigabit Ethernet interface to provide inter-VLAN routing. The switch port connected to the router must be a trunk port; then you must create virtual interfaces (subinterfaces) on the router port for each VLAN connecting to it. The hosts in each VLAN will use this subinterface address as their default gateway address.

Remember how to provide inter-VLAN routing with a layer 3 switch. You can use a layer 3 (multilayer) switch to provide IVR just as with a router on a stick, but using a layer 3 switch is more efficient and faster. First you start the routing process with the command ip routing, then create a virtual interface for each VLAN using the command interface vlan vlan, and then apply the IP address for that VLAN under that logical interface.

Compare and contrast static routing and dynamic routing

There are several ways to configure the routing tables to include all the networks in our little internetwork so that packets will be properly forwarded. As usual, one size fits all rarely fits at all, and what's best for one network isn't necessarily what's best for another. That's why understanding the different types of routing will be really helpful when choosing the best solution for your specific environment and business requirements. Let's compare static and dynamic routing.

Static Routing

Static routing is the process that ensues when you manually add routes in each router's routing table. Predictably, there are pros and cons to static routing, but that's true for all routing approaches.

Here are the pros:

• There is no overhead on the router CPU, which means you could probably make do with a cheaper router than you would need for dynamic routing.
• There is no bandwidth usage between routers, saving you money on WAN links as well as minimizing overhead on the router since you're not using a routing protocol.
• It adds security because you, the administrator, can be very exclusive and choose to allow routing access to certain networks only.

And here are the cons:

• Whoever the administrator is must have a vault-tight knowledge of the internetwork and how each router is connected in order to configure routes correctly. If you don't have a good, accurate map of your internetwork, things will get very messy quickly!
• If you add a network to the internetwork, you have to tediously add a route to it on all routers by hand, which only gets increasingly insane as the network grows.
• Due to the last point, it's just not feasible to use it in most large networks because maintaining it would be a full-time job in itself.

Dynamic Routing

Dynamic routing is when protocols are used to find networks and update routing tables on routers. This is whole lot easier than using static or default routing, but it will cost you in terms of router CPU processing and bandwidth on network links. A routing protocol defines the set of rules used by a router when it communicates routing information between neighboring routers.

Exam Essentials

Compare and contrast static and dynamic routing. Static routing creates no routing update traffic and creates less overhead on the router and network links, but it must be configured manually and does not have the ability to react to link outages. Dynamic routing creates routing update traffic and uses more overhead on the router and network links.

Compare and contrast distance vector and link state routing protocols

There are three classes of routing protocols:

Distance vector The distance-vector protocols in use today find the best path to a remote network by judging distance. In RIP routing, each instance where a packet goes through a router is called a hop, and the route with the least number of hops to the network will be chosen as the best one. The vector indicates the direction to the remote network. RIP is a distance-vector routing protocol and periodically sends out the entire routing table to directly connected neighbors.

Link state In link-state protocols, also called shortest path first (SPF) protocols, the routers each create three separate tables. One of these tables keeps track of directly attached neighbors, one determines the topology of the entire internetwork, and one is used as the routing table. Link-state routers know more about the internetwork than any distance- vector routing protocol ever could. OSPF is an IP routing protocol that's completely link-state. Link-state routing tables are not exchanged periodically. Instead, triggered updates containing only specific link-state information are sent. Periodic keepalives that are small and efficient, in the form of Hello messages, are exchanged between directly connected neighbors to establish and maintain neighbor relationships.

Advanced distance vector Advanced distance-vector protocols use aspects of both distance-vector and link-state protocols, and EIGRP is a great example. EIGRP may act like a link-state routing protocol because it uses a Hello protocol to discover neighbors and form neighbor relationships and because only partial updates are sent when a change occurs. However, EIGRP is still based on the key distance-vector routing protocol principle that information about the rest of the network is learned from directly connected neighbors.

There's no set of rules to follow that dictate exactly how to broadly configure routing protocols for every situation. It's a task that really must be undertaken on a case-by-case basis, with an eye on specific requirements of each one. If you understand how the different routing protocols work, you can make good, solid decisions that will solidly meet the individual needs of any business!

Exam Essentials

Differentiate distance-vector, link-state, and hybrid routing protocols. Distance-vector routing protocols make routing decisions based on hop count (think RIP), while link-state routing protocols are able to consider multiple factors such as bandwidth available and building a topology table. Hybrid routing protocols exhibit characteristics of both types.

Compare and contrast interior and exterior routing protocols

Two types of routing protocols are used in internetworks: interior gateway protocols (IGPs) and exterior gateway protocols (EGPs). IGPs are used to exchange routing information with routers in the same autonomous system (AS). An AS is either a single network or a collection of networks under a common administrative domain, which basically means that all routers sharing the same routing-table information are in the same AS. EGPs are used to communicate between ASs. An example of an EGP is Border Gateway Protocol (BGP), which we're not going to bother with because it's beyond the scope of this book.

Exam Essentials

Describe both interior and exterior routing protocols. IGPs are used to exchange routing information with routers in the same autonomous system (AS), while EGPs are used to route between ASs.

Configure, verify, and troubleshoot IPv4 and IPv6 static routing

Starting at the beginning, here's the command syntax you use to add a static route to a routing table from global config:

ip route [destination_network] [mask] [next-hop_address or

  exitinterface] [administrative_distance] [permanent]

This list describes each command in the string:

ip route The command used to create the static route

destination_network The network you're placing in the routing table

mask The subnet mask being used on the network

next-hop_address This is the IP address of the next-hop router that will receive packets and forward them to the remote network, which must signify a router interface that's on a directly connected network. You must be able to successfully ping the router interface before you can add the route. Important note to self is that if you type in the wrong next-hop address or the interface to the correct router is down, the static route will show up in the router's configuration but not in the routing table.

exitinterface Used in place of the next-hop address if you want, and shows up as a directly connected route

administrative_distance By default, static routes have an administrative distance of 1 or 0 if you use an exit interface instead of a next-hop address. You can change the default value by adding an administrative weight at the end of the command.

permanent If the interface is shut down or the router can't communicate to the next-hop router, the route will automatically be discarded from the routing table by default. Choosing the permanent option keeps the entry in the vector.

Before I guide you through configuring static routes, let's take a look at a sample static route to see what we can find out about it:

Router(config)#ip route 172.16.3.0 255.255.255.0 192.168.2.4

The ip route command tells us simply that it's a static route.

• 172.16.3.0 is the remote network we want to send packets to.
• 255.255.255.0 is the mask of the remote network.
• 192.168.2.4 is the next hop, or router, that packets will be sent to.

But what if the static route looked like this instead?

Router(config)#ip route 172.16.3.0 255.255.255.0 192.168.2.4 150

That 150 at the end changes the default administrative distance (AD) of 1 to 150. As I said, remember that the AD is the trustworthiness of a route, where 0 is best and 255 is worst.

One more example, then we'll start configuring:

Router(config)#ip route 172.16.3.0 255.255.255.0 s0/0/0

Instead of using a next-hop address, we can use an exit interface that will make the route show up as a directly connected network. Functionally, the next hop and exit interface work exactly the same.

Static Route Configuration

To help you understand how static routes work, I'll demonstrate the configuration on the internetwork shown in Figure 3.13.

Each routing table automatically includes directly connected networks. To be able to route to all indirectly connected networks within the internetwork, the routing table must include information that describes where these other networks are located and how to get to them.

Corp

The Corp router is connected to three networks. For the Corp router to be able to route to all networks, the following networks have to be configured into its routing table:

• 192.168.10.0
• 192.168.20.0

The following router output shows the static routes on the Corp router and the routing table after the configuration. For the Corp router to find the remote networks, I had to place an entry into the routing table describing the remote network, the remote mask, and where to send the packets. I am going to add a 150 at the end of each line to raise the administrative distance. Here's the output:

Corp#config t

Corp(config)#ip route 192.168.10.0 255.255.255.0 172.16.10.2 150

Corp(config)#ip route 192.168.20.0 255.255.255.0 s0/1 150

Corp(config)#do show run | begin ip route

ip route 192.168.10.0 255.255.255.0 172.16.10.2 150

ip route 192.168.20.0 255.255.255.0 Serial0/1 150

I needed to use different paths for networks 192.168.10.0 and 192.168.20.0, so I used a next-hop address for the SF router and an exit interface for the LA router. After the router has been configured, you can just type show ip route to see the static routes:

Corp(config)#do show ip route

S    192.168.10.0/24 [150/0] via 172.16.10.2

     172.16.0.0/30 is subnetted, 2 subnets

C       172.16.10.4 is directly connected, Serial0/1

L       172.16.10.5/32 is directly connected, Serial0/1

C       172.16.10.0 is directly connected, Serial0/0

L       172.16.10.1/32 is directly connected, Serial0/0

S    192.168.20.0/24 is directly connected, Serial0/1

     10.0.0.0/24 is subnetted, 1 subnets

C       10.10.10.0 is directly connected, FastEthernet0/0

L       10.10.10.1/32 is directly connected, FastEthernet0/0

The Corp router is configured to route and know all routes to all networks. But can you see a difference in the routing table for the routes to SF and LA? That's right! The next-hop configuration showed up as via, and the route configured with an exit interface configuration shows up as static but also as directly connected! This demonstrates how they are functionally the same but will display differently in the routing table.

Understand that if the routes don't appear in the routing table, it's because the router can't communicate with the next-hop address you've configured. But you can still use the permanent parameter to keep the route in the routing table even if the next-hop device can't be contacted.

The S in the first routing table entry means that the route is a static entry. The [150/0] stands for the administrative distance and metric to the remote network, respectively.

Okay—we're good. The Corp router now has all the information it needs to communicate with the other remote networks. Still, keep in mind that if the SF and LA routers aren't configured with all the same information, the packets will be discarded. We can fix this by configuring static routes.

SF

The SF router is directly connected to networks 172.16.10.0/30 and 192.168.10.0/24, which means I've got to configure the following static routes on the SF router:

• 10.10.10.0/24
• 192.168.20.0/24
• 172.16.10.4/30

The configuration for the SF router is revealed in the following output. Remember that we'll never create a static route to any network we're directly connected to as well as the fact that we must use the next hop of 172.16.10.1 since that's our only router connection. Let's check out the commands:

SF(config)#ip route 10.10.10.0 255.255.255.0 172.16.10.1 150

SF(config)#ip route 172.16.10.4 255.255.255.252 172.16.10.1 150

SF(config)#ip route 192.168.20.0 255.255.255.0 172.16.10.1 150

SF(config)#do show run | begin ip route

ip route 10.10.10.0 255.255.255.0 172.16.10.1 150

ip route 172.16.10.4 255.255.255.252 172.16.10.1 150

ip route 192.168.20.0 255.255.255.0 172.16.10.1 150

By looking at the routing table, you can see that the SF router now understands how to find each network:

SF(config)#do show ip route

C    192.168.10.0/24 is directly connected, FastEthernet0/0

L    192.168.10.1/32 is directly connected, FastEthernet0/0

     172.16.0.0/30 is subnetted, 3 subnets

S       172.16.10.4 [150/0] via 172.16.10.1

C       172.16.10.0 is directly connected, Serial0/0/0

L       172.16.10.2/32 is directly connected, Serial0/0

S    192.168.20.0/24 [150/0] via 172.16.10.1

     10.0.0.0/24 is subnetted, 1 subnets

S       10.10.10.0 [150/0] via 172.16.10.1

And we now can rest assured that the SF router has a complete routing table as well. As soon as the LA router has all the networks in its routing table, SF will be able to communicate with all remote networks!

LA

The LA router is directly connected to 192.168.20.0/24 and 172.16.10.4/30, so these are the routes that must be added:

• 10.10.10.0/24
• 172.16.10.0/30
• 192.168.10.0/24

And here's the LA router's configuration:

LA#config t

LA(config)#ip route 10.10.10.0 255.255.255.0 172.16.10.5 150

LA(config)#ip route 172.16.10.0 255.255.255.252 172.16.10.5 150

LA(config)#ip route 192.168.10.0 255.255.255.0 172.16.10.5 150

LA(config)#do show run | begin ip route

ip route 10.10.10.0 255.255.255.0 172.16.10.5 150

ip route 172.16.10.0 255.255.255.252 172.16.10.5 150

ip route 192.168.10.0 255.255.255.0 172.16.10.5 150

This output displays the routing table on the LA router:

LA(config)#do sho ip route

S    192.168.10.0/24 [150/0] via 172.16.10.5

     172.16.0.0/30 is subnetted, 3 subnets

C       172.16.10.4 is directly connected, Serial0/0/1

L       172.16.10.6/32 is directly connected, Serial0/0/1

S       172.16.10.0 [150/0] via 172.16.10.5

C    192.168.20.0/24 is directly connected, FastEthernet0/0

L    192.168.20.1/32 is directly connected, FastEthernet0/0

     10.0.0.0/24 is subnetted, 1 subnets

S       10.10.10.0 [150/0] via 172.16.10.5

LA now shows all five networks in the internetwork, so it too can now communicate with all routers and networks.

Default Route

The SF and LA routers that I've connected to the Corp router are considered stub routers. A stub indicates that the networks in this design have only one way out to reach all other networks, which means that instead of creating multiple static routes, we can just use a single default route. This default route is used by IP to forward any packet with a destination not found in the routing table, which is why it is also called a gateway of last resort. Here's the configuration I could have done on the LA router instead of typing in the static routes due to its stub status:

LA#config t

LA(config)#no ip route 10.10.10.0 255.255.255.0 172.16.10.5 150

LA(config)#no ip route 172.16.10.0 255.255.255.252 172.16.10.5 150

LA(config)#no ip route 192.168.10.0 255.255.255.0 172.16.10.5 150

LA(config)#ip route 0.0.0.0 0.0.0.0 172.16.10.5

LA(config)#do sho ip route

[output cut]

Gateway of last resort is 172.16.10.5 to network 0.0.0.0

172.16.0.0/30 is subnetted, 1 subnets

C       172.16.10.4 is directly connected, Serial0/0/1

L       172.16.10.6/32 is directly connected, Serial0/0/1

C    192.168.20.0/24 is directly connected, FastEthernet0/0

L    192.168.20.0/32 is directly connected, FastEthernet0/0

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

Okay—I've removed all the initial static routes I had configured, and adding a default route is a lot easier than typing a bunch of static routes! Can you see the default route listed last in the routing table? The S* shows that as a candidate for the default route. And I really want you to notice that the gateway of last resort is now set too. Everything the router receives with a destination not found in the routing table will be forwarded to 172.16.10.5. You need to be careful where you place default routes because you can easily create a network loop!

So we're there—we've configured all our routing tables! All the routers have the correct routing table, so all routers and hosts should be able to communicate without a hitch—for now. But if you add even one more network or another router to the internetwork, you'll have to update each and every router's routing tables by hand—ugh! Not really a problem at all if you've got a small network like we do, but it would be a time-consuming monster if you're dealing with a large internetwork!

Network Route

When a route is created that points to a network (as most route entries do), it is called a network route. This simply means that the route points to a group of hosts, as does the following entry:

S    192.168.10.0/24 [150/0] via 172.16.10.5

Host Route

In most cases, we create routes to networks, but you can create a route leading to a single host. An example of a host route is shown below. Note that the mask that goes with the route is 32 bits in length, meaning it is a route to a single IP address.

S        10.1.1.1/32 [1/0] via 192.168.12.4 Ethernet0

There are dynamically created host routes called local host routes as well. One of these will be placed in the routing table for each router interface. An example is shown below. Note that is has an L next to it and is preceded by the network route for the directly connected network in which the interface resides.

C        10.1.1.0/30 is directly connected, Ethernet0/0

L        10.1.1.1/32 is directly connected, Ethernet0/0

Floating Static

A floating static route is simply one that has been created as a backup to a route learned though a routing protocol. By creating the static route with an administrative distance larger than that of the routing protocol, we can prevent the use of the static route unless the dynamic route is unavailable. The following example configures a static route with a distance of 125, which would prevent it from being placed in the routing table as long as a route to the same network with a lower distance value is present ( for example, a RIP route that has a distance of 120). Router(config)#ip route 192.168.4.0 255.255.255.0 125.

Exam Essentials

Configure static routes at the CLI. The command syntax to add a route is ip route [destination_network] [mask] [next-hop_ address or exitinterface] [administrative_distance] [permanent].

Create a default route. To add a default route, use the command syntax ip route 0.0.0.0 0.0.0.0 ip-address or exit interface type and number.

Configure, verify, and troubleshoot single area and multi-area OSPFv2 for IPv4 (excluding authentication, filtering, manual summarization, redistribution, stub, virtual-link, and LSAs)

Configuring basic OSPF isn't as simple as configuring RIP and EIGRP, and it can get really complex once the many options that are allowed within OSPF are factored in. But that's okay because you really only need to focus on basic, single-area OSPF configuration at this point. Coming up, I'll show you how to configure single-area OSPF.

The two factors that are foundational to OSPF configuration are enabling OSPF and configuring OSPF areas.

Enabling Single Area OSPF

The easiest and also least scalable way to configure OSPF is to just use a single area. Doing this requires a minimum of two commands.

The first command used to activate the OSPF routing process is as follows:

Router(config)#router ospf ?

<1-65535> Process ID

A value in the range from 1 to 65,535 identifies the OSPF process ID. It's a unique number on this router that groups a series of OSPF configuration commands under a specific running process. Different OSPF routers don't have to use the same process ID to communicate. It's a purely local value that doesn't mean a lot, but you still need to remember that it cannot start at 0; it has to start at a minimum of 1.

You can have more than one OSPF process running simultaneously on the same router if you want, but this isn't the same as running multi-area OSPF. The second process will maintain an entirely separate copy of its topology table and manage its communications independently of the first one, and you use it when you want OSPF to connect multiple ASs together. Also, because the Cisco exam objectives only cover single-area OSPF with each router running a single OSPF process, that's what we'll focus on in this book.

Configuring OSPF Areas

After identifying the OSPF process, you need to identify the interfaces that you want to activate OSPF communications on as well as the area in which each resides. This will also configure the networks you're going to advertise to others.

Here's an example of a basic OSPF configuration for you, showing our second minimum command needed, the network command:

Router#config t

Router(config)#router ospf 1

Router(config-router)#network 10.0.0.0 0.255.255.255 area ?

  <0-4294967295>  OSPF area ID as a decimal value

  A.B.C.D         OSPF area ID in IP address format

Router(config-router)#network 10.0.0.0 0.255.255.255 area 0

Remember, the OSPF process ID number is irrelevant. It can be the same on every router on the network, or it can be different—doesn't matter. It's locally significant and just enables the OSPF routing on the router.

The arguments of the network command are the network number (10.0.0.0) and the wildcard mask (0.255.255.255). The combination of these two numbers identifies the interfaces that OSPF will operate on and will also be included in its OSPF LSA advertisements. Based on my sample configuration, OSPF will use this command to find any interface on the router configured in the 10.0.0.0 network and will place any interface it finds into area 0. Notice that you can create about 4.2 billion areas! In reality, a router wouldn't let you create that many, but you can certainly name them using the numbers up to 4.2 billion. You can also label an area using an IP address format.

Let me stop here a minute to give you a quick explanation of wildcards: A 0 octet in the wildcard mask indicates that the corresponding octet in the network must match exactly. On the other hand, a 255 indicates that you don't care what the corresponding octet is in the network number. A network and wildcard mask combination of 1.1.1.1 0.0.0.0 would match an interface configured exactly with 1.1.1.1 only, and nothing else. This is really useful if you want to activate OSPF on a specific interface in a very clear and simple way. If you insist on matching a range of networks, the network and wildcard mask combination of 1.1.0.0 0.0.255.255 would match any interface in the range of 1.1.0.0 to 1.1.255.255. Because of this, it's simpler and safer to stick to using wildcard masks of 0.0.0.0 and identify each OSPF interface individually. Once configured, they'll function exactly the same—one way really isn't better than the other.

The final argument is the area number. It indicates the area to which the interfaces identified in the network and wildcard mask portion belong. Remember that OSPF routers will become neighbors only if their interfaces share a network that's configured to belong to the same area number. The format of the area number is either a decimal value from the range 0 to 4,294,967,295 or a value represented in standard dotted-decimal notation. For example, area 0.0.0.0 is a legitimate area and is identical to area 0.

Wildcard Example

Before getting down to configuring our network, let's take a quick peek at a more complex OSPF network configuration to find out what our OSPF network statements would be if we were using subnets and wildcards.

In this scenario, you have a router with these four subnets connected to four different interfaces:

• 192.168.10.64/28
• 192.168.10.80/28
• 192.168.10.96/28
• 192.168.10.8/30

All interfaces need to be in area 0, so it seems to me the easiest configuration would look like this:

Test#config t

Test(config)#router ospf 1

Test(config-router)#network 192.168.10.0 0.0.0.255 area 0

I'll admit that the preceding example is actually pretty simple, but easy isn't always best—especially when dealing with OSPF! So even though this is an easy-button way to configure OSPF, it doesn't make good use of its capabilities, and what fun is that? Worse yet, the objectives aren't very likely to present something this simple for you! So let's create a separate network statement for each interface using the subnet numbers and wildcards. Doing that would look something like this:

Test#config t

Test(config)#router ospf 1

Test(config-router)#network 192.168.10.64 0.0.0.15 area 0

Test(config-router)#network 192.168.10.80 0.0.0.15 area 0

Test(config-router)#network 192.168.10.96 0.0.0.15 area 0

Test(config-router)#network 192.168.10.8 0.0.0.3 area 0

Wow, now that's a different looking config! Truthfully, OSPF would work exactly the same way as it would with the easy configuration I showed you first—but unlike the easy configuration, this one covers the objectives!

And although this looks a bit complicated, trust me, it really isn't. All you need for clarity is to fully understand your block sizes! Just remember that when configuring wildcards, they're always one less than the block size. A /28 is a block size of 16, so we would add our network statement using the subnet number and then add a wildcard of 15 in the interesting octet. For the /30, which is a block size of 4, we would go with a wildcard of 3. Once you practice this a few times, it gets really easy. And do practice because we'll deal with them again when we get to access lists later on!

Let's use Figure 3.14 as an example and configure that network with OSPF using wildcards to make sure you have a solid grip on this. The figure shows a three-router network with the IP addresses of each interface.

The very first thing you need to be able to do is to look at each interface and determine the subnet that the addresses are in. Hold on, I know what you're thinking: “Why don't I just use the exact IP addresses of the interface with the 0.0.0.0 wildcard?” Well, you can, but we're paying attention to Cisco exam objectives here, not just what's easiest, remember?

The IP addresses for each interface are shown in Figure 3.14. The Lab A router has two directly connected subnets: 192.168.10.64/29 and 10.255.255.80/30. Here's the OSPF configuration using wildcards:

Lab_A#config t

Lab_A(config)#router ospf 1

Lab_A(config-router)#network 192.168.10.64 0.0.0.7 area 0

Lab_A(config-router)#network 10.255.255.80 0.0.0.3 area 0

The Lab A router is using a /29, or 255.255.255.248, mask on the Fa0/0 interface. This is a block size of 8, which is a wildcard of 7. The G0/0 interface is a mask of 255.255.255.252—block size of 4, with a wildcard of 3. Notice that I typed in the network number, not the interface number. You can't configure OSPF this way if you can't look at the IP address and slash notation and then figure out the subnet, mask, and wildcard, can you? So don't take your exam until you can do this.

Here are other two configurations to help you practice:

Lab_B#config t

Lab_B(config)#router ospf 1

Lab_B(config-router)#network 192.168.10.48 0.0.0.7 area 0

Lab_B(config-router)#network 10.255.255.80 0.0.0.3 area 0

Lab_B(config-router)#network 10.255.255.8 0.0.0.3 area 0

 

Lab_C#config t

Lab_C(config)#router ospf 1

Lab_C(config-router)#network 192.168.10.16 0.0.0.7 area 0

Lab_C(config-router)#network 10.255.255.8 0.0.0.3 area 0

As I mentioned with the Lab A configuration, you've got to be able to determine the subnet, mask, and wildcard just by looking at the IP address and mask of an interface. If you can't do that, you won't be able to configure OSPF using wildcards as I just demonstrated. So go over this until you're really comfortable with it!

Configuring Our Network with OSPF

Now we get to have some fun! Let's configure our internetwork with OSPF using just area 0. OSPF has an administrative distance of 110, but let's remove RIP while we're at it because I don't want you to get in the habit of having RIP running on your network.

There's a bunch of different ways to configure OSPF, and as I said, the simplest and easiest is to use the wildcard mask 0.0.0.0. But I want to demonstrate that we can configure each router differently with OSPF and still come up with the exact same result. This is one reason why OSPF is more fun and challenging than other routing protocols—it gives us all a lot more ways to screw things up, which automatically provides a troubleshooting opportunity! We'll use our network as shown in Figure 3.15 to configure OSPF, and by the way, notice I added a new router!

Corp

Here's the Corp router's configuration:

Corp#sh ip int brief

Interface        IP-Address      OK? Method Status                Protocol

 

FastEthernet0/0  10.10.10.1      YES manual up                    up

Serial0/0        172.16.10.1     YES manual up                    up

FastEthernet0/1  unassigned      YES unset  administratively down down

Serial0/1        172.16.10.5     YES manual up                    up

Corp#config t

Corp(config)#no router rip

Corp(config)#router ospf 132

Corp(config-router)#network 10.10.10.1 0.0.0.0 area 0

Corp(config-router)#network 172.16.10.1 0.0.0.0 area 0

Corp(config-router)#network 172.16.10.5 0.0.0.0 area 0

Alright—it looks like we have a few things to talk about here. First, I removed RIP and then added OSPF. Why did I use OSPF 132? It really doesn't matter—the number is irrelevant. I guess it just felt good to use 132. But notice that I started with the show ip int brief command, just like when I was configuring RIP. I did this because it's always important to verify exactly what you are directly connected to. Doing this really helps prevent typos!

The network commands are pretty straightforward. I typed in the IP address of each interface and used the wildcard mask of 0.0.0.0, which means that the IP address must precisely match each octet. This is actually one of those times where easier is better, so just do this:

Corp(config)#router ospf 132

Corp(config-router)#network 172.16.10.0 0.0.0.255 area 0

Nice—there's only one line instead of two for the 172.16.10.0 network! I really want you to understand that OSPF will work the same here no matter which way you configure the network statement. Now, let's move on to SF. To simplify things, we're going to use our same sample configuration.

SF

The SF router has two directly connected networks. I'll use the IP addresses on each interface to configure this router.

SF#sh ip int brief

Interface    IP-Address      OK? Method Status                Protocol

FastEthernet0/0  192.168.10.1    YES manual up                    up

FastEthernet0/1  unassigned      YES unset  administratively down down

Serial0/0/0      172.16.10.2     YES manual up                    up

Serial0/0/1      unassigned      YES unset  administratively down down

SF#config t

SF(config)#no router rip

SF(config)#router ospf 300

SF(config-router)#network 192.168.10.1 0.0.0.0 area 0

SF(config-router)#network 172.16.10.2 0.0.0.0 area 0

*Apr 30 00:25:43.810: %OSPF-5-ADJCHG: Process 300, Nbr 172.16.10.5 on Serial0/0/0 from LOADING to FULL, Loading Done

Here, all I did was to first disable RIP, turn on OSPF routing process 300, and then I added my two directly connected networks. Now let's move on to LA!

LA

We're going to give some attention to the LA router that's directly connected to two networks:

LA#sh ip int brief

Interface    IP-Address      OK? Method Status                Protocol

FastEthernet0/0 192.168.20.1    YES manual up                    up

FastEthernet0/1 unassigned      YES unset  administratively down down

Serial0/0/0     unassigned      YES unset  administratively down down

Serial0/0/1     172.16.10.6     YES manual up                    up

LA#config t

LA(config)#router ospf 100

LA(config-router)#network 192.168.20.0 0.0.0.255 area 0

LA(config-router)#network 172.16.0.0 0.0.255.255 area 0

*Apr 30 00:56:37.090: %OSPF-5-ADJCHG: Process 100, Nbr 172.16.10.5 on Serial0/0/1 from LOADING to FULL, Loading Done

Remember that when you're configuring dynamic routing, using the show ip int brief command first will make it all so much easier!

And don't forget, I can use any process ID I want, as long as it's a value from 1 to 65,535, because it doesn't matter if all routers use the same process ID. Also, notice that I used different wildcards in this example. Doing this works really well too.

Okay, I want you to think about something for a second before we move onto more advanced OSPF topics: What if the Fa0/1 interface of the LA router was connected to a link that we didn't need to send OSPF hellos ( no other OSPF routers), as shown in Figure 3.16.

We can use the passive-interface command under the routing process to prevent OSPF hellos from being transmitted! Take a look:

LA(config)#router ospf 100

LA(config-router)#passive-interface fastEthernet 0/1

Even though this is pretty simple, you've really got to be careful before you configure this command on your router! I added this command as an example on interface Fa0/1, which happens to be an interface we're not using in this network because I want OSPF to work on my other router's interfaces.

Now it's time to configure our Corp router to advertise a default route to the SF and LA routers because doing so will make our lives a lot easier. Instead of having to configure all our routers with a default route, we'll only configure one router and then advertise that this router is the one that holds the default route—elegant!

In Figure 3.16, keep in mind that, for now, the corporate router is connected to the Internet off of Fa0/0. We'll create a default route toward this imaginary Internet and then tell the other routers that this is the route they'll use to get to the Internet. Here is the configuration:

Corp#config t

Corp(config)#ip route 0.0.0.0 0.0.0.0 Fa0/0

Corp(config)#router ospf 1

Corp(config-router)#default-information originate

Now, let's check and see if our other routers have received this default route from the Corp router:

SF#show ip route

[output cut]

E1 - OSPF external type 1, E2 - OSPF external type 2

[output cut]

O*E2 0.0.0.0/0 [110/1] via 172.16.10.1, 00:01:54, Serial0/0/0

SF#

Sure enough—the last line in the SF router shows that it received the advertisement from the Corp router regarding the fact that the corporate router is the one holding the default route out of the AS.

But hold on a second! I need to configure our new router into my lab to create the example network we'll use from here on. Here's the configuration of the new router that I connected to the same network that the Corp router is connected to via the Fa0/0 interface:

Router#config t

Router(config)#hostname Boulder

Boulder(config)#int f0/0

Boulder(config-if)#ip address 10.10.10.2 255.255.255.0

Boulder(config-if)#no shut

*Apr  6 18:01:38.007: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up

Boulder(config-if)#router ospf 2

Boulder(config-router)#network 10.0.0.0 0.255.255.255 area 0

*Apr  6 18:03:27.267: %OSPF-5-ADJCHG: Process 2, Nbr 223.255.255.254 on FastEthernet0/0 from LOADING to FULL, Loading Done

This is all good, but I need to make sure that you don't follow my example to a tee because here, I just quickly brought a router up without setting my passwords first. I can get away with this only because I am in a nonproduction network, so don't do this in the real world where security is key!

Anyway, now that I have my new router nicely connected with a basic configuration, we're going to move on to cover loopback interfaces, how to set the router ID (RID) used with OSPF, and finally, how to verify OSPF.

OSPF and Loopback Interfaces

It's really vital to configure loopback interfaces when using OSPF. In fact, Cisco suggests using them whenever you configure OSPF on a router for stability purposes.

Loopback interfaces are logical interfaces, which means they're virtual, software-only interfaces, not actual, physical router interfaces. A big reason we use loopback interfaces with OSPF configurations is because they ensure that an interface is always active and available for OSPF processes.

Loopback interfaces also come in very handy for diagnostic purposes as well as for OSPF configuration. Understand that if you don't configure a loopback interface on a router, the highest active IP address on a router will become that router's RID during bootup! Figure 3.17 illustrates how routers know each other by their router ID.

The RID is not only used to advertise routes, it's also used to elect the designated router (DR) and the backup designated router (BDR). These designated routers create adjacencies when a new router comes up and exchanges LSAs to build topological databases.

Now it's time to show you how to configure these logical loopback interfaces and how to verify them, as well as verify RIDs.

Configuring Loopback Interfaces

Configuring loopback interfaces rocks mostly because it's the easiest part of OSPF configuration, and we all need a break about now—right? So hang on—we're in the home stretch!

First, let's see what the RID is on the Corp router with the show ip ospf command:

Corp#sh ip ospf

 Routing Process "ospf 1" with ID 172.16.10.5

[output cut]

Okay, we can see that the RID is 172.16.10.5—the Serial0/1 interface of the router. So let's configure a loopback interface using a completely different IP addressing scheme:

Corp(config)#int loopback 0

*Mar 22 01:23:14.206: %LINEPROTO-5-UPDOWN: Line protocol on Interface

   Loopback0, changed state to up

Corp(config-if)#ip address 172.31.1.1 255.255.255.255

The IP scheme really doesn't matter here, but each one being in a separate subnet does! By using the /32 mask, we can use any IP address we want as long as the addresses are never the same on any two routers.

Let's configure the other routers now:

SF#config t

SF(config)#int loopback 0

*Mar 22 01:25:11.206: %LINEPROTO-5-UPDOWN: Line protocol on Interface

   Loopback0, changed state to up

SF(config-if)#ip address 172.31.1.2 255.255.255.255

Here's the configuration of the loopback interface on LA:

LA#config t

LA(config)#int loopback 0

*Mar 22 02:21:59.686: %LINEPROTO-5-UPDOWN: Line protocol on Interface

   Loopback0, changed state to up

LA(config-if)#ip address 172.31.1.3 255.255.255.255

I'm pretty sure you're wondering what the IP address mask of 255.255.255.255 (/32) means and why we don't just use 255.255.255.0 instead. While it's true that either mask works, the /32 mask is called a host mask and works fine for loopback interfaces. It also allows us to save subnets. Notice how I was able to use 172.31.1.1, .2, and .3. If I didn't use the /32, I'd have to use a separate subnet for each and every router—not good!

One important question to answer before we move on is did we actually change the RIDs of our router by setting the loopback interfaces? Let's find out by taking a look at the Corp's RID:

Corp#sh ip ospf

 Routing Process "ospf 1" with ID 172.16.10.5

What happened here? You would think that because we set logical interfaces, the IP addresses under them would automatically become the RID of the router, right? Well, sort of, but only if you do one of two things: either reboot the router or delete OSPF and re-create the database on your router. Neither is all that great an option, so try to remember to create your logical interfaces before you start OSPF routing. That way, the loopback interface would always become your RID straight away!

With all this in mind, I'm going with rebooting the Corp router because it's the easier of the two options I have right now.

Now let's look and see what our RID is:

Corp#sh ip ospf

 Routing Process "ospf 1" with ID 172.31.1.1

That did the trick! The Corp router now has a new RID, so I guess I'll just go ahead and reboot all my routers to get their RIDs reset to our logical addresses. But should I really do that?

Maybe not because there is one other way. What do you think about adding a new RID for the router right under the router ospf process-id command instead? Sounds good, so I'd say let's give that a shot! Here's an example of doing that on the Corp router:

Corp#config t

Corp(config)#router ospf 1

Corp(config-router)#router-id 223.255.255.254

Reload or use "clear ip ospf process" command, for this to take effect

Corp(config-router)#do clear ip ospf process

Reset ALL OSPF processes? [no]: yes

*Jan 16 14:20:36.906: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.20.1

on Serial0/1 from FULL to DOWN, Neighbor Down: Interface down

or detached

*Jan 16 14:20:36.906: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.10.1

on Serial0/0 from FULL to DOWN, Neighbor Down: Interface down

or detached

*Jan 16 14:20:36.982: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.20.1

on Serial0/1 from LOADING to FULL, Loading Done

*Jan 16 14:20:36.982: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.10.1

on Serial0/0 from LOADING to FULL, Loading Done

Corp(config-router)#do sh ip ospf

 Routing Process "ospf 1" with ID 223.255.255.254

Now look at that—it worked! We changed the RID without reloading the router! But wait—remember, we set a logical loopback interface earlier. Does that mean the loopback interface will win over the router-id command? Well, we can see our answer. . . A loopback interface will not override the router-id command, and we don't have to reboot the router to make it take effect as the RID!

So this process follows this hierarchy:

1. Highest active interface by default
2. Highest logical interface overrides a physical interface.
3. The router-id overrides the interface and loopback interface.

The only thing left now is to decide whether you want to advertise the loopback interfaces under OSPF. There are pros and cons to using an address that won't be advertised versus using an address that will be. Using an unadvertised address saves on real IP address space, but the address won't appear in the OSPF table, which means you can't ping it.

So basically, what you're faced with here is a choice that equals a trade-off between the ease of debugging the network and conservation of address space—what to do? A really tight strategy is to use a private IP address scheme as I did. Do this and all will be well!

Now that we've configured all the routers with OSPF, what's next? Miller time? Nope—not yet. It's that verification thing again. We still have to make sure that OSPF is really working, and that's exactly what we're going to do next.

Verifying OSPF Configuration

There are several ways to verify proper OSPF configuration and operation, so next, I'm going to demonstrate the various OSPF show commands you need to know in order to achieve this. We're going to start by taking a quick look at the routing table of the Corp router.

First, let's issue a show ip route command on the Corp router:

O    192.168.10.0/24 [110/65] via 172.16.10.2, 1d17h, Serial0/0

     172.131.0.0/32 is subnetted, 1 subnets

    172.131.0.0/32 is subnetted, 1 subnets

C        172.131.1.1 is directly connected, Loopback0

     172.16.0.0/30 is subnetted, 4 subnets

C       172.16.10.4 is directly connected, Serial0/1

L       172.16.10.5/32 is directly connected, Serial0/1

C       172.16.10.0 is directly connected, Serial0/0

L       172.16.10.1/32 is directly connected, Serial0/0

O    192.168.20.0/24 [110/65] via 172.16.10.6, 1d17h, Serial0/1

     10.0.0.0/24 is subnetted, 2 subnets

C       10.10.10.0 is directly connected, FastEthernet0/0

L       10.10.10.1/32 is directly connected, FastEthernet0/0

The Corp router shows only two dynamic routes for the internetwork, with the O representing OSPF internal routes. The Cs are clearly our directly connected networks, and our two remote networks are showing up too—nice! Notice the 110/65, which is our administrative distance/metric.

Now that's a really sweet-looking OSPF routing table! It's important to make it easier to troubleshoot and fix an OSPF network, which is why I always use the show ip int brief command when configuring my routing protocols. It's very easy to make little mistakes with OSPF, so keep your eyes on the details!

It's time to show you all the OSPF verification commands that you need in your toolbox for now.

The show ip ospf Command

The show ip ospf command is what you'll need to display OSPF information for one or all OSPF processes running on the router. Information contained therein includes the router ID, area information, SPF statistics, and LSA timer information. Let's check out the output from the Corp router:

Corp#sh ip ospf

 Routing Process "ospf 1" with ID 223.255.255.254

 Start time: 00:08:41.724, Time elapsed: 2d16h

 Supports only single TOS(TOS0) routes

 Supports opaque LSA

 Supports Link-local Signaling (LLS)

 Supports area transit capability

 Router is not originating router-LSAs with maximum metric

 Initial SPF schedule delay 5000 msecs

 Minimum hold time between two consecutive SPFs 10000 msecs

 Maximum wait time between two consecutive SPFs 10000 msecs

 Incremental-SPF disabled

 Minimum LSA interval 5 secs

 Minimum LSA arrival 1000 msecs

 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 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 1. 1 normal 0 stub 0 nssa

 Number of areas transit capable is 0

 External flood list length 0

 IETF NSF helper support enabled

 Cisco NSF helper support enabled

    Area BACKBONE(0)

        Number of interfaces in this area is 3

        Area has no authentication

        SPF algorithm last executed 00:11:08.760 ago

        SPF algorithm executed 5 times

        Area ranges are

        Number of LSA 6. Checksum Sum 0x03B054

        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

Notice the router ID (RID) of 223.255.255.254, which is the highest IP address configured on the router. Hopefully, you also noticed that I set the RID of the corporate router to the highest IP address available with IPv4.

The show ip ospf database Command

Using the show ip ospf database command will give you information about the number of routers in the internetwork (AS) plus the neighboring router's ID—the topology database I mentioned earlier. Unlike the show ip eigrp topology command, this command reveals the OSPF routers, but not each and every link in the AS like EIGRP does.

The output is broken down by area. Here's a sample output, again from Corp:

Corp#sh ip ospf database

 

                OSPF Router with ID (223.255.255.254) (Process ID 1)

Router Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum Link count

10.10.10.2      10.10.10.2      966         0x80000001 0x007162 1

172.31.1.4      172.31.1.4      885         0x80000002 0x00D27E 1

192.168.10.1    192.168.10.1    886         0x8000007A 0x00BC95 3

192.168.20.1    192.168.20.1    1133        0x8000007A 0x00E348 3

223.255.255.254 223.255.255.254 925         0x8000004D 0x000B90 5

 

                Net Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum

10.10.10.1      223.255.255.254 884         0x80000002 0x008CFE

You can see all the routers and the RID of each router—the highest IP address on each of them. For example, the link ID and ADV router of my new Boulder router shows up twice: once with the directly connected IP address (10.10.10.2) and as the RID that I set under the OSPF process (172.31.1.4).

The router output shows the link ID—remember that an interface is also a link—and the RID of the router on that link under the ADV router, or advertising router.

The show ip ospf interface Command

The show ip ospf interface command reveals all interface-related OSPF information. Data is displayed about OSPF information for all OSPF-enabled interfaces or for specified interfaces. I'll highlight some of the more important factors for you. Check it out:

Corp#sh ip ospf int f0/0

FastEthernet0/0 is up, line protocol is up

  Internet Address 10.10.10.1/24, Area 0

  Process ID 1, Router ID 223.255.255.254, Network Type BROADCAST, Cost: 1

  Transmit Delay is 1 sec, State DR, Priority 1

  Designated Router (ID) 223.255.255.254, Interface address 10.10.10.1

  Backup Designated router (ID) 172.31.1.4, Interface address 10.10.10.2

  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

    oob-resync timeout 40

    Hello due in 00:00:08

  Supports Link-local Signaling (LLS)

  Cisco NSF helper support enabled

  IETF NSF helper support enabled

  Index 3/3, flood queue length 0

  Next 0x0(0)/0x0(0)

  Last flood scan length is 1, maximum is 1

  Last flood scan time is 0 msec, maximum is 0 msec

  Neighbor Count is 1, Adjacent neighbor count is 1

    Adjacent with neighbor 172.31.1.  Suppress hello for 0 neighbor(s)

So this command has given us the following information:

• Interface IP address
• Area assignment
• Process ID
• Router ID
• Network type
• Cost
• Priority
• DR/BDR election information (if applicable)
• Hello and dead timer intervals
• Adjacent neighbor information

The reason I used the show ip ospf interface f0/0 command is because I knew that there would be a designated router elected on the FastEthernet broadcast multi-access network between our Corp and Boulder routers. The information that I highlighted is all very important, so make sure you've noted it! A good question to ask you here is what are the hello and dead timers set to by default?

Type in the show ip ospf interface command and receive this response:

Corp#sh ip ospf int f0/0

%OSPF: OSPF not enabled on FastEthernet0/0

This error occurs when OSPF is enabled on the router, but not the interface. When this happens, you need to check your network statements because it means that the interface you're trying to verify is not in your OSPF process!

The show ip ospf neighbor Command

The show ip ospf neighbor command is super-useful because it summarizes the pertinent OSPF information regarding neighbors and the adjacency state. If a DR or BDR exists, that information will also be displayed. Here's a sample:

Corp#sh ip ospf neighbor

 

Neighbor ID     Pri   State      Dead Time   Address         Interface

172.31.1.4        1   FULL/BDR   00:00:34    10.10.10.2     FastEthernet0/0

192.168.20.1      0   FULL/  -   00:00:31    172.16.10.6     Serial0/1

192.168.10.1      0   FULL/  -   00:00:32    172.16.10.2     Serial0/0

This is a critical command to understand because it's extremely useful in production networks. Let's take a look at the Boulder router output:

Boulder>sh ip ospf neighbor

 

Neighbor ID     Pri   State    Dead Time   Address         Interface

223.255.255.254   1   FULL/DR  00:00:31    10.10.10.1      FastEthernet0/0

Here we can see that since there's an Ethernet link (broadcast multi-access) on the link between the Boulder and the Corp router, there's going to be an election to determine who will be the designated router (DR) and who will be the backup designated router (BDR). We can see that the Corp became the designated router, and it won because it had the highest IP address on the network—the highest RID.

Now the reason that the Corp connections to SF and LA don't have a DR or BDR listed in the output is that by default, elections don't happen on point-to-point links and they show FULL/ -. But we can still determine that the Corp router is fully adjacent to all three routers from its output.

The show ip protocols Command

The show ip protocols command is also highly useful, whether you're running OSPF, EIGRP, RIP, BGP, IS-IS, or any other routing protocol that can be configured on your router. It provides an excellent overview of the actual operation of all currently running protocols!

Check out the output from the Corp router:

Corp#sh ip protocols

Routing Protocol is "ospf 1"

  Outgoing update filter list for all interfaces is not set

  Incoming update filter list for all interfaces is not set

  Router ID 223.255.255.254

  Number of areas in this router is 1. 1 normal 0 stub 0 nssa

  Maximum path: 4

  Routing for Networks:

    10.10.10.1 0.0.0.0 area 0

    172.16.10.1 0.0.0.0 area 0

    172.16.10.5 0.0.0.0 area 0

 Reference bandwidth unit is 100 mbps

  Routing Information Sources:

    Gateway         Distance      Last Update

    192.168.10.1         110      00:21:53

    192.168.20.1         110      00:21:53

  Distance: (default is 110) Distance: (default is 110)

From looking at this output, you can determine the OSPF process ID, OSPF router ID, type of OSPF area, networks and areas configured for OSPF, and the OSPF router IDs of neighbors—that's a lot. It's super-efficient!

Multi-Area OSPF

Basic multi-area configuration isn't all that hard. Understanding your design, layout, and types of LSAs and DRs and configuring the elections, troubleshooting, and fully comprehending what's happening in the background are really the most complicated aspects of OSPF.

As I was saying, configuring OSPF is pretty simple, and you'll see toward the end of this chapter that configuring OSPFv3 is even easier! After I show you the basic OSPF multi-area configuration in this section, we'll work on the verification of OSPF. Let's get the ball rolling with the multi-area configuration shown in Figure 3.18.

We're going to create three areas. I've verified that the IPv4 addresses are on the interfaces and working as well since then, so we're all set to rock the configs for this chapter! Here's the Corp configuration:

Corp#config t

Corp(config)#router ospf 1

Corp(config-router)#router-id 1.1.1.1

Corp(config-router)#Reload or use "clear ip ospf process" command, for this to

take effect

 

Corp(config-router)#network 10.10.0.0 0.0.255.255 area 0

Corp(config-router)#network 172.16.10.0 0.0.0.3 area 1

Corp(config-router)#network 172.16.10.4 0.0.0.3 area 2

Pretty straightforward, but let's talk about it anyway. First I started the OSPF process with the router ospf process-id command, using any number from 1–65,535 because they're only locally significant, so they don't need to match my neighbor routers. I set the RID of the router only to remind you that this can be configured under the router process, but with our small network it wouldn't really be necessary to mess with RIDs if this was an actual production network. The one thing that you need to keep in mind here is that in OSPF, the RID must be different on each router. With EIGRP, they can all be the same because they are not as important in that process. Still, as I'll show you in the EIGRPv6 section, we still need them!

Anyway, at this point in the configurations I needed to choose my network statements for the OSPF process to use, which allowed me to place my four interfaces on the Corp router into three different areas. In the first network statement, 10.10.0.0 0.0.255.255, I placed the g0/0 and g0/1 interfaces into area 0. The second and third statements needed to be more exact since there are /30 networks. 172.16.10.0 0.0.0.3 tells OSPF process 1 to go find an active interface that's configured with 172.16.10.1 or .2 and to place that interface into area 1. The last line tells the OSPF process to go find any active interface configured with 172.16.10.5 or .6 and place that interface into area 2. The wildcard of 0.0.0.3 means the first three octets can match any value, but the last octet is a block size of 4.

The only thing different about these configurations from those in the single-area OSPF is the different areas at the end of the command—that's it!

Here is the configuration for the SF and NY routers:

SF(config)#router ospf 1

SF(config-router)#network 10.10.0.0 0.0.255.255 area 1

SF(config-router)#network 172.16.0.0 0.0.255.255 area 1

 

NY(config)#router ospf 1

NY(config-router)#network 0.0.0.0 255.255.255.255 area 2

00:01:07: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial0/0/0 from LOADING to FULL,

Loading Done

I configured each one slightly different from the Corp router, but since they didn't have an interface in more than area 1, I had more leeway in configuring them. For the NY router I just configured a network statement (0.0.0.0 255.255.255.255) that says “go find any active interface and place it into area 2!” I'm not recommending that you configure your routers in such a broad manner; I just wanted to show you your options.

Before we move onto verifying our network, let me show you another way that the CCNA objectives configure OSPF. For the Corp router, we had three network statements, which covered the four interfaces used. We could have configured the OSPF process like this on the Corp router (or all routers); it doesn't matter which way you choose:

Corp(config)#router ospf 1

Corp(config-router)#router-id 1.1.1.1

Corp(config-router)#int g0/0

Corp(config-if)#ip ospf 1 area 0

Corp(config-if)#int g0/1

Corp(config-if)#ip ospf 1 area 0

Corp(config-if)#int s0/0

Corp(config-if)#ip ospf 1 area 1

Corp(config-if)#int s0/1

Corp(config-if)#ip ospf 1 area 2

First I chose my process ID, then set my RID (this absolutely must be different on every router in your internetwork!), then I just went to each interface and told it what area it was in. Easy! No network commands to screw up! Nice. Again, you can configure it with the network statement or the interface statement, it doesn't matter, but you need to really remember this for the CCNA objectives!

Now that our three routers are configured, let's verify our internetwork.

Verifying and Troubleshooting Multi-Area OSPF Networks

Cisco's IOS has several show and debug commands that can help you monitor and troubleshoot OSPF networks. A sampling of these commands, which can be used to gain information about various OSPF characteristics, is included in Table 3.2.

Table 3.2 OSPF verification commands

Let's go through some verification commands—the same commands we used to verify our single-area OSPF network.

Okay, once you've checked the link between your neighbors and can use the Ping program, the best command when verifying a routing protocol is to always check the status of your neighbor's connection first. The show ip ospf neighbor command is super useful because it summarizes the pertinent OSPF information regarding neighbors and their adjacency state. If a DR or BDR exists, that information will also be displayed. Here's a sample:

Corp#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

172.16.10.2       0   FULL/  -        00:00:34    172.16.10.2     Serial0/0/0

172.16.10.6       0   FULL/  -        00:00:31    172.16.10.6     Serial0/0/1

 

SF#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

1.1.1.1           0   FULL/  -        00:00:39    172.16.10.1     Serial0/0/0

 

NY#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

1.1.1.1           0   FULL/  -        00:00:34    172.16.10.5     Serial0/0/0

The reason that the Corp connections to SF and NY don't have a DR or BDR listed in the output is that by default, elections don't happen on point-to-point links and they show FULL/-. But we can see that the Corp router is fully adjacent to all three routers from its output.

The output of this command shows the neighbor ID, which is the RID of the router. Notice in the output of the Corp router that the RIDs for the SF and NY routers were chosen based on the highest IP address of any active interface when I started the OSPF process on those routers. Both the SF and NY routers see the Corp router RID as 1.1.1.1 because I set that manually under the router ospf process command.

Next we see the Pri field, which is the priority field that's set to 1 by default. Don't forget that on point-to-point links, elections don't happen, so the interfaces are all set to 0 in this example because none of these routers will have elections on these interfaces with each other over this serial WAN network. The state field shows Full/-, which means all routers are synchronized with their LSDB, and the /- means there is no election on this type of interface. The dead timer is counting down, and if the router does not hear from this neighbor before this expires, the link will be considered down. The address is the actual address of the neighbor's interface connecting to the router, and the interface is the neighbor's interface—not your interface!

The show ip ospf Command

We use the show ip ospf command to display OSPF information for one or all OSPF processes running on the router. Information contained therein includes the router ID, area information, SPF statistics, and LSA timer information. Let's check out the output from the Corp router:

Corp#sh ip ospf

 Routing Process "ospf 1" with ID 1.1.1.1

 Supports only single TOS(TOS0) routes

 Supports 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 19 times

        Area ranges are

        Number of LSA 7. Checksum Sum 0x0384d5

        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 1

        Number of interfaces in this area is 1

        Area has no authentication

        SPF algorithm executed 43 times

        Area ranges are

        Number of LSA 7. Checksum Sum 0x0435f8

        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 2

        Number of interfaces in this area is 1

        Area has no authentication

        SPF algorithm executed 38 times

        Area ranges are

        Number of LSA 7. Checksum Sum 0x0319ed

        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

You'll notice that most of the preceding information wasn't displayed with this command output in single-area OSPF. We have more displayed here because it's providing information about each area we've configured on this router.

The show ip ospf interface Command

The show ip ospf interface command displays all interface-related OSPF information. Data is displayed for all OSPF-enabled interfaces or for specified interfaces. I'll highlight some important portions I want you to pay special attention to.

Corp#sh ip ospf interface gi0/0

GigabitEthernet0/0 is up, line protocol is up

  Internet address is 10.10.10.1/24, Area 0

  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1

  Transmit Delay is 1 sec, State DR, Priority 1

  Designated Router (ID) 1.1.1.1, Interface address 10.10.10.1

  No backup designated router on this network

  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

    Hello due in 00:00:05

  Index 1/1, 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 0, Adjacent neighbor count is 0

  Suppress hello for 0 neighbor(s)

Let's take a look at a serial interface so we can compare it to the Gigabit Ethernet interface just shown. The Ethernet network is a broadcast multi-access network by default, and the serial interface is a point-to-point non-broadcast multi-access network, so they will act differently with OSPF:

Corp#sh ip ospf interface s0/0/0

Serial0/0/0 is up, line protocol is up

  Internet address is 172.16.10.1/30, Area 1

  Process ID 1, Router ID 1.1.1.1, Network Type POINT-TO-POINT, Cost: 64

  Transmit Delay is 1 sec, State POINT-TO-POINT, Priority 0

  No designated router on this network

  No backup designated router on this network

  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

    Hello due in 00:00:02

  Index 3/3, flood queue length 0

  Next 0x0(0)/0x0(0)

  Last flood scan length is 1, maximum is 1

  Last flood scan time is 0 msec, maximum is 0 msec

  Neighbor Count is 1 , Adjacent neighbor count is 1

    Adjacent with neighbor 172.16.10.2

  Suppress hello for 0 neighbor(s)

The following information is displayed via this command:

• Interface IP address
• Area assignment
• Process ID
• Router ID
• Network type
• Cost
• Priority
• DR/BDR election information (if applicable)
• Hello and dead timer intervals
• Adjacent neighbor information

I used the show ip ospf interface gi0/0 command first because I knew that there would be a designated router elected on the Ethernet broadcast multi-access network on the Corp router, even though it has no one to run against, which means the Corp router automatically wins. The information that I bolded is all very important! What are the hello and dead timers set to by default? Even though I haven't talked much about the cost output on an interface, it can also be very important. Two OSPF routers still could create an adjacency if the costs don't match, but it could lead to certain links not being utilized.

The show ip protocols Command

The show ip protocols command is also useful, whether you're running OSPF, EIGRP, RIP, BGP, IS-IS, or any other routing protocol that can be configured on your router. It provides an excellent overview of the actual operation of all currently running protocols.

Check the output from the Corp router:

Corp#sh ip protocols

Routing Protocol is "ospf 1"

  Outgoing update filter list for all interfaces is not set

  Incoming update filter list for all interfaces is not set

  Router ID 1.1.1.1

  Number of areas in this router is 3. 3 normal 0 stub 0 nssa

  Maximum path: 4

  Routing for Networks:

    10.10.0.0 0.0.255.255 area 0

    172.16.10.0 0.0.0.3 area 1

    172.16.10.4 0.0.0.3 area 2

  Routing Information Sources:

    Gateway         Distance      Last Update

    1.1.1.1              110      00:17:42

    172.16.10.2          110      00:17:42

    172.16.10.6          110      00:17:42

  Distance: (default is 110)

Here we can determine the OSPF process ID, OSPF router ID, type of OSPF area, networks, and the three areas configured for OSPF as well as the OSPF router IDs of neighbors—that's a lot. Read efficient!

The show ip route Command

Now would be a great time to issue a show ip route command on the Corp router. The Corp router shows only four dynamic routes for our internetwork, with the O representing OSPF internal routes. The Cs clearly represent our directly connected networks, but our four remote networks are also showing up—nice! Notice the 110/65, which is the administrative distance/metric:

Corp#sh ip route

[output cut]

     10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks

C       10.10.10.0/24 is directly connected, GigabitEthernet0/0

L       10.10.10.1/32 is directly connected, GigabitEthernet0/0

C       10.10.11.0/24 is directly connected, GigabitEthernet0/1

L       10.10.11.1/32 is directly connected, GigabitEthernet0/1

O       10.10.20.0/24 [110/65] via 172.16.10.2, 02:18:27, Serial0/0/0

O       10.10.30.0/24 [110/65] via 172.16.10.2, 02:18:27, Serial0/0/0

O       10.10.40.0/24 [110/65] via 172.16.10.6, 03:37:24, Serial0/0/1

O       10.10.50.0/24 [110/65] via 172.16.10.6, 03:37:24, Serial0/0/1

     172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks

C       172.16.10.0/30 is directly connected, Serial0/0/0

L       172.16.10.1/32 is directly connected, Serial0/0/0

C       172.16.10.4/30 is directly connected, Serial0/0/1

L       172.16.10.5/32 is directly connected, Serial0/0/1

In addition, you can use the show ip route ospf command to get only OSPF-injected routes in your routing table. I can't stress enough how useful this is when dealing with large networks!

Corp#sh ip route ospf

     10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks

O       10.10.20.0 [110/65] via 172.16.10.2, 02:18:33, Serial0/0/0

O       10.10.30.0 [110/65] via 172.16.10.2, 02:18:33, Serial0/0/0

O       10.10.40.0 [110/65] via 172.16.10.6, 03:37:30, Serial0/0/1

O       10.10.50.0 [110/65] via 172.16.10.6, 03:37:30, Serial0/0/1

Now that's a really nice-looking OSPF routing table! Troubleshooting and fixing an OSPF network is as vital a skill to have as it is in any other networking environment, which is why I always use the show ip int brief command when configuring my routing protocols. It's very easy to make little mistakes with OSPF, so pay very close attention to the details—especially when troubleshooting!

The show ip ospf database Command

Using the show ip ospf database command will give you information about the number of routers in the internetwork (AS), plus the neighboring router's ID. This is the topology database I referred to earlier.

The output is broken down by area. Here's a sample, again from Corp:

Corp#sh ip ospf database

            OSPF Router with ID (1.1.1.1) (Process ID 1)

 

                Router Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum Link count

1.1.1.1         1.1.1.1         196         0x8000001a 0x006d76 2

 

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum

172.16.10.0     1.1.1.1         182         0x80000095 0x00be04

172.16.10.4     1.1.1.1         177         0x80000096 0x009429

10.10.40.0      1.1.1.1         1166        0x80000091 0x00222b

10.10.50.0      1.1.1.1         1166        0x80000092 0x00b190

10.10.20.0      1.1.1.1         1114        0x80000093 0x00fa64

10.10.30.0      1.1.1.1         1114        0x80000094 0x008ac9

 

                Router Link States (Area 1)

 

Link ID         ADV Router      Age         Seq#       Checksum Link count

1.1.1.1         1.1.1.1         1118        0x8000002a 0x00a59a 2

172.16.10.2     172.16.10.2     1119        0x80000031 0x00af47 4

 

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum

10.10.10.0      1.1.1.1         178         0x80000076 0x0021a5

10.10.11.0      1.1.1.1         178         0x80000077 0x0014b0

172.16.10.4     1.1.1.1         173         0x80000078 0x00d00b

10.10.40.0      1.1.1.1         1164        0x80000074 0x005c0e

10.10.50.0      1.1.1.1         1164        0x80000075 0x00eb73

 

                Router Link States (Area 2)

 

Link ID         ADV Router      Age         Seq#       Checksum Link count

1.1.1.1         1.1.1.1         1119        0x8000002b 0x005cd6 2

172.16.10.6     172.16.10.6     1119        0x8000002d 0x0020a3 4

 

                Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum

10.10.10.0      1.1.1.1         179         0x8000007a 0x0019a9

10.10.11.0      1.1.1.1         179         0x8000007b 0x000cb4

172.16.10.0     1.1.1.1         179         0x8000007c 0x00f0ea

10.10.20.0      1.1.1.1         1104        0x80000078 0x003149

10.10.30.0      1.1.1.1         1104        0x80000079 0x00c0ae

Corp#

Considering we only have eight networks configured in our internetwork, there's a huge amount of information in this database! You can see all the routers and the RID of each—the highest IP address related to individual routers. And each output under each area represents LSA Type 1, indicating the area they're connected to.

The router output also shows the link ID. Remember that an interface is also a link, as is the RID of the router on that link under the ADV router—the advertising router.

So far, this has been a great section, brimming with detailed OSPF information, a whole lot more than what was needed to meet past Cisco objectives, for sure!

Exam Essentials

Know how OSPF routers become neighbors and/or adjacent. OSPF routers become neighbors when each router sees the other's Hello packets.

Be able to configure single-area OSPF. A minimal single-area configuration involves only two commands: router ospf process-id and network x.x.x.x y.y.y.y area Z.

Be able to verify the operation of OSPF. There are many show commands that provide useful details on OSPF, and it is useful to be completely familiar with the output of each: show ip ospf, show ip ospf database, show ip ospf interface, show ip ospf neighbor, and show ip protocols.

Be able to monitor multi-area OSPF. There are a number of commands that provide information useful in a multi-area OSPF environment: show ip route ospf, show ip ospf neighbor, show ip ospf, and show ip ospf database. It's important to understand what each provides.

Configure, verify, and troubleshoot single area and multi-area OSPFv3 for IPv6 (excluding authentication, filtering, manual summarization, redistribution, stub, virtual-link, and LSAs)

The new version of OSPF continues the trend of routing protocols having a lot in common with their IPv4 versions. The foundation of OSPF remains the same—it's still a link-state routing protocol that divides an entire internetwork or autonomous system into areas, establishing a hierarchy.

In OSPF version 2, the router ID (RID) is determined by the highest IP addresses assigned to the router. And as you now know, the RID can be assigned. In version 3, nothing has really changed because you can still assign the RID, area ID, and link-state ID, which remain 32-bit values.

Adjacencies and next-hop attributes now use link-local addresses, but OSPFv3 still uses multicast traffic to send its updates and acknowledgments. It uses the addresses FF02::5 for OSPF routers and FF02::6 for OSPF-designated routers. These new addresses are the replacements for 224.0.0.5 and 224.0.0.6, respectively.

Other, less flexible IPv4 protocols don't give us the ability that OSPFv2 does to assign specific networks and interfaces into the OSPF process, but this is still configured under the router configuration process. And with OSPFv3, the interfaces and therefore the networks attached to them are configured directly on the interface in interface configuration mode.

The configuration of OSPFv3 is going to look like this: First, optionally start by assigning the RID, but if you have IPv4 addresses assigned to your interface, you can let OSPF pick the RID just as we did with OSPFv2:

Router(config)#ipv6 router ospf 10

Router(config-rtr)#router-id 1.1.1.1

You get to perform some other configurations from router configuration mode, like summarization and redistribution, but again, we don't even need to configure OSPFv3 from this prompt if we configure it from the interface!

A simple interface configuration looks like this:

Router(config-if)#ipv6 ospf 10 area 0.0.0.0

So, if we just go to each interface and assign a process ID and area—poof, we're done! See? Easy! As the configuration shows, I configured the area as 0.0.0.0, which is the same thing as just typing area 0. We'll use Figure 3.19.

Okay, so all we have to do to enable OSPF on the internetwork is go to each interface that we want to run it on. Here's the Corp configuration:

Corp#config t

Corp(config)#int g0/0

Corp(config-if)#ipv6 ospf 1 area 0

Corp(config-if)#int g0/1

Corp(config-if)#ipv6 ospf 1 area 0

Corp(config-if)#int s0/0/0

Corp(config-if)#ipv6 ospf 1 area 0

Corp(config-if)#int s0/0/1

Corp(config-if)#ipv6 ospf 1 area 0

That wasn't so bad—much easier than it was with IPv4! To configure OSPFv3, you just need to establish the specific interfaces you'll be using! Let's configure the other two routers now:

SF#config t

SF(config)#int g0/0

SF(config-if)#ipv6 ospf 1 area 1

SF(config-if)#int g0/1

SF(config-if)#ipv6 ospf 1 area 1

SF(config-if)#int s0/0/0

SF(config-if)#ipv6 ospf 1 area 0

01:03:55: %OSPFv3-5-ADJCHG: Process 1, Nbr 192.168.1.5 on Serial0/0/0

from LOADING to  FULL, Loading Done

Sweet—the SF has become adjacent to the Corp router! One interesting output line I want to point out is that the IPv4 RID is being used in the OSPFv3 adjacent change. I didn't set the RIDs manually because I knew I had interfaces with IPv4 addresses already on them, which the OSPF process would use for a RID.

Now let's configure the NY router:

NY(config)#int g0/0

NY(config-if)#ipv6 ospf 1 area 2

%OSPFv3-4-NORTRID:OSPFv3 process 1 could not pick a router-id,please configure manually

NY(config-if)#ipv6 router ospf 1

NY(config-rtr)#router-id 1.1.1.1

NY(config-if)#int g0/0

NY(config-if)#ipv6 ospf 1 area 2

NY(config-if)#int g0/1

NY(config-if)#ipv6 ospf 1 area 2

NY(config-if)#int s0/0/0

NY(config-if)#ipv6 ospf 1 area 0

00:09:00: %OSPFv3-5-ADJCHG: Process 1, Nbr 192.168.1.5 on Serial0/0/0 from LOADING to

FULL, Loading Done

Our adjacency popped up—this is great. But did you notice that I had to set the RID? That's because there wasn't an IPv4 32-bit address already on an interface for the router to use as the RID, so it was mandatory to set the RID manually!

Without even verifying our network, it appears it's up and running. Even so, it's always important to verify!

Verifying OSPFv3

I'll start as usual with the show ipv6 route ospf command:

Corp#sh ipv6 route ospf

OI  2001:DB8:3C4D:15::/64 [110/65]

     via FE80::201:C9FF:FED2:5E01, Serial0/0/1

OI  2001:DB8:3C4D:16::/64 [110/65]

     via FE80::201:C9FF:FED2:5E01, Serial0/0/1

O   2001:DB8:C34D:11::/64 [110/128]

     via FE80::2E0:F7FF:FE13:5E01, Serial0/0/0

OI  2001:DB8:C34D:17::/64 [110/65]

     via FE80::2E0:F7FF:FE13:5E01, Serial0/0/0

OI  2001:DB8:C34D:18::/64 [110/65]

     via FE80::2E0:F7FF:FE13:5E01, Serial0/0/0

Corp#

Perfect. I see all six subnets. Notice the O and OI? The O is intra-area and the OI is inter-area, meaning it's a route from a different area. You can't simply distinguish the area by looking at the routing table though. Plus, don't forget that the routers communicate with their neighbor via link-local addresses: via FE80::2E0:F7FF:FE13:5E01, Serial0/0/0, for example.

Let's take a look at the show ipv6 protocols command:

Corp#sh ipv6 protocols

IPv6 Routing Protocol is "connected"

IPv6 Routing Protocol is "static

IPv6 Routing Protocol is "ospf 1"

  Interfaces (Area 0)

    GigabitEthernet0/0

    GigabitEthernet0/1

    Serial0/0/0

    Serial0/0/1

This just tells us which interfaces are part of OSPF process 1, area 0. To configure OSPFv3, you absolutely have to know which interfaces are in use. Sho ip int brief can really help you if you're having a problem finding your active interfaces.

Let's take a look at the Gigabit Ethernet OSPFv3 active interface on the Corp router:

Corp#sh ipv6 ospf int g0/0

GigabitEthernet0/0 is up, line protocol is up

  Link Local Address FE80::2E0:F7FF:FE0A:3301 , Interface ID 1

  Area 0, Process ID 1, Instance ID 0, Router ID 192.168.1.5

  Network Type BROADCAST, Cost: 1

  Transmit Delay is 1 sec, State DR, Priority 1

  Designated Router (ID) 192.168.1.5, local address FE80::2E0:F7FF:FE0A:3301

  No backup designated router on this network

  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

    Hello due in 00:00:09

  Index 1/1, flood queue length 0

  Next 0x0(0)/0x0(0)

  Last flood scan length is 1, maximum is 1

  Last flood scan time is 0 msec, maximum is 0 msec

  Neighbor Count is 0, Adjacent neighbor count is 0

  Suppress hello for 0 neighbor(s)

Let's take a look at the neighbor table on the Corp router via show ipv6 ospf neighbor:

Corp#sh ipv6 ospf neighbor

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface

2.2.2.2           0   FULL/  -        00:00:36    4               Serial0/0/1

192.168.1.6       0   FULL/  -        00:00:39    4               Serial0/0/0

Okay, we can see our two neighbors, and there's also a slight difference in this version's command from OSPFv2. We still see the RID on the left and that we're also fully adjacent with both our neighbors—the dash is there because there are no elections on serial point-to-point links. But we don't see the neighbor's IPv6 address listed as we did with OSPFv2's IPv4 addresses, which were listed in the interface ID field.

There's one other command I want to finish with—the show ipv6 ospf command:

Corp#sh ipv6 ospf

 Routing Process "ospfv3 1" with ID 192.168.1.5

 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 4

        SPF algorithm executed 10 times

        Number of LSA 10. Checksum Sum 0x05aebb

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

This shows the process ID and RID, our reference bandwidth for this interface, and how many interfaces we have in each area, which in our example is only area 0.

Exam Essentials

Understand how to configure OSPFv3. OSPFv3 uses the same basic mechanisms that OSPFv2 uses, but OSPFv3 is more easily configured by OSPFv3 on a per-interface basis with ipv6 ospf process-ID area area.

Configure, verify, and troubleshoot EIGRP for IPv4 (excluding authentication, filtering, manual summarization, redistribution, stub)

We're going to start with the easy part of EIGRP, and by configuring it on our little internetwork, you'll learn a lot more this way than you would if I just continued explaining more at this point. After we've completed the initial configuration, we'll fine-tune it and have fun experimenting with it throughout the rest of this chapter!

Okay, there are two modes for entering EIGRP commands: router configuration mode and interface configuration mode. In router configuration mode, we'll enable the protocol, determine which networks will run EIGRP, and set global factors. When in interface configuration mode, we'll customize summaries and bandwidth.

To initiate an EIGRP session on a router, I'll use the router eigrp command followed by our network's AS number. After that, we'll enter the specific numbers of the networks that we want to connect to the router using the network command followed by the network number. This is pretty straightforward stuff—if you can configure RIP, then you can configure EIGRP!

I'm going to enable EIGRP for autonomous system 20 on our Corp router connected to four networks. Figure 3.20 shows the network we'll be configuring. Here's the Corp configuration:

Corp#config t

Corp(config)#router eigrp 20

Corp(config-router)#network 172.16.0.0

Corp(config-router)#network 10.0.0.0

Remember, we need to use the classful network address, which is all subnet and host bits turned off. This is another thing that makes EIGRP so great: It has the complexity of a link-state protocol running in the background and the same easy configuration process used for RIP!

But wait, the EIGRP configuration can't be that easy, can it? A few simple EIGRP commands and my network just works? Well, it can be and usually is, but not always. Remember the wildcards you learned about in the section on OSPF? Let's say, for example, that we wanted to advertise all the directly connected networks with EIGRP off the Corp router. By using the command network 10.0.0.0, we can effectively advertise to all subnets within that classful network; however, take a look at this configuration now:

Corp#config t

Corp(config)#router eigrp 20

Corp(config-router)#network 10.10.11.0 0.0.0.255

Corp(config-router)#network 172.16.10.0 0.0.0.3

Corp(config-router)#network 172.16.10.4 0.0.0.3

This configuration should look pretty familiar to you because by now you should have a solid understanding of how wildcards are configured. This configuration will advertise the network connected to g0/1 on the Corp router as well as the two WAN links. Still, all we accomplished with this configuration was to stop the g0/0 interface from being placed into the EIGRP process, and unless you have tens of thousands of networks worldwide, then there is really no need to use wildcards because they don't provide any other administrative purpose other than what I've already described.

Now let's take a look at the simple configuration needed for the SF and NY routers in our internetwork:

SF(config)#router eigrp 20

SF(config-router)#network 172.16.0.0

SF(config-router)#network 10.0.0.0

000060:%DUAL-5-NBRCHANGE:IP-EIGRP(0) 20:Neighbor 172.16.10.1 (Serial0/0/0) is up:

new adjacency

 

NY(config)#router eigrp 20

NY(config-router)#network 172.16.0.0

NY(config-router)#network 10.0.0.0

*Jun 26 02:41:36:%DUAL-5-NBRCHANGE:IP-EIGRP(0) 20:Neighbor 172.16.10.5 (Serial0/0/1) is up: new adjacency

Nice and easy—or is it? We can see that the SF and NY router created an adjacency to the Corp router, but are they actually sharing routing information? To find out, let's take a look at the number that I pointed out as the autonomous system (AS) number in the configuration.

EIGRP uses ASs to identify the group of routers that will share route information. Only routers that have the same AS share routes. The range of values we can use to create an AS with EIGRP is 1–65535:

Corp(config)#router eigrp ?

  <1-65535>  Autonomous System

  WORD       EIGRP Virtual-Instance Name

Corp(config)#router eigrp 20

Notice that I could have used any number from 1 to 65,535, but I chose to use 20 because it just felt good at the time. As long as all routers use the same number, they'll create an adjacency. Okay, now the AS makes sense, but it looks like I can type a word in the place of the AS number, and I can! Let's take a look at the configuration:

Corp(config)#router eigrp Todd

Corp(config-router)#address-family ipv4 autonomous-system 20

Corp(config-router-af)#network 10.0.0.0

Corp(config-router-af)#network 172.16.0.0

Verifying and Troubleshooting EIGRP

Even though EIGRP usually runs smoothly and is relatively low maintenance, there are several commands you need to memorize for using on a router that can be super helpful when troubleshooting EIGRP! I've already shown you a few of them, but I'm going to demonstrate all the tools you'll need to verify and troubleshoot EIGRP now. Table 3.3 contains all of the commands you need to know for verifying that EIGRP is functioning well and offers a brief description of what each command does.

Table 3.3 EIGRP troubleshooting commands

When troubleshooting an EIGRP problem, it's always a good idea to start by getting an accurate map of the network, and the best way to do that is by using the show ip eigrp neighbors command to find out who your directly connected neighbors are. This command shows all adjacent routers that share route information within a given AS. If neighbors are missing, check the configuration, AS number, and link status on both routers to verify that the protocol has been configured correctly.

Let's execute the command on the Corp router:

Corp#sh ip eigrp neighbors

IP-EIGRP neighbors for process 20

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

1   172.16.10.2             Se0/0             11 03:54:25    1   200  0  127

0   172.16.10.6             Se0/1             11 04:14:47    1   200  0  2010

Here's a breakdown of the important information we can see in the preceding output:

• H indicates the order in which the neighbor was discovered.
• Hold time in seconds is how long this router will wait for a Hello packet to arrive from a specific neighbor.
• The Uptime value indicates how long the neighbor relationship has been established.
• The SRTT field is the smooth round-trip timer and represents how long it takes to complete a round-trip from this router to its neighbor and back. This value delimits how long to wait after a multicast for a reply from this neighbor. As mentioned earlier, the router will attempt to establish communication via unicasts if it doesn't receive a reply.
• The time between multicast attempts is specified by the Retransmission Time Out (RTO) field, which is based upon the SRTT values.
• The Q value tells us if there are any outstanding messages in the queue. We can make a mental note that there's a problem if we see consistently large values here!
• Finally, the Seq field shows the sequence number of the last update from that neighbor, which is used to maintain synchronization and avoid duplicate messages or their out-of-sequence processing.

The neighbors command is a great command, but we can get the local status of our router by also using the show ip eigrp interfaces command like this:

Corp#sh ip eigrp interfaces

IP-EIGRP interfaces for process 20

 

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending

Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes

Gi0/0              0        0/0         0       0/1            0           0

Se0/1              1        0/0         1       0/15          50           0

Se0/0              1        0/0         1       0/15          50           0

Gi0/1              0        0/0         0       0/1            0           0

 

Corp#sh ip eigrp interface detail s0/0

IP-EIGRP interfaces for process 20

 

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending

Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes

Se0/0              1        0/0         1       0/15          50           0

  Hello interval is 5 sec

  Next xmit serial <none>

  Un/reliable mcasts: 0/0  Un/reliable ucasts: 21/26

  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 9

  Retransmissions sent: 0  Out-of-sequence rcvd: 0

  Authentication mode is not set

The first command, show ip eigrp interfaces, lists all interfaces for which EIGRP is enabled as well as those the router is currently sending Hello messages to in an attempt to find new EIGRP neighbors. The show ip eigrp interface detail interface command lists more details per interface, including the local router's own Hello interval. Understand that you can use these commands to verify that all your interfaces are within the AS process used by EIGRP, but also note that the passive interfaces won't show up in these outputs. So be sure to also check to see if an interface has been configured as passive if is not present in the outputs.

Okay, if all neighbors are present, then verify the routes learned. By executing the show ip route eigrp command, you're given a quick picture of the routes in the routing table. If a certain route doesn't appear in the routing table, you need to verify its source. If the source is functioning properly, then check the topology table.

The routing table according to Corp looks like this:

Corp#sh ip ip eigrp topology

D    192.168.10.0/24 [90/2172416] via 172.16.10.6, 02:29:09, Serial0/1

                     [90/2172416] via 172.16.10.2, 02:29:09, Serial0/0

     172.16.0.0/30 is subnetted, 2 subnets

C       172.16.10.4 is directly connected, Serial0/1

C       172.16.10.0 is directly connected, Serial0/0

     10.0.0.0/24 is subnetted, 6 subnets

C       10.10.10.0 is directly connected, Loopback0

C       10.10.11.0 is directly connected, Loopback1

D       10.10.20.0 [90/2300416] via 172.16.10.6, 02:29:09, Serial0/1

                   [90/2297856] via 172.16.10.2, 02:29:10, Serial0/0

D       10.10.30.0 [90/2300416] via 172.16.10.6, 02:29:10, Serial0/1

                   [90/2297856] via 172.16.10.2, 02:29:10, Serial0/0

D       10.10.40.0 [90/2297856] via 172.16.10.6, 02:29:10, Serial0/1

                   [90/2300416] via 172.16.10.2, 02:29:10, Serial0/0

D       10.10.50.0 [90/2297856] via 172.16.10.6, 02:29:11, Serial0/1

                   [90/2300416] via 172.16.10.2, 02:29:11, Serial0/0

You can see here that most EIGRP routes are referenced with a D and that their administrative distance is 90. Remember that the [90/2300416] represents AD/FD, and in the preceding output, EIGRP is performing equal- and unequal-cost load balancing between two links to our remote networks.

We can see this by looking closer at two different networks. Pay special attention to the FD of each output:

Corp#sh ip route | section 192.168.10.0

D    192.168.10.0/24 [90/2172416] via 172.16.10.6, 01:15:44, Serial0/1

                     [90/2172416] via 172.16.10.2, 01:15:44, Serial0/0

The preceding output shows equal-cost load balancing, and here's our unequal-cost load balancing in action:

Corp#sh ip route | section 10.10.50.0

D       10.10.50.0 [90/2297856] via 172.16.10.6, 01:16:16, Serial0/1

                   [90/2300416] via 172.16.10.2, 01:16:16, Serial0/0

We can get the topology table displayed for us via the show ip eigrp topology command. If the route is in the topology table but not in the routing table, it's a pretty safe assumption that there's a problem between the topology database and the routing table. After all, there must be a good reason the topology database isn't adding the route into the routing table, right? We discussed this issue in detail earlier in the chapter, and it's oh so important!

Corp's topology table looks like this:

Corp#sh ip ip eigrp topology

P 10.10.10.0/24, 1 successors, FD is 128256

        via Connected, GigabitEthernet0/0

P 10.10.11.0/24, 1 successors, FD is 128256

        via Connected, GigabitEthernet0/1

P 10.10.20.0/24, 1 successors, FD is 2297856

        via 172.16.10.2 (2297856/128256), Serial0/0

        via 172.16.10.6 (2300416/156160), Serial0/1

P 10.10.30.0/24, 1 successors, FD is 2297856

        via 172.16.10.2 (2297856/128256), Serial0/0

        via 172.16.10.6 (2300416/156160), Serial0/1

P 10.10.40.0/24, 1 successors, FD is 2297856

        via 172.16.10.6 (2297856/128256), Serial0/1

        via 172.16.10.2 (2300416/156160), Serial0/0

P 10.10.50.0/24, 1 successors, FD is 2297856

        via 172.16.10.6 (2297856/128256), Serial0/1

        via 172.16.10.2 (2300416/156160), Serial0/0

P 192.168.10.0/24, 2 successors, FD is 2172416

        via 172.16.10.2 (2172416/28160), Serial0/0

        via 172.16.10.6 (2172416/28160), Serial0/1

P 172.16.10.4/30, 1 successors, FD is 2169856

        via Connected, Serial0/1

P 172.16.10.0/30, 1 successors, FD is 2169856

        via Connected, Serial0/0

Notice that every route in this output is preceded by a P, which shows that these routes are in a passive state. This is good because routes in the active state indicate that the router has lost its path to this network and is searching for a replacement. Each entry also reveals the feasible distance, or FD, to each remote network as well as the next-hop neighbor through which packets will travel to this destination. Each entry also has two numbers in brackets, with the first indicating the feasible distance and the second, the advertised distance to a remote network.

Again, here's our equal- and unequal-cost load-balancing output shown in the topology table:

Corp#sh ip eigrp top | section 192.168.10.0

P 192.168.10.0/24, 2 successors, FD is 2172416

        via 172.16.10.2 (2172416/28160), Serial0/0

        via 172.16.10.6 (2172416/28160), Serial0/1

The preceding output shows equal-cost load balancing, and here is our unequal-cost load balancing in action:

Corp#sh ip eigrp top | section 10.10.50.0

P 10.10.50.0/24, 1 successors, FD is 2297856

        via 172.16.10.6 (2297856/128256), Serial0/1

        via 172.16.10.2 (2300416/156160), Serial0/0

The command show ip eigrp traffic enables us to see if updates are being sent. If the counters for EIGRP input and output packets don't increase, it means that no EIGRP information is being sent between peers. The following output indicates that the Corp router is experiencing normal traffic:

Corp#show ip eigrp traffic

IP-EIGRP Traffic Statistics for process 200

  Hellos sent/received: 2208/2310

  Updates sent/received: 184/183

  Queries sent/received: 17/4

  Replies sent/received: 4/18

  Acks sent/received: 62/65

  Input queue high water mark 2, 0 drops

All EIGRP packet types are represented in the output of this command. And we can't forget the always useful troubleshooting command show ip protocols. Here's the output the Corp router gives us after using it:

Routing Protocol is "eigrp 20"

  Outgoing update filter list for all interfaces is not set

  Incoming update filter list for all interfaces is not set

  Default networks flagged in outgoing updates

  Default networks accepted from incoming updates

  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

  EIGRP maximum hopcount 100

  EIGRP maximum metric variance 2

  Redistributing: eigrp 20

  EIGRP NSF-aware route hold timer is 240s

  Automatic network summarization is not in effect

  Maximum path: 4

  Routing for Networks:

    10.0.0.0

    172.16.0.0

  Routing Information Sources:

    Gateway         Distance      Last Update

    (this router)         90      04:23:51

    172.16.10.6           90      02:30:48

    172.16.10.2           90      02:30:48

  Distance: internal 90 external 170

In this output, we can see that EIGRP is enabled for autonomous system 20 and that the K values are set to their defaults. The variance is 2, so both equal- and unequal-cost load balancing is happening here. Automatic summarization has been turned off. We can also see that EIGRP is advertising two classful networks and that it sees two neighbors.

The show ip eigrp events command displays a log of every EIGRP event: when routes are injected and removed from the routing table and when EIGRP adjacencies are reset or fail. This information is so helpful in determining if there are routing instabilities in the network! Be advised that this command can result in quite a flood of information even for really simple configurations like ours. To demonstrate, here's the output the Corp router divulged after I used it:

Corp#show ip eigrp events

Event information for AS 20:

1    22:24:24.258 Metric set: 172.16.10.0/30 2169856

2    22:24:24.258 FC sat rdbmet/succmet: 2169856 0

3    22:24:24.258 FC sat nh/ndbmet: 0.0.0.0 2169856

4    22:24:24.258 Find FS: 172.16.10.0/30 2169856

5    22:24:24.258 Metric set: 172.16.10.4/30 2169856

6    22:24:24.258 FC sat rdbmet/succmet: 2169856 0

7    22:24:24.258 FC sat nh/ndbmet: 0.0.0.0 2169856

8    22:24:24.258 Find FS: 172.16.10.4/30 2169856

9    22:24:24.258 Metric set: 192.168.10.0/24 2172416

10   22:24:24.258 Route install: 192.168.10.0/24 172.16.10.2

11   22:24:24.258 Route install: 192.168.10.0/24 172.16.10.6

12   22:24:24.254 FC sat rdbmet/succmet: 2172416 28160

13   22:24:24.254 FC sat nh/ndbmet: 172.16.10.6 2172416

14   22:24:24.254 Find FS: 192.168.10.0/24 2172416

15   22:24:24.254 Metric set: 10.10.50.0/24 2297856

16   22:24:24.254 Route install: 10.10.50.0/24 172.16.10.6

17   22:24:24.254 FC sat rdbmet/succmet: 2297856 128256

18   22:24:24.254 FC sat nh/ndbmet: 172.16.10.6 2297856

19   22:24:24.254 Find FS: 10.10.50.0/24 2297856

20   22:24:24.254 Metric set: 10.10.40.0/24 2297856

21   22:24:24.254 Route install: 10.10.40.0/24 172.16.10.6

22   22:24:24.250 FC sat rdbmet/succmet: 2297856 128256

 ––More––

Exam Essentials

Know how to configure EIGRP. Be able to configure basic EIGRP. This is configured the same as RIP with classful addresses.

Know how to verify EIGRP operation. Know all of the EIGRP show commands and be familiar with their output and the interpretation of the main components of their output.

Be able to read an EIGRP topology table. Understand which are successors, which are feasible successors, and which routes will become successors if the main successor fails.

You must be able to troubleshoot EIGRP. Go through the EIGRP troubleshooting scenario and make sure you understand to look for the AS number, ACLs, passive interfaces, variance, and other factors.

Configure, verify, and troubleshoot EIGRP for IPv6 (excluding authentication, filtering, manual summarization, redistribution, stub)

EIGRPv6 works much the same way as its IPv4 predecessor does—most of the features that EIGRP provided before EIGRPv6 will still be available.

EIGRPv6 is still an advanced distance-vector protocol that has some link-state features. The neighbor discovery process using Hellos still happens, and it still provides reliable communication with Reliable Transport Protocol that gives us loop-free fast convergence using the Diffusing Update Algorithm (DUAL).

Hello packets and updates are sent using multicast transmission, and as with RIPng, EIGRPv6's multicast address stayed almost the same. In IPv4 it was 224.0.0.10; in IPv6, it's FF02::A (A = 10 in hexadecimal notation).

But clearly, there are key differences between the two versions. Most notably the use of the pesky network command is gone, so it's hard to make a mistake with EIGRPv6. Also, the network and interface to be advertised must be enabled from interface configuration mode with one simple command.

But you still have to use the router configuration mode to enable the routing protocol in EIGRPv6 because the routing process must be literally enabled like an interface with the no shutdown command—interesting! However, the 15.0 code does enable this by default, so this command actually may or may not be needed.

Here's an example of enabling EIGRPv6 on the Corp router:

Corp(config)#ipv6 unicast-routing

Corp(config)#ipv6 router eigrp 10

The 10 in this case is still the AS number. The prompt changes to (config-rtr), and from here, just initiate a no shutdown if needed:

Corp(config-rtr)#no shutdown

Other options also can be configured in this mode, like redistribution and router ID (RID). So now, let's go to the interface and enable IPv6:

Corp(config-if)#ipv6 eigrp 10

The 10 in the interface command again references the AS number that was enabled in the configuration mode.

Figure 3.21 shows the layout we've been using throughout this chapter, only with IPv6 addresses now assigned to interfaces. I used the EUI-64 option on each interface so each router assigned itself an IPv6 address after I typed in the 64-bit network/subnet address.

We'll start with the Corp router. Really, all we need to know in order to enable EIGRPv6 are which interfaces we're using and want to advertise our networks.

Corp#config t

Corp(config)#ipv6 router eigrp 10

Corp(config-rtr)#no shut

Corp(config-rtr)#router-id 1.1.1.1

Corp(config-rtr)#int s0/0/0

Corp(config-if)#ipv6 eigrp 10

Corp(config-if)#int s0/0/1

Corp(config-if)#ipv6 eigrp 10

Corp(config-if)#int g0/0

Corp(config-if)#ipv6 eigrp 10

Corp(config-if)#int g0/1

Corp(config-if)#ipv6 eigrp 10

I had erased and reloaded the routers before I started this EIGRPv6 section of the chapter. What this means is that there were no 32-bit addresses on the router in order to create the RID for EIGRP, so I had to set it under the IPv6 router global command, which is the same command used with EIGRP and EIGRPv6. Unlike with OSPF, the RID isn't that important, and it can actually be the same address on every router. You just can't get away with doing this with OSPF! The configuration for EIGRPv6 was pretty straightforward because unless you type the AS number wrong, it's pretty hard to screw this up!

Okay, let's configure the SF and NY routers now, and then we'll verify our networks:

SF#config t

SF(config)#ipv6 router eigrp 10

SF(config-rtr)#no shut

SF(config-rtr)#router-id 2.2.2.2

SF(config-rtr)#int s0/0/0

SF(config-if)#ipv6 eigrp 10

SF(config-if)#int g0/0

SF(config-if)#ipv6 eigrp 10

SF(config-if)#int g0/1

SF(config-if)#ipv6 eigrp 10

 

NY#config t

NY(config)#ipv6 router eigrp 10

NY(config-rtr)#no shut

NY(config-rtr)#router-id 3.3.3.3

NY(config-rtr)#int s0/0/0

NY(config-if)#ipv6 eigrp 10

NY(config-if)#int g0/0

NY(config-if)#ipv6 eigrp 10

NY(config-if)#int g0/1

Since we configured EIGRPv6 on a per-interface basis, no worries about having to use the passive-interface command. This is because if we don't enable the routing protocol on an interface, it's just not part of the EIGRPv6 process. We can see which interfaces are part of the EIGRPv6 process with the show ipv6 eigrp interfaces command like this:

Corp#sh ipv6 eigrp interfaces

IPv6-EIGRP interfaces for process 10

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending

Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes

Se0/0/0            1        0/0      1236       0/10           0           0

Se0/0/1            1        0/0      1236       0/10           0           0

Gig0/1             0        0/0      1236       0/10           0           0

Gig0/0             0        0/0      1236       0/10           0           0

Corp#

Looks great so far—all the interfaces we want in our AS are listed, so we're looking good for our Corp's local configuration. Now it's time to check if our adjacencies came up with the show ipv6 eigrp neighbors command:

Corp#sh ipv6 eigrp neighbors

IPv6-EIGRP neighbors for process 10

H   Address                 Interface     Hold   Uptime   SRTT   RTO  Q  Seq

                                          (sec)           (ms)       Cnt Num

0   Link-local address:       Se0/0/0      10   00:01:40  40     1000  0   11

    FE80::201:C9FF:FED0:3301

1   Link-local address:       Se0/0/1      14   00:01:24  40     1000  0   11

    FE80::209:7CFF:FE51:B401

It's great that we can see neighbors listed off of each serial interface, but do you notice something missing from the preceding output? That's right, the actual IPv6 network/subnet addresses of the links aren't listed in the neighbor table! Only the link-local addresses are used for forming EIGRP neighbor adjacencies. With IPv6, neighbor interfaces and next-hop addresses are always link-local.

We can verify our configuration with the show ip protocols command:

Corp#sh ipv6 protocols

IPv6 Routing Protocol is "connected"

IPv6 Routing Protocol is "static

IPv6 Routing Protocol is "eigrp  10 "

  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

  EIGRP maximum hopcount 100

  EIGRP maximum metric variance 1

  Interfaces:

    Serial0/0/0

    Serial0/0/1

    GigabitEthernet0/0

    GigabitEthernet0/1

Redistributing: eigrp 10

  Maximum path: 16

  Distance: internal 90 external 170

You can verify the AS number from this output, but be sure to verify your K values, variance, and interfaces too. Remember that the AS number and interfaces are the first factors to check when troubleshooting.

The topology table lists all feasible routes in the network, so this output can be rather long, but let's see what this shows us:

Corp#sh ipv6 eigrp topology

IPv6-EIGRP Topology Table for AS 10/ID(1.1.1.1)

 

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

       r - Reply status

 

P 2001:DB8:C34D:11::/64, 1 successors, FD is 2169856

         via Connected, Serial0/0/0

P 2001:DB8:C34D:12::/64, 1 successors, FD is 2169856

         via Connected, Serial0/0/1

P 2001:DB8:C34D:14::/64, 1 successors, FD is 2816

         via Connected, GigabitEthernet0/1

P 2001:DB8:C34D:13::/64, 1 successors, FD is 2816

         via Connected, GigabitEthernet0/0

P 2001:DB8:C34D:17::/64, 1 successors, FD is 2170112

         via FE80::201:C9FF:FED0:3301 (2170112/2816), Serial0/0/0

P 2001:DB8:C34D:18::/64, 1 successors, FD is 2170112

         via FE80::201:C9FF:FED0:3301 (2170112/2816), Serial0/0/0

P 2001:DB8:C34D:15::/64, 1 successors, FD is 2170112

         via FE80::209:7CFF:FE51:B401 (2170112/2816), Serial0/0/1

P 2001:DB8:C34D:16::/64, 1 successors, FD is 2170112

         via FE80::209:7CFF:FE51:B401 (2170112/2816), Serial0/0/1

Since we only have eight networks in our internetwork, we can see all eight networks in the topology table, which clearly is as it should be. I've highlighted a couple of things I want to discuss, and the first is that you need to be able to read and understand a topology table. This includes understanding which routes are directly connected and which are being advertised via neighbors. The via Connected shows us our directly connected networks. The second item I want to show you is (2170112/2816), which is the FD/AD, and by the way, it's no different than if you're working with IPv4.

So let's wrap this up by taking a look at a routing table:

Corp#sh ipv6 route eigrp

IPv6 Routing Table - 13 entries

Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP

       U - Per-user Static route, M - MIPv6

       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

       D - EIGRP, EX - EIGRP external

C   2001:DB8:C34D:11::/64 [0/0]

     via ::, Serial0/0/0

L   2001:DB8:C34D:11:230:A3FF:FE36:B101/128 [0/0]

     via ::, Serial0/0/0

C   2001:DB8:C34D:12::/64 [0/0]

     via ::, Serial0/0/1

L   2001:DB8:C34D:12:230:A3FF:FE36:B102/128 [0/0]

     via ::, Serial0/0/1

C   2001:DB8:C34D:13::/64 [0/0]

     via ::, GigabitEthernet0/0

L   2001:DB8:C34D:13:2E0:F7FF:FEDA:7501/128 [0/0]

     via ::, GigabitEthernet0/0

C   2001:DB8:C34D:14::/64 [0/0]

     via ::, GigabitEthernet0/1

L   2001:DB8:C34D:14:2E0:F7FF:FEDA:7502/128 [0/0]

     via ::, GigabitEthernet0/1

D   2001:DB8:C34D:15::/64 [90/2170112]

     via FE80::209:7CFF:FE51:B401, Serial0/0/1

D   2001:DB8:C34D:16::/64 [90/2170112]

     via FE80::209:7CFF:FE51:B401, Serial0/0/1

D   2001:DB8:C34D:17::/64 [90/2170112]

     via FE80::201:C9FF:FED0:3301, Serial0/0/0

D   2001:DB8:C34D:18::/64 [90/2170112]

     via FE80::201:C9FF:FED0:3301, Serial0/0/0

L   FF00::/8 [0/0]

     via ::, Null0

I highlighted the EIGRPv6 injected routes that were injected into the routing table. It's important to notice that in order for IPv6 to get to a remote network, the router uses the next-hop link-local address. Do you see that in the table? For example, via FE80::209:7CFF:FE51:B401, Serial0/0/1 is the link-local address of the NY router.

Exam Essentials

Understand how to configure EIGRPv6. To configure EIGRPv6, first create the autonomous system from global configuration mode and perform a no shutdown. Then enable EIGRPv6 on each interface individually.

Configure, verify, and troubleshoot RIPv2 for IPv4 (excluding authentication, filtering, manual summarization, redistribution)

To configure RIP routing, just turn on the protocol with the router rip command and tell the RIP routing protocol the networks to advertise. Remember that with static routing, we always configured remote networks and never typed a route to our directly connected networks? Well, dynamic routing is carried out the complete opposite way. You would never type a remote network under your routing protocol—only enter your directly connected networks!

Configuring RIPv2

Let's configure a three-router internetwork, shown in Figure 3.22, with RIP routing.

Corp

RIP has an administrative distance of 120. Static routes have an administrative distance of 1 by default, and since we currently have static routes configured, the routing tables won't be populated with RIP information. We're still good though because I added the 150 to the end of each static route!

You can add the RIP routing protocol by using the router rip command and the network command. The network command tells the routing protocol which classful network to advertise. By doing this, you're activating the RIP routing process on the interfaces whose addressing falls within the specified classful networks configured with the network command under the RIP routing process.

Look at the Corp router configuration to see how easy this is. Oh wait—first, I want to verify my directly connected networks so I know what to configure RIP with:

Corp#sh ip int brief

Interface        IP-Address      OK? Method Status                Protocol

FastEthernet0/0  10.10.10.1      YES manual up                    up

Serial0/0        172.16.10.1     YES manual up                    up

FastEthernet0/1  unassigned      YES unset  administratively down down

Serial0/1        172.16.10.5     YES manual up                    up

Corp#config t

Corp(config)#router rip

Corp(config-router)#network 10.0.0.0

Corp(config-router)#network 172.16.0.0

Corp(config-router)#version 2

Corp(config-router)#no auto-summary

That's it—really! Typically just two or three commands and you're done, which sure makes your job a lot easier than dealing with static routes, doesn't it? Be sure to keep in mind the extra router CPU process and bandwidth that you're consuming.

Anyway, so what exactly did I do here? I enabled the RIP routing protocol, added my directly connected networks, made sure I was only running RIPv2, which is a classless routing protocol, and then I disabled auto-summary. We typically don't want our routing protocols summarizing for us because it's better to do that manually and both RIP and EIGRP (before 15.x code) auto-summarize by default. So a general rule of thumb is to disable auto-summary, which allows them to advertise subnets.

Notice I didn't type in subnets, only the classful network address, which is betrayed by the fact that all subnet bits and host bits are off! That's because with dynamic routing, it's not my job and it's up to the routing protocol to find the subnets and populate the routing tables. And since we have no router buddies running RIP, we won't see any RIP routes in the routing table yet.

SF

Let's configure our SF router now, which is connected to two networks. We need to configure both directly connected classful networks, not subnets:

SF#sh ip int brief

Interface         IP-Address      OK? Method Status             Protocol

FastEthernet0/0   192.168.10.1    YES manual up                    up

FastEthernet0/1   unassigned      YES unset  administratively down down

Serial0/0/0       172.16.10.2     YES manual up                    up

Serial0/0/1       unassigned      YES unset  administratively down down

SF#config

SF(config)#router rip

SF(config-router)#network 192.168.10.0

SF(config-router)#network 172.16.0.0

SF(config-router)#version 2

SF(config-router)#no auto-summary

SF(config-router)#do show ip route

C    192.168.10.0/24 is directly connected, FastEthernet0/0

L    192.168.10.1/32 is directly connected, FastEthernet0/0

     172.16.0.0/30 is subnetted, 3 subnets

R       172.16.10.4 [120/1] via 172.16.10.1, 00:00:08, Serial0/0/0

C       172.16.10.0 is directly connected, Serial0/0/0

L       172.16.10.2/32 is directly connected, Serial0/0

S    192.168.20.0/24 [150/0] via 172.16.10.1

     10.0.0.0/24 is subnetted, 1 subnets

R       10.10.10.0 [120/1] via 172.16.10.1, 00:00:08, Serial0/0/0

That was pretty straightforward. Let's talk about this routing table. Since we have one RIP buddy out there with whom we are exchanging routing tables, we can see the RIP networks coming from the Corp router. All the other routes still show up as static and local. RIP also found both connections through the Corp router to networks 10.10.10.0 and 172.16.10.4. But we're not done yet!

LA

Let's configure our LA router with RIP, only I'm going to remove the default route first, even though I don't have to. You'll see why soon:

LA#config t

LA(config)#no ip route 0.0.0.0 0.0.0.0

LA(config)#router rip

LA(config-router)#network 192.168.20.0

LA(config-router)#network 172.16.0.0

LA(config-router)#no auto

LA(config-router)#vers 2

LA(config-router)#do show ip route

R    192.168.10.0/24 [120/2] via 172.16.10.5, 00:00:10, Serial0/0/1

     172.16.0.0/30 is subnetted, 3 subnets

C       172.16.10.4 is directly connected, Serial0/0/1

L       172.16.10.6/32 is directly connected, Serial0/0/1

R       172.16.10.0 [120/1] via 172.16.10.5, 00:00:10, Serial0/0/1

C    192.168.20.0/24 is directly connected, FastEthernet0/0

L    192.168.20.1/32 is directly connected, FastEthernet0/0

     10.0.0.0/24 is subnetted, 1 subnets

R       10.10.10.0 [120/1] via 172.16.10.5, 00:00:10, Serial0/0/1

The routing table is sprouting new Rs as we add RIP buddies! We can still see that all routes are in the routing table.

This output shows us basically the same routing table and the same entries that it had when we were using static routes—except for those Rs. An R indicates that the networks were added dynamically using the RIP routing protocol. The [120/1] is the administrative distance of the route (120) along with the metric, which for RIP is the number of hops to that remote network (1). From the Corp router, all networks are one hop away.

So, while yes, it's true that RIP has worked in our little internetwork, it's just not a great solution for most enterprises. Its maximum hop count of only 15 is a highly limiting factor. And it performs full routing-table updates every 30 seconds, which would bring a larger internetwork to a painful crawl in no time!

There's still one more thing I want to show you about RIP routing tables and the parameters used to advertise remote networks. Using a different router on a different network as an example for a second, look into the following output. Can you spot where the following routing table shows [120/15] in the 10.1.3.0 network metric? This means that the administrative distance is 120, the default for RIP, but the hop count is 15. Remember that each time a router sends out an update to a neighbor router, the hop count goes up by one incrementally for each route! Here's that output now:

Router#sh ip route

     10.0.0.0/24 is subnetted, 12 subnets

C       10.1.11.0 is directly connected, FastEthernet0/1

L       10.1.11.1/32 is directly connected, FastEthernet0/1

C       10.1.10.0 is directly connected, FastEthernet0/0

L       10.1.10.1/32 is directly connected, FastEthernet/0/0

R       10.1.9.0 [120/2] via 10.1.5.1, 00:00:15, Serial0/0/1

R       10.1.8.0 [120/2] via 10.1.5.1, 00:00:15, Serial0/0/1

R       10.1.12.0 [120/1] via 10.1.11.2, 00:00:00, FastEthernet0/1

R       10.1.3.0 [120/15] via 10.1.5.1, 00:00:15, Serial0/0/1

R       10.1.2.0 [120/1] via 10.1.5.1, 00:00:15, Serial0/0/1

R       10.1.1.0 [120/1] via 10.1.5.1, 00:00:15, Serial0/0/1

R       10.1.7.0 [120/2] via 10.1.5.1, 00:00:15, Serial0/0/1

R       10.1.6.0 [120/2] via 10.1.5.1, 00:00:15, Serial0/0/1

C       10.1.5.0 is directly connected, Serial0/0/1

L       10.1.5.1/32 is directly connected, Serial0/0/1

R       10.1.4.0 [120/1] via 10.1.5.1, 00:00:15, Serial0/0/1

So this [120/15] is really bad. We're basically doomed because the next router that receives the table from this router will just discard the route to network 10.1.3.0 since the hop count would rise to 16, which is invalid!

Holding Down RIP Propagations

You probably don't want your RIP network advertised everywhere on your LAN and WAN. There's enough stress in networking already and not a whole lot to be gained by advertising your RIP network to the Internet!

There are a few different ways to stop unwanted RIP updates from propagating across your LANs and WANs, and the easiest one is through the passive-interface command. This command prevents RIP update broadcasts from being sent out of a specified interface but still allows that same interface to receive RIP updates.

Here's an example of how to configure a passive-interface on the Corp router's Fa0/1 interface, which we will pretend is connected to a LAN that we don't want RIP on (and the interface isn't shown in the figure):

Corp#config t

Corp(config)#router rip

Corp(config-router)#passive-interface FastEthernet 0/1

This command will stop RIP updates from being propagated out of FastEthernet interface 0/1, but it can still receive RIP updates.

Advertising a Default Route Using RIP

Now I'm going to guide you through how to advertise a way out of your autonomous system to other routers, and you'll see this is completed the same way with OSPF. Imagine that our Corp router's Fa0/0 interface is connected to some type of Metro-Ethernet as a connection to the Internet. This is a pretty common configuration today that uses a LAN interface to connect to the ISP instead of a serial interface.

If we do add an Internet connection to Corp, all routers in our AS (SF and LA) must know where to send packets destined for networks on the Internet or they'll just drop the packets when they get a remote request. One solution to this little hitch would be to place a default route on every router and funnel the information to Corp, which in turn would have a default route to the ISP. Most people do this type of configuration in small- to medium-size networks because it actually works pretty well!

But since I'm running RIPv2 on all routers, I'll just add a default route on the Corp router to our ISP, as I would normally. I'll then add another command to advertise my network to the other routers in the AS as the default route to show them where to send packets destined for the Internet.

Here's my new Corp configuration:

Corp(config)#ip route 0.0.0.0 0.0.0.0 fa0/0

Corp(config)#router rip

Corp(config-router)#default-information originate

Now, let's take a look at the last entry found in the Corp routing table:

S*   0.0.0.0/0 is directly connected, FastEthernet0/0

Let's see if the LA router can see this same entry:

LA#sh ip route

Gateway of last resort is 172.16.10.5 to network 0.0.0.0

 

R    192.168.10.0/24 [120/2] via 172.16.10.5, 00:00:04, Serial0/0/1

     172.16.0.0/30 is subnetted, 2 subnets

C       172.16.10.4 is directly connected, Serial0/0/1

L       172.16.10.5/32 is directly connected, Serial0/0/1

R       172.16.10.0 [120/1] via 172.16.10.5, 00:00:04, Serial0/0/1

C    192.168.20.0/24 is directly connected, FastEthernet0/0

L    192.168.20.1/32 is directly connected, FastEthernet0/0

     10.0.0.0/24 is subnetted, 1 subnets

R       10.10.10.0 [120/1] via 172.16.10.5, 00:00:04, Serial0/0/1

R    192.168.218.0/24 [120/3] via 172.16.10.5, 00:00:04, Serial0/0/1

R    192.168.118.0/24 [120/2] via 172.16.10.5, 00:00:05, Serial0/0/1

R*   0.0.0.0/0 [120/1] via 172.16.10.5, 00:00:05, Serial0/0/1

Can you see that last entry? It screams that it's an RIP injected route, but it's also a default route, so our default-information originate command is working! Last, notice that the gateway of last resort is now set as well.

Exam Essentials

Configure RIPv2 routing. To configure RIP routing, first you must be in global configuration mode and then you type the command router rip. Then you add all directly connected networks, making sure to use the classful address and the version 2 command and to disable auto-summarization with the no auto-summary command.

Troubleshoot basic layer 3 end-to-end connectivity issues

To be prepared for the exam, it's a great idea to get used to connecting to various routers and pinging from them. Of course, pinging from a router is not as good as pinging from the host reporting the problem, but that doesn't mean we can't isolate some problems from the routers themselves.

Let's use Figure 3.23 as a basis to run through some troubleshooting scenarios.

In this first scenario, a manager calls you and says that he cannot log in to Server1 from PC1. Your job is to find out why and fix it. The Cisco objectives are clear on the troubleshooting steps you need to take when a problem has been reported, and here they are:

1. Check the cables to find out if there's a faulty cable or interface in the mix and verify the interface's statistics.
2. Make sure that devices are determining the correct path from the source to the destination. Manipulate the routing information if needed.
3. Verify that the default gateway is correct.
4. Verify that name resolution settings are correct.
5. Verify that there are no access control lists (ACLs) blocking traffic.

In order to effectively troubleshoot this problem, we'll narrow down the possibilities by the process of elimination. We'll start with PC1 and verify that it's configured correctly and also that IP is working correctly.

There are four steps for checking the PC1 configuration:

1. Test that the local IP stack is working by pinging the loopback address.
2. Test that the local IP stack is talking to the Data Link layer (LAN driver) by pinging the local IP address.
3. Test that the host is working on the LAN by pinging the default gateway.
4. Test that the host can get to remote networks by pinging remote Server1.

Let's check out the PC1 configuration by using the ipconfig command, or ifconfig on a Mac:

C:UsersTodd Lammle>ipconfig

 

Windows IP Configuration

 

Ethernet adapter Local Area Connection:

 

   Connection-specific DNS Suffix  . : localdomain

   Link-local IPv6 Address . . . . . : fe80::64e3:76a2:541f:ebcb%11

   IPv4 Address. . . . . . . . . . . : 10.1.1.10

   Subnet Mask . . . . . . . . . . . : 255.255.255.0

   Default Gateway . . . . . . . . . : 10.1.1.1

We can also check the route table on the host with the route print command to see if it truly does know the default gateway:

C:UsersTodd Lammle>route print

[output cut]

IPv4 Route Table

=======================================================================

Active Routes:

Network Destination      Netmask        Gateway       Interface  Metric

          0.0.0.0        0.0.0.0        10.1.1.10     10.1.1.1   10

[output cut]

Between the output of the ipconfig command and the route print command, we can be assured that the hosts are aware of the correct default gateway.

So, let's verify that the local IP stack is initialized by pinging the loopback address now:

C:UsersTodd Lammle>ping 127.0.0.1

 

Pinging 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

 

Ping statistics for 127.0.0.1:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 0ms, Maximum = 0ms, Average = 0ms

This first output confirms the IP address and configured default gateway of the host, and then I verified the fact that the local IP stack is working. Our next move is to verify that the IP stack is talking to the LAN driver by pinging the local IP address.

C:UsersTodd Lammle>ping 10.1.1.10

 

Pinging 10.1.1.10 with 32 bytes of data:

Reply from 10.1.1.10: bytes=32 time<1ms TTL=128

Reply from 10.1.1.10: bytes=32 time<1ms TTL=128

Reply from 10.1.1.10: bytes=32 time<1ms TTL=128

Reply from 10.1.1.10: bytes=32 time<1ms TTL=128

 

Ping statistics for 10.1.1.10:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 0ms, Maximum = 0ms, Average = 0ms

And now that we know the local stack is solid and the IP stack is communicating to the LAN driver, it's time to check our local LAN connectivity by pinging the default gateway:

C:UsersTodd Lammle>ping 10.1.1.1

 

Pinging 10.1.1.1 with 32 bytes of data:

Reply from 10.1.1.1: bytes=32 time<1ms TTL=128

Reply from 10.1.1.1: bytes=32 time<1ms TTL=128

Reply from 10.1.1.1: bytes=32 time<1ms TTL=128

Reply from 10.1.1.1: bytes=32 time<1ms TTL=128

 

Ping statistics for 10.1.1.1:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Looking good! I'd say our host is in good shape. Let's try to ping the remote server next to see if our host is actually getting off the local LAN to communicate remotely:

C:UsersTodd Lammle>ping 172.16.20.254

 

Pinging 172.16.20.254 with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

 

Ping statistics for 172.16.20.254:

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Well, looks like we've confirmed local connectivity but not remote connectivity, so we're going to have to dig deeper to isolate our problem. But first, and just as important, it's key to make note of what we can rule out at this point:

1. The PC is configured with the correct IP address and the local IP stack is working.
2. The default gateway is configured correctly and the PC's default gateway configuration matches the router interface IP address.
3. The local switch is working because we can ping through the switch to the router.
4. We don't have a local LAN issue, meaning our Physical layer is good because we can ping the router. If we couldn't ping the router, we would need to verify our physical cables and interfaces.

Let's see if we can narrow the problem down further using the traceroute command:

C:UsersTodd Lammle>tracert 172.16.20.254

 

Tracing route to 172.16.20.254 over a maximum of 30 hops

 

  1     1 ms     1 ms    <1 ms  10.1.1.1

  2     *        *        *     Request timed out.

  3     *        *        *     Request timed out.

Well, we didn't get beyond our default gateway, so let's go over to R2 and see if we can talk locally to the server:

R2#ping 172.16.20.254

 

Pinging 172.16.20.254 with 32 bytes of data:

Reply from 172.16.20.254: bytes=32 time<1ms TTL=128

Reply from 172.16.20.254: bytes=32 time<1ms TTL=128

Reply from 172.16.20.254: bytes=32 time<1ms TTL=128

Reply from 172.16.20.254: bytes=32 time<1ms TTL=128

 

Ping statistics for 172.16.20.254:

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Okay, we just eliminated a local LAN problem by connecting to Server1 from the R2 router, so we're good there. Let's summarize what we know so far:

1. PC1 is configured correctly.
2. The switch located on the 10.1.1.0 LAN is working.
3. PC1's default gateway is configured correctly.
4. R2 can communicate to Server1, so we don't have a remote LAN issue.

But something is still clearly wrong, so what should we check now? Now would be a great time to verify the Server1 IP configuration and make sure the default gateway is configured correctly. Let's take a look:

C:UsersServer1>ipconfig

 

Windows IP Configuration

 

Ethernet adapter Local Area Connection:

 

   Connection-specific DNS Suffix  . : localdomain

   Link-local IPv6 Address . . . . . : fe80::7723:76a2:e73c:2acb%11

   IPv4 Address. . . . . . . . . . . : 172.16.20.254

   Subnet Mask . . . . . . . . . . . : 255.255.255.0

   Default Gateway . . . . . . . . . : 172.16.20.1

Okay—the Server1 configuration looks good and the R2 router can ping the server, so it seems that the server's local LAN is solid, the local switch is working, and there are no cable or interface issues. But let's zoom in on interface Fa0/0 on R2 and talk about what to expect if there were errors on this interface:

R2#sh int fa0/0

FastEthernet0/0 is up, line protocol is up

[output cut]

  Full-duplex, 100Mb/s, 100BaseTX/FX

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input 00:00:05, output 00:00:01, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

     1325 packets input, 157823 bytes

     Received 1157 broadcasts (0 IP multicasts)

     0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog

     0 input packets with dribble condition detected

     2294 packets output, 244630 bytes, 0 underruns

     0 output errors, 0 collisions, 3 interface resets

     347 unknown protocol drops

     0 babbles, 0 late collision, 0 deferred

     4 lost carrier, 0 no carrier

     0 output buffer failures, 0 output buffers swapped out

You've got to be able to analyze interface statistics to find problems there if they exist, so let's pick out the important factors relevant to meeting that challenge effectively now.

Speed and duplex settings Good to know that the most common cause of interface errors is a mismatched duplex mode between two ends of an Ethernet link. This is why it's so important to make sure that the switch and its hosts (PCs, router interfaces, etc.) have the same speed setting. If not, they just won't connect. And if they have mismatched duplex settings, you'll receive a legion of errors, which cause nasty performance issues, intermittent connectivity—even total loss of communication!

Using autonegotiation for speed and duplex is a very common practice, and it's enabled by default. But if this fails for some reason, you'll have to set the configuration manually like this:

Switch(config)#int gi0/1

Switch(config-if)#speed ?

  10    Force 10 Mbps operation

  100   Force 100 Mbps operation

  1000  Force 1000 Mbps operation

  auto  Enable AUTO speed configuration

Switch(config-if)#speed 1000

Switch(config-if)#duplex  ?

  auto  Enable AUTO duplex configuration

  full  Force full duplex operation

  half  Force half-duplex operation

Switch(config-if)#duplex  full

Input queue drops If the input queue drops counter increments, this signifies that more traffic is being delivered to the router that it can process. If this is consistently high, try to determine exactly when these counters are increasing and how the events relate to CPU usage. You'll see the ignored and throttle counters increment as well.

Output queue drops This counter indicates that packets were dropped due to interface congestion, leading to queuing delays. When this occurs, applications like VoIP will experience performance issues. If you observe this constantly incrementing, consider QoS.

Input errors Input errors often indicate high errors such as CRCs. This can point to cabling problems, hardware issues, or duplex mismatches.

Output errors This is the total number of frames that the port tried to transmit when an issue such as a collision occurred.

We're going to move on in our troubleshooting process of elimination by analyzing the routers' actual configurations. Here's R1's routing table:

R1>sh ip route

[output cut]

Gateway of last resort is 192.168.10.254 to network 0.0.0.0

 

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

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C        10.1.1.0/24 is directly connected, FastEthernet0/0

L        10.1.1.1/32 is directly connected, FastEthernet0/0

      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.10.0/24 is directly connected, FastEthernet0/1

L        192.168.10.1/32 is directly connected, FastEthernet0/1

This actually looks pretty good! Both of our directly connected networks are in the table and we can confirm that we have a default route going to the R2 router. So now let's verify the connectivity to R2 from R1:

R1>sh ip int brief

Interface               IP-Address    OK? Method Status              Protocol

FastEthernet0/0         10.1.1.1      YES manual up                    up

FastEthernet0/1         192.168.10.1  YES manual up                    up

Serial0/0/0             unassigned    YES unset  administratively down down

Serial0/1/0             unassigned    YES unset  administratively down down

R1>ping 192.168.10.254

Type escape sequence to abort.

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

!!!!!

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

This looks great too! Our interfaces are correctly configured with the right IP address and the Physical and Data Link layers are up. By the way, I also tested layer 3 connectivity by pinging the R2 Fa0/1 interface.

Since everything looks good so far, our next step is to check into the status of R2's interfaces:

R2>sh ip int brief

Interface               IP-Address      OK? Method Status              Protocol

FastEthernet0/0         172.16.20.1     YES manual up                    up

FastEthernet0/1         192.168.10.254  YES manual up                    up

R2>ping 192.168.10.1

Type escape sequence to abort.

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

!!!!!

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

Well, everything still checks out at this point. The IP addresses are correct and the Physical and Data Link layers are up. I also tested the layer 3 connectivity with a ping to R1, so we're all good so far. We'll examine the routing table next:

R2>sh ip route

[output cut]

Gateway of last resort is not set

 

      10.0.0.0/24 is subnetted, 1 subnets

S        10.1.1.0 is directly connected, FastEthernet0/0

      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks

C        172.16.20.0/24 is directly connected, FastEthernet0/0

L        172.16.20.1/32 is directly connected, FastEthernet0/0

      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.10.0/24 is directly connected, FastEthernet0/1

L        192.168.10.254/32 is directly connected, FastEthernet0/1

Okay—we can see that all our local interfaces are in the table, as well as a static route to the 10.1.1.0 network. But do you see the problem? Look closely at the static route. The route was entered with an exit interface of Fa0/0, and the path to the 10.1.1.0 network is out Fa0/1! Aha! We've found our problem! Let's fix R2:

R2#config t

R2(config)#no ip route 10.1.1.0 255.255.255.0 fa0/0

R2(config)#ip route 10.1.1.0 255.255.255.0 192.168.10.1

That should do it. Let's verify from PC1:

C:UsersTodd Lammle>ping 172.16.20.254

 

Pinging 172.16.20.254 with 32 bytes of data:

Reply from 172.16.20.254: bytes=32 time<1ms TTL=128

Reply from 172.16.20.254: bytes=32 time<1ms TTL=128

Reply from 172.16.20.254: bytes=32 time<1ms TTL=128

Reply from 172.16.20.254: bytes=32 time<1ms TTL=128

 

Ping statistics for 172.16.20.254

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Our snag appears to be solved, but just to make sure, we really need to verify with a higher-level protocol like Telnet:

C:UsersTodd Lammle>telnet 172.16.20.254

Connecting To 172.16.20.254...Could not open connection to the host, on

port 23: Connect failed

Okay, that's not good! We can ping to Server1, but we can't telnet to it. In the past, I've verified that telnetting to this server worked, but it's still possible that we have a failure on the server side. To find out, let's verify our network first, starting at R1:

R1>ping 172.16.20.254

Type escape sequence to abort.

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

!!!!!

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

R1>telnet 172.16.20.254

Trying 172.16.20.254 ...

% Destination unreachable; gateway or host down

This is some pretty ominous output! Let's try from R2 and see what happens:

R2#telnet 172.16.20.254

Trying 172.16.20.254 ... Open

 

User Access Verification

 

Password:

Oh my—I can ping the server from a remote network, but I can't telnet to it; however, the local router R2 can! These factors eliminate the server being a problem since I can telnet to the server when I'm on the local LAN.

And we know we don't have a routing problem because we fixed that already. So what's next? Let's check to see if there's an ACL on R2:

R2>sh access-lists

Extended IP access list 110

    10 permit icmp any any (25 matches)

Seriously? What a loopy access list to have on a router! This ridiculous list permits ICMP, but that's it. It denies everything except ICMP due to the implicit deny ip any any at the end of every ACL. But before we uncork the champagne, we need to see if this foolish list has been applied to our interfaces on R2 to confirm that this is really our problem:

R2>sh ip int fa0/0

FastEthernet0/0 is up, line protocol is up

  Internet address is 172.16.20.1/24

  Broadcast address is 255.255.255.255

  Address determined by setup command

  MTU is 1500 bytes

  Helper address is not set

  Directed broadcast forwarding is disabled

  Outgoing access list is 110

  Inbound  access list is not set

There it is—that's our problem all right! In case you're wondering why R2 could telnet to Server1, it's because an ACL filters only packets trying to go through the router—not packets generated at the router. Let's get to work and fix this:

R2#config t

R2(config)#no access-list 110

I just verified that I can telnet from PC1 to Server1, but let's try telnetting from R1 again:

R1#telnet 172.16.20.254

Trying 172.16.20.254 ... Open

 

User Access Verification

 

Password:

Nice—looks like we're set, but what about using the name?

R1#telnet Server1

Translating "Server1"...domain server (255.255.255.255)

 

% Bad IP address or host name

Well, we're not all set just yet. Let's fix R1 so that it can provide name resolution:

R1(config)#ip host Server1 172.16.20.254

R1(config)#^Z

R1#telnet Server1

Trying Server1 (172.16.20.254)... Open

 

User Access Verification

 

Password:

Great—things are looking good from the router, but if the customer can't telnet to the remote host using the name, we've got to check the DNS server to confirm connectivity and for the correct entry to the server. Another option would be to configure the local host table manually on PC1.

The last thing to do is to check the server to see if it's responding to HTTP requests via the telnet command, believe it or not! Here's an example:

R1#telnet 172.16.20.254 80

Trying 172.16.20.254, 80 ... Open

Yes—finally! Server1 is responding to requests on port 80, so we're in the clear.

Troubleshooting IPv6 Network Connectivity

I'm going to be straight with you: There isn't a lot that's going to be much different between this section and the process you just went through with the IPv4 troubleshooting steps. Except regarding the addressing of course! So other than that key factor, we'll take the same approach, using Figure 3.24, specifically because I really want to highlight the differences associated with IPv6. So the problem scenario I'm going to use will also stay the same: PC1 cannot communicate to Server1.

I want to point out that this is not an “introduction to IPv6,” so I'm assuming you've got some IPv6 fundamentals down.

Notice that I documented both the link-local and global addresses assigned to each router interface in Figure 3.24. We need both in order to troubleshoot, so right away, you can see that things get a bit more complicated because of the longer addresses and the fact that there are multiple addresses per interface involved!

Here are the troubleshooting steps we'll progress through in our investigation:

1. Check the cables because there might be a faulty cable or interface. Verify interface statistics.
2. Make sure that devices are determining the correct path from the source to the destination. Manipulate the routing information if needed.
3. Verify that the default gateway is correct.
4. Verify that name resolution settings are correct, and especially for IPv6, make sure the DNS server is reachable via IPv4 and IPv6.
5. Verify that there are no ACLs that are blocking traffic.

In order to troubleshoot this problem, we'll use the same process of elimination, beginning with PC1. We must verify that it's configured correctly and that IP is working properly. Let's start by pinging the loopback address to verify the IPv6 stack:

C:UsersTodd Lammle>ping ::1

 

Pinging ::1 with 32 bytes of data:

Reply from ::1: time<1ms

Reply from ::1: time<1ms

Reply from ::1: time<1ms

Reply from ::1: time<1ms

Well, the IPv6 stack checks out, so let's ping the Fa0/0 of R1, which PC1 is directly connected to on the same LAN, starting with the link-local address:

C:UsersTodd Lammle>ping fe80::21a:6dff:fe37:a44e

 

Pinging fe80:21a:6dff:fe37:a44e with 32 bytes of data:

Reply from fe80::21a:6dff:fe37:a44e: time<1ms

Reply from fe80::21a:6dff:fe37:a44e: time<1ms

Reply from fe80::21a:6dff:fe37:a44e: time<1ms

Reply from fe80::21a:6dff:fe37:a44e: time<1ms

Next, we'll ping the global address on Fa0/0:

C:UsersTodd Lammle>ping 2001:db8:3c4d:3:21a:6dff:fe37:a44e

 

Pinging 2001:db8:3c4d:3:21a:6dff:fe37:a44e with 32 bytes of data:

Reply from 2001:db8:3c4d:3:21a:6dff:fe37:a44e: time<1ms

Reply from 2001:db8:3c4d:3:21a:6dff:fe37:a44e: time<1ms

Reply from 2001:db8:3c4d:3:21a:6dff:fe37:a44e: time<1ms

Reply from 2001:db8:3c4d:3:21a:6dff:fe37:a44e: time<1ms

Okay—looks like PC1 is configured and working on the local LAN to the R1 router, so we've confirmed the Physical, Data Link, and Network layers between the PC1 and the R1 router Fa0/0 interface.

Our next move is to check the local connection on Server1 to the R2 router to verify that LAN. First we'll ping the link-local address of the router from Server1:

C:UsersServer1>ping fe80::21a:6dff:fe64:9b2

 

Pinging fe80::21a:6dff:fe64:9b2  with 32 bytes of data:

Reply from fe80::21a:6dff:fe64:9b2: time<1ms

Reply from fe80::21a:6dff:fe64:9b2: time<1ms

Reply from fe80::21a:6dff:fe64:9b2: time<1ms

Reply from fe80::21a:6dff:fe64:9b2: time<1ms

And next, we'll ping the global address of Fa0/0 on R2:

C:UsersServer1>ping 2001:db8:3c4d:1:21a:6dff:fe37:a443

 

Pinging 2001:db8:3c4d:1:21a:6dff:fe37:a443 with 32 bytes of data:

Reply from 2001:db8:3c4d:1:21a:6dff:fe37:a443: time<1ms

Reply from 2001:db8:3c4d:1:21a:6dff:fe37:a443: time<1ms

Reply from 2001:db8:3c4d:1:21a:6dff:fe37:a443: time<1ms

Reply from 2001:db8:3c4d:1:21a:6dff:fe37:a443: time<1ms

Let's quickly summarize what we know at this point:

1. By using the ipconfig /all command on PC1 and Server1, I was able to document their global and link-local IPv6 addresses.
2. We know the IPv6 link-local addresses of each router interface.
3. We know the IPv6 global address of each router interface.
4. We can ping from PC1 to router R1's Fa0/0 interface.
5. We can ping from Server1 to router R2's Fa0/0 interface.
6. We can eliminate a local problem on both LANs.

From here, we'll go to PC1 and see if we can route to Server1:

C:UsersTodd Lammle>tracert 2001:db8:3c4d:1:a14c:8c33:2d1:be3d

 

Tracing route to 2001:db8:3c4d:1:a14c:8c33:2d1:be3d over a maximum of 30 hops

 

  1     Destination host unreachable.

Okay, now that's not good. Looks like we might have a routing problem. And on this little network, we're doing static IPv6 routing, so getting to the bottom of things will definitely take a little effort! But before we start looking into our potential routing issue, let's check the link between R1 and R2. We'll ping R2 from R1 to test the directly connected link.

The first thing you need to do before attempting to ping between routers is verify your addresses—yes, verify them again! Let's check out both routers, then try pinging from R1 to R2:

R1#sh ipv6 int brief

FastEthernet0/0            [up/up]

    FE80::21A:6DFF:FE37:A44E

    2001:DB8:3C4D:3:21A:6DFF:FE37:A44E

FastEthernet0/1            [up/up]

    FE80::21A:6DFF:FE37:A44F

    2001:DB8:3C4D:2:21A:6DFF:FE37:A44F

 

R2#sh ipv6 int brief

FastEthernet0/0            [up/up]

    FE80::21A:6DFF:FE64:9B2

    2001:DB8:3C4D:1:21A:6DFF:FE37:A443

FastEthernet0/1            [up/up]

    FE80::21A:6DFF:FE64:9B3

    2001:DB8:3C4D:2:21A:6DFF:FE64:9B3

 

R1#ping 2001:DB8:3C4D:2:21A:6DFF:FE64:9B3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to ping 2001:DB8:3C4D:2:21A:6DFF:FE64:9B3,

timeout is 2 seconds:

!!!!!

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

In the preceding output, you can see that I now have the IPv6 addresses for both the R1 and R2 directly connected interfaces. The output also shows that I used the Ping program to verify layer 3 connectivity. Just as with IPv4, we need to resolve the logical (IPv6) address to a MAC address in order to communicate on the local LAN. But unlike IPv4, IPv6 doesn't use ARP—it uses ICMPv6 neighbor solicitations instead—so after the successful ping, we can now see the neighbor resolution table on R1:

R1#sh ipv6 neighbors

IPv6 Address                          Age Link-layer Addr State Interface

FE80::21A:6DFF:FE64:9B3                 0 001a.6c46.9b09  DELAY Fa0/1

2001:DB8:3C4D:2:21A:6DFF:FE64:9B3       0 001a.6c46.9b09  REACH Fa0/1

Let's take a minute to talk about the possible states that a resolved address shows us:

INCMP (incomplete) Address resolution is being performed on the entry. A neighbor solicitation message has been sent, but the neighbor message has not yet been received.

REACH (reachable) Positive confirmation has been received confirming that the path to the neighbor is functioning correctly. REACH is good!

STALE The state is STALE when the interface has not communicated within the neighbor reachable time frame. The next time the neighbor communicates, the state will change back to REACH.

DELAY Occurs after the STALE state, when no reachability confirmation has been received within what's known as the DELAY_FIRST_PROBE_TIME. This means that the path was functioning but it hasn't had communication within the neighbor reachable time frame.

PROBE When in PROBE state, the configured interface is resending a neighbor solicitation and waiting for a reachability confirmation from a neighbor.

We can verify our default gateway with IPv6 with the ipconfig command like this:

C:UsersTodd Lammle>ipconfig

   Connection-specific DNS Suffix  . : localdomain

   IPv6 Address. . . . . . . . . . . : 2001:db8:3c4d:3:ac3b:2ef:1823:8938

   Temporary IPv6 Address. . . . . . : 2001:db8:3c4d:3:2f33:44dd:211:1c3d

   Link-local IPv6 Address . . . . . : fe80::ac3b:2ef:1823:8938%11

   IPv4 Address. . . . . . . . . . . : 10.1.1.10

   Subnet Mask . . . . . . . . . . . : 255.255.255.0

   Default Gateway . . . . . . . . . : Fe80::21a:6dff:fe37:a44e%11

      10.1.1.1

It's important to understand that the default gateway will be the link-local address of the router, and in this case, we can see that the address the host learned is truly the link-local address of the Fa0/0 interface of R1. The %11 is just used to identify an interface and isn't used as part of the IPv6 address.

In addition to the ipconfig command, we can use the command netsh interface ipv6 show neighbor to verify our default gateway address:

C:UsersTodd Lammle>netsh interface ipv6 show neighbor

[output cut]

 

Interface 11: Local Area Connection

 

Internet Address                              Physical Address   Type

--------------------------------------------  -----------------  -----------

2001:db8:3c4d:3:21a:6dff:fe37:a44e            00-1a-6d-37-a4-4e  (Router)

Fe80::21a:6dff:fe37:a44e                      00-1a-6d-37-a4-4e  (Router)

ff02::1                                       33-33-00-00-00-01  Permanent

ff02::2                                       33-33-00-00-00-02  Permanent

ff02::c                                       33-33-00-00-00-0c  Permanent

ff02::16                                      33-33-00-00-00-16  Permanent

ff02::fb                                      33-33-00-00-00-fb  Permanent

ff02::1:2                                     33-33-00-01-00-02  Permanent

ff02::1:3                                     33-33-00-01-00-03  Permanent

ff02::1:ff1f:ebcb                             33-33-ff-1f-eb-cb  Permanent

Let's establish the information we have right now:

1. Our PC1 and Server1 configurations are working and have been verified.
2. The LANs are working and verified, so there is no Physical layer issue.
3. The default gateways are correct.
4. The link between the R1 and R2 routers is working and verified.

So all this tells us is that it's now time to check our routing tables! We'll start with the R1 router:

R1#sh ipv6 route

C   2001:DB8:3C4D:2::/64 [0/0]

     via FastEthernet0/1, directly connected

L   2001:DB8:3C4D:2:21A:6DFF:FE37:A44F/128 [0/0]

     via FastEthernet0/1, receive

C   2001:DB8:3C4D:3::/64 [0/0]

     via FastEthernet0/0, directly connected

L   2001:DB8:3C4D:3:21A:6DFF:FE37:A44E/128 [0/0]

     via FastEthernet0/0, receive

L   FF00::/8 [0/0]

     via Null0, receive

All we can see in the output is the two directly connected interfaces configured on the router, and that won't help us send IPv6 packets to the 2001:db8:3c4d:1::/64 subnet off of Fa0/0 on R2. So let's find out what R2 can tell us:

R2#sh ipv6 route

C   2001:DB8:3C4D:1::/64 [0/0]

     via FastEthernet0/0, directly connected

L   2001:DB8:3C4D:1:21A:6DFF:FE37:A443/128 [0/0]

     via FastEthernet0/0, receive

C   2001:DB8:3C4D:2::/64 [0/0]

     via FastEthernet0/1, directly connected

L   2001:DB8:3C4D:2:21A:6DFF:FE64:9B3/128 [0/0]

     via FastEthernet0/1, receive

S   2001:DB8:3C4D:3::/64 [1/0]

     via 2001:DB8:3C4D:2:21B:D4FF:FE0A:539

L   FF00::/8 [0/0]

     via Null0, receive

Now we're talking—that tells us a lot more than R1's table did! We have both of our directly connected configured LANs, Fa0/0 and Fa0/1, right there in the routing table, as well as a static route to 2001:DB8:3C4D:3::/64, which is the remote LAN Fa0/0 off of R1, which is good. Now let's fix the route problem on R1 by adding a route that gives us access to the Server1 network.

R1(config)#ipv6 route ::/0 fastethernet 0/1 FE80::21A:6DFF:FE64:9B3

I want to point out that I didn't need to make the default route as difficult as I did. I entered both the exit interface and next-hop link-local address when just the exit interface or next-hop global addresses would be mandatory, but not the link-local. So it could have simply just been this:

R1(config)#ipv6 route ::/0 fa0/1

Next, we'll verify that we can now ping from PC1 to Server1:

C:UsersTodd Lammle>ping 2001:db8:3c4d:1:a14c:8c33:2d1:be3d

 

Pinging 2001:db8:3c4d:1:a14c:8c33:2d1:be3d with 32 bytes of data:

Reply from 2001:db8:3c4d:1:a14c:8c33:2d1:be3d: time<1ms

Reply from 2001:db8:3c4d:1:a14c:8c33:2d1:be3d: time<1ms

Reply from 2001:db8:3c4d:1:a14c:8c33:2d1:be3d: time<1ms

Reply from 2001:db8:3c4d:1:a14c:8c33:2d1:be3d: time<1ms

Sweet—we're looking golden with this particular scenario! But know that it is still possible to have name resolution issues. If that were the case, you would just need to check your DNS server or local host table.

Moving on, it's a good time to check into your ACLs, especially if you're still having a problem after troubleshooting all your local LANs and all other potential routing issues.

Troubleshooting IPv6 Extended Access Lists

Let's create an extended IPv6 ACL on R2. First, understand that you can only create named extended IPv6 ACLs, so you don't need to specify standard or extended in your named list, and although you won't see any sequence numbers, you can still somewhat edit a named IPv6 ACL, meaning you can delete a single line but there is no way to insert a line other than at the end of the ACL.

In addition, there is an implicit deny ip any any at the bottom of every IPv4 access list; however, IPv6 access lists actually have three implied statements at the bottom:

• permit icmp any any nd-na
• permit icmp any any nd-ns
• deny ipv6 any any

The two permit statements are required for neighbor discovery, which is an important protocol in IPv6 because it's the replacement for ARP.

Using Figure 3.24 network layout and IPv6 addresses, let's create an IPv6 extended named ACL that blocks Telnet to Server1 with an IPv6 address of 2001:db8:3c4d:1:a14c:8c33:2d1:be3d from PC1 with a destination IPv6 address of 2001:db8:3c4d:3:2ef:1823:8938. Since it's an IPv6 extended named ACL (always), we'll place it closest to the source address if possible.

Step 1: Test that you can telnet to the remote host.

R1#telnet 2001:db8:3c4d:1:a14c:8c33:2d1:be3d

Trying 2001:db8:3c4d:1:a14c:8c33:2d1:be3d... Open

 

Server1>

Okay, great—but that was way too much effort! Let's create an entry into the hosts table of R1 so I don't have to type an IPv6 address when trying to access that host:

R1(config)#ipv6 host Server1 2001:db8:3c4d:1:a14c:8c33:2d1:be3d

R1(config)#do sh host

[output cut]

 

Host Port Flags Age Type Address(es)

Server1 None (perm, OK) 0 IPV6 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D

 

Now I can just type this from now on (the name is case sensitive):

R1#telnet Server1

Trying 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D... Open

 

Server1>

Or better yet, just the name (telnet is the default):

R1#Server1

Trying 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D... Open

 

Server1>exit

 

Also, ping using the name:

R1#ping Server1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D,

timeout is 2 seconds:

!!!!!

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

Step 2: Create an ACL on R2 that stops Telnet to the remote host Server1 (2001:db8:3c4d:1:a14c:8c33:2d1:be3d). The name is absolutely case sensitive when applying to an interface.

R2(config)#ipv6 access-list Block_Telnet

R2(config-ipv6-acl)#

Step 3: Once you have created the named list, add your test parameters.

R2(config-ipv6-acl)#deny tcp host 2001:DB8:3C4D:2:21A:6DFF:FE37:A44F host

2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D eq telnet

R2(config-ipv6-acl)#permit ipv6 any any

Step 4: Configure your ACP on your router interface.

Since we're adding this to the R2 router in Figure 3.24, we'll add it to interface FastEthernet 0/1, stopping traffic closest to the source, and use the ipv6 traffic-filter command.

R2(config)#int fa0/1

R2(config-if)#ipv6 traffic-filter Block_Telnet out

Step 5: Test your access list by telnetting from Server1 on the R1 router.

R1#Server1

Trying 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D ...Open

Server1>

Hmm...and I tried really hard not to make a typo! Let's take a look.

R2#sh access-lists

IPv6 access list Block_Telnet

      deny tcp host 2001:DB8:3C4D:2:21A:6DFF:FE37:A44F host

2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D eq telnet (96 match(es))

      permit ipv6 any any (181 match(es))

Verifying the IPv6 addresses with the interfaces of the routers, this list looks correct. It's important to verify your addresses with a show ipv6 interface brief command. Let's take a look:

R1#sh ipv6 int brief

FastEthernet0/0 [up/up]

      FE80::2E0:B0FF:FED2:B701

      2001:DB8:3C4D:3:21A:6DFF:FE37:A44E

FastEthernet0/1 [up/up]

      FE80::2E0:B0FF:FED2:B702

      2001:DB8:3C4D:2:21A:6DFF:FE37:A44F

Since R1 Fa0/1 is my source address, we can see that this address is correct in my ACL. Let's take a look at the destination device:

Server1#sh ipv6 int br

FastEthernet0/0 [up/up]

      FE80::260:70FF:FED8:DD01

      2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D

Yup, this one is correct too! My IPv6 ACL is correct, so now we need to check our interface.

Step 6: Fix and/or edit your access list and/or interfaces.

R2#show running-config

[output cut]

!

interface FastEthernet0/0

      no ip address

      duplex auto

      speed auto

      ipv6 address 2001:DB8:3C4D:1:21A:6DFF:FE37:A443/64

      ipv6 rip 1 enable

!

interface FastEthernet0/1

      no ip address

      ipv6 traffic-filter Block_Telnet out

      duplex auto

      speed auto

      ipv6 address 2001:DB8:3C4D:2:21A:6DFF:FE64:9B3/64

      ipv6 rip 1 enable

!

Unlike with IPv4, where we can use the show ip interface command to see if an ACL is set, we can only use the show running-config command to verify if an IPv6 ACL is set on an interface. In the preceding output, we can see that I certainly did set the ACL to the interface Fa0/1; however, I configured it to out instead of in on the interface. Let's fix that.

R2#config t

R2(config)#int fa0/1

R2(config-if)#no ipv6 traffic-filter Block_Telnet out

R2(config-if)#ipv6 traffic-filter Block_Telnet in

Step 7: Retest your ACL.

R1#Server1

 

Trying 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D ...% Connection timed out;

remote host not responding

R1#

Looks good! Although I don't recommend using this method to block Telnet to a router, it was a great way to test our IPv6 ACLs.

Exam Essentials

Remember the Cisco steps in troubleshooting an IPv4 and IPv6 network.

1. Check the cables to find out if there's a faulty cable or interface in the mix and verify the interface's statistics.
2. Make sure that devices are determining the correct path from the source to the destination. Manipulate the routing information if needed.
3. Verify that the default gateway is correct.
4. Verify that name resolution settings are correct.
5. Verify that there are no ACLs blocking traffic.

Remember the commands to verify and troubleshoot IPv4 and IPv6. You need to remember and practice the commands used in this chapter, especially ping and traceroute (tracert on Windows). But we also used the Windows commands ipconfig and route print and Cisco's commands show ip int brief, show interface, and show ip route.

Remember to look at the statistics on a router and switch interface to determine problems. You've got to be able to analyze interface statistics to find problems if they exist, and this includes speed and duplex settings, input queue drops, output queue drops, and input and output errors.

Review Questions

You can find the answers in the Appendix.

1. What command was used to generate the following output?

      

   Codes: L - local, C - connected, S - static,

   [output cut]

           10.0.0.0/8 is variably subnetted, 6 subnets, 4 masks

   C       10.0.0.0/8 is directly connected, FastEthernet0/3

   L       10.0.0.1/32 is directly connected, FastEthernet0/3

   C       10.10.0.0/16 is directly connected, FastEthernet0/2

   L       10.10.0.1/32 is directly connected, FastEthernet0/2

   C       10.10.10.0/24 is directly connected, FastEthernet0/1

   L       10.10.10.1/32 is directly connected, FastEthernet0/1

   S*      0.0.0.0/0 is directly connected, FastEthernet0/0

2. You are viewing the routing table and you see an entry 10.1.1.1/32. What legend code would you expect to see next to this route?
   1. C
   2. L
   3. S
   4. D
3. Which of the following statements are true regarding the command ip route 172.16.4.0 255.255.255.0 192.168.4.2? (Choose two.)
   1. The command is used to establish a static route.
   2. The default administrative distance is used.
   3. The command is used to configure the default route.
   4. The subnet mask for the source address is 255.255.255.0.
   5. The command is used to establish a stub network.
4. What destination addresses will be used by HostA to send data to the HTTPS server as shown in the following network? (Choose two.)

   

   1. The IP address of the switch
   2. The MAC address of the remote switch
   3. The IP address of the HTTPS server
   4. The MAC address of the HTTPS server
   5. The IP address of RouterA's Fa0/0 interface
   6. The MAC address of RouterA's Fa0/0 interface
5. Using the output shown, what protocol was used to learn the MAC address for 172.16.10.1?

      Interface: 172.16.10.2 --- 0x3

     Internet Address      Physical Address      Type

     172.16.10.1          00-15-05-06-31-b0     dynamic

   1. ICMP
   2. ARP
   3. TCP
   4. UDP
6. Which of the following is called an advanced distance-vector routing protocol?
   1. OSPF
   2. EIGRP
   3. BGP
   4. RIP
7. When a packet is routed across a network, the ______________ in the packet changes at every hop while the ________ does not.
   1. MAC address, IP address
   2. IP address, MAC address
   3. Port number, IP address
   4. IP address, port number
8. Write the command that must be present for this layer 3 switch to provide inter-VLAN routing between the two VLANs created with these commands:

      

   S1(config)#int vlan 10

   S1(config-if)#ip address 192.168.10.1 255.255.255.0

   S1(config-if)#int vlan 20

   S1(config-if)#ip address 192.168.20.1 255.255.255.0

9. In the configuration and diagram shown, what command is missing to enable inter-VLAN routing between VLAN 2 and VLAN 3?

   

   1. encapsulation dot1q 3 under int f0/0.2
   2. encapsulation dot1q 2 under int f0/0.2
   3. no shutdown under int f0/0.2
   4. no shutdown under int f0/0.3
10. Based on the configuration shown here, what statement is true?

       S1(config)#ip routing

    S1(config)#int vlan 10

    S1(config-if)#ip address 192.168.10.1 255.255.255.0

    S1(config-if)#int vlan 20

    S1(config-if)#ip address 192.168.20.1 255.255.255.0

    1. This is a multilayer switch.
    2. The two VLANs are in the same subnet.
    3. Encapsulation must be configured.
    4. VLAN 10 is the management VLAN.