IPv6 Intro: Global Unicast Address, Link-Local Addresses, and a Brief Intro to Static Routing

In the last lab, we configured a link between R1 and R2, using the IP addresses "2001:co:ffee::4:1" and "2001:co:ffee::4:2," respectively.  Let's try something:
R1#sho ipv6 interface brief
FastEthernet0/0            [up/up]
    FE80::CE00:6BFF:FE8E:0
    2001:C0:FFEE::4:1
Loopback0                  [up/up]
    unassigned
R1#

Well, that's odd! I don't know about you, but I only recall configuring a single IPv6 address on Fa0/0 on R1, but the "sho ipv6 interface brief" command is displaying two addresses.

Actually, it's not odd at all. When you enable IPv6 on an interface, it automatically configures a special class of IPv6 addresses on the interface. Notice how the extra address begins with "FE80?" An IPv6 address that begins with FE80 is a "link-local" address, and they are automatically configured on every interface using IPv6. The IPv6 address that we manually added to the routers is called a "global unicast" address. At this point, you are probably wondering why we bothered to assign an IPv6 address to the interface if the router would automatically assign one, too. There's a hint buried within the names of these address types: "Link-local" and "global-unicast." "Link-local" addresses are locally scoped (where "locally" means local to that one interface), whereas "global-unicast" addresses are, well, globally-scoped. Try to ping the link-local address on R1 from R2:
R2#ping ipv6 fe80:0:0:0:ce00:6bff:fe8e:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE00:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE01:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/16/36 ms
R2#

Interesting...notice how the router prompted you to specify an output interface? Since link-local addresses are locally-scoped to one specific interface, you have to specify which interface the ping command should use to reach the destination address. Just for giggles, let's add a new interface, Fa1/0, to R2, and connect a third router to that interface:



We'll add the new IPv6 addresses on both R2 and R3 as we've done in the past, and we'll add a static route so that R3 knows how to reach the 2001:co:ffee::4:0/126 network:
R3(config)#ipv6 route 2001:00c0:ffee:0:0:0:4:0/126 2015:0:0:0:0:0:0:1
R3(config)#exit
R3#ping ipv6 2001:00c0:ffee:0:0:0:4:2

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

Good! Let's add a static route for the link-local address on R2, Fa0/0:
R3(config)#ipv6 route fe80:0000:0000:0000:ce01:6bff:fe8e:0/126 2015:0:0:0:0:0:0:1
% Invalid prefix
R3(config)#

"Locally-scoped" means you can't route these addresses. The only place they are valid is on the interface directly connected to the destination address. Therefore, you can't create a static route for a link-local address. Let's try one more thing, just for the fun of it:



We'll configure the subnet 2001::0/125 on each of these interfaces:
R1(config-if)#int fa0/0
R1(config-if)#ipv6 addr 2001:0:0:0:0:0:0:1/125
R1(config-if)#no shut

R2(config-if)#int fa0/0
R2(config-if)#ipv6 addr 2001:0:0:0:0:0:0:2/125
R2(config-if)#no shut

R3(config-if)#int fa0/0
R3(config-if)#ipv6 addr 2001:0:0:0:0:0:0:3/125
R3(config-if)#no shut

Now, let's make sure each router can ping the other two routers:
R1#ping ipv6 2001:0:0:0:0:0:0:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/36 ms
R1#ping ipv6 2001:0:0:0:0:0:0:3

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

(I've omitted the output from R2 and R3 for the sake of brevity, but I did test them)

What about the link-local interfaces? Can we ping them? Let's find out:
R1#sho ipv6 int brie
FastEthernet0/0            [up/up]
    FE80::CE00:6BFF:FE8E:0
    2001::1
<...snip...>
R2#sho ipv6 int brie
FastEthernet0/0            [up/up]
    FE80::CE01:6BFF:FE8E:0
    2001::2
<...snip...>
R3#sho ipv6 int brie
FastEthernet0/0            [up/up]
    FE80::CE03:6BFF:FE8E:0
    2001::3
<...snip...>

Now that we have the link-local addresses on each router, we'll try the ping test:
R1#ping ipv6 FE80::CE01:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE01:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE00:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/22/40 ms
R1#ping ipv6 FE80::CE03:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE03:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE00:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/36 ms
R1#
<...snip...>

R2#ping ipv6 FE80::CE00:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE00:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE01:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
R2#ping ipv6 FE80::CE03:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE03:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE01:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/20 ms
R2#
<...snip...>

R3#ping ipv6 FE80::CE00:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE00:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE03:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/14/40 ms
R3#ping ipv6 FE80::CE01:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE01:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE03:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/15/36 ms
R3#
<...snip...>


As you can see, the link-local interface is not limited to point-to-point networks; it will also work on multipoint networks.

One other interesting point to raise about IPv6 addresses: there is no broadcast address, as there is in IPv4. Instead, IPv6 uses multicast to replicate the functionality of IPv4 broadcast addresses. In additon to global unicast, link-local and multicast addresses, IPv6 also supports a few other special classes of addresses, but we will save them for another day. With what we have covered in this lab and the previous lab, we now have enough grounding to start playing with routing...but I'll save that for the next lab.

IPv6 Intro: Address Format and Subnetting

A couple of years ago, I created a lab, Advanced Cisco Routing: Implementing OSPF in IPv6. I probably got the cart before the horse when I created that lab, since that was the only in this blog (so far) where we even discussed IPv6. Ideally, I should have given an intro to IPv6 addressing and networking before creating a lab where we implemented a routing protocol in IPv6. Today, I'd like to fix that problem. Let's start with a basic introduction to IPv6, from the beginning.

I won't spend a lot of time discussing the need for IPv6. If you are reading this blog, you are already well aware that we network types are quickly running out of free IPv4 addresses, and that in an increasingly connected world, we need to implement a new Layer-3 protocol in order to connect all of our devices to the public Internet. Good enough? ;) Good. Let's proceed with a description of IPv6.

Basic Format of an IPv6 Address:
In IPv4, a valid IP address is a 32-bit number, broken down into four groups of 8-bit numbers -- that is, four groups of digits, each of which can be in the range 0-255. For example, 10.254.254.1 is a valid IP address, as is 172.16.0.4 and 192.168.131.75. Technically, any grouping of octets from 0.0.0.0 to 255.255.255.255 would be valid for IP addressing. However, in practice, parts of the address space have been reserved for special purposes, and therefore, 224.0.0.0 through 255.255.255.255 are not usable for addressing hosts.

Because one of the primary drivers for IPv6 is a lack of IPv4 address space, an IPv6 address is rather more complex. Where IPv4 addresses are 32 bits in length, an IPv6 address is 128 bits in length. Where IPv4 addresses are typically written in decimal notation, IPv6 addresses are written in hexidecimal. Additionally, where an IPv4 address is divided into four groups of 8 bits, separated by a period ("."), IPv6 addresses are subdivided into eight groups of 16-bits each, separated by a colon (":"). For example:
2001:4840:af21:0000:0000:2112:2358:0042
fe80:0000:0000:0000:baca:8ffe:fe42:f138

Because hexidecimal numbers contain alphabetic characters between "A" and "F," you will often see IPv6 addresses with...ummm...clever (?)...words enmbedded in the addresses:
2016:00c0:ffee:4a11:0000:0000:0000:0001
2001:dead:beef:cafe:0000:0000:0000:0128

...which helps with memorizing frequently used addresses. Even better, if an address contains a long sequence of zeroes, you can abbreviate the IPv6 address by replacing the sequence with two colons (":"):
2016:00c0:ffee:4a11::0001

Actually, even that can be shortened, because it isn't necessary to include all of the leading zeroes in each 16-bit string, like so:
2016:c0:ffee:4a11::1

Note: This only applies to LEADING zeroes, however, because trailing zeroes are placeholders, and therefore are required! Consequently, you cannot shorten "2016:c0:ffee:4a11::1" any further, as the zero in "2016" and "c0" must be present. One other catch: you can only truncate sequences of zeroes ONCE in an IPv6 address. For example, if you had the complete IPv6 address, "2001:0000:0042:0000:0000:0000:0000:af41," you would have to choose which sequence of zeroes to truncate. These would be acceptable:
2001::42:0000:0000:0000:0000:af41
2001:0000:42::af41

...but this would not:
2001::42::af41

That is because with either of the first two examples, you can still determine where within the 128 bits of address the "42" lies, but "2001::42::af41" could be any of the following addresses:
2001:0000:0042:0000:0000:0000:0000:af41
2001:0000:0000:0042:0000:0000:0000:af41
2001:0000:0000:0000:0042:0000:0000:af41
2001:0000:0000:0000:0000:0042:0000:af41

Note: Wait a minute! When you abbreviated the full IPv6 address as "2001:0000:42::af41,", you dropped the two leading zeroes ahead of the "42" in "0042," even though you replaced all of the zeroes after "42!"

Yes, but since you can only drop the leading zeroes in a 16-bit segment (i.e., "0042" can be abbreviated as "42," but "4200" cannot), we still know exactly where it belongs in the full, expanded IPv6 address.

Subnetting:
Just as in IPv4, IPv6 addresses can be subnetted. Just as 10.254.254.1/32 is a host address in IPv4, 2001::192:168:1:1/128 is a host address in IPv6. You can subdivide networks in IPv6 to optimize the number of networks and hosts in exactly the same way that you would in IPv4. However, it is important to remember that IPv6 uses hexadecimal numbers, so if you decide to "encapsulate" a common IPv4 address in IPv6 as I did above, don't make the mistake of assuming that, for example, 2001::192:168:1:9/126 and 2001::192.168.1.10/126 are contiguous host addresses within the same subnet. They aren't, as I discovered in a lab recently ;) Between ":9" and ":10" in an IPv6 address, you will find ":a" through ":f" -- which spans two /126 subnets, with ":10" being the network address (as opposed to a host address) for yet another subnet!

Putting it into practice!
Let's create a lab in GNS3 (or actual hardware, if you'd prefer) where we start connecting devices with IPv6. We'll start with a very simple network consisting of two routers. For this first lab, all we'll do is enable IPv6 on the routers, apply an IPv6 address to the connected interfaces, and make sure we can ping across the connection:



Now, we'll turn up the IPv6 addresses on these two routers:
R1(config)#ipv6 unicast-routing
R1(config)#int fa0/0
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address 2001:00c0:ffee:0000:0000:0000:0004:0001/126
R1(config-if)#no shut
R1(config-if)#exit
R1(config#exit

...and on R2:
R2(config)#ipv6 unicast-routing
R2(config)#int fa0/0
R2(config-if)#ipv6 enable
R2(config-if)#ipv6 address 2001:00c0:ffee:0000:0000:0000:0004:0002/126
R2(config-if)#no shut
R2(config-if)#exit
R2(config#exit

Can we ping?
R1#ping ipv6 2001:00c0:ffee:0000:0000:0000:0004:0002

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::4:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/19/36 ms
R1#

How about from R2?
R2#ping ipv6 2001:00c0:ffee:0000:0000:0000:0004:0001

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::4:1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/12 ms
R2#

Perfect! We have met the objectives of this lab, so we'll call it a day.

IPv6 Intro: Address Format and Subnetting

A couple of years ago, I created a lab, Advanced Cisco Routing: Implementing OSPF in IPv6. I probably got the cart before the horse when I created that lab, since that was the only in this blog (so far) where we even discussed IPv6. Ideally, I should have given an intro to IPv6 addressing and networking before creating a lab where we implemented a routing protocol in IPv6. Today, I'd like to fix that problem. Let's start with a basic introduction to IPv6, from the beginning.

I won't spend a lot of time discussing the need for IPv6. If you are reading this blog, you are already well aware that we network types are quickly running out of free IPv4 addresses, and that in an increasingly connected world, we need to implement a new Layer-3 protocol in order to connect all of our devices to the public Internet. Good enough? ;) Good. Let's proceed with a description of IPv6.

Basic Format of an IPv6 Address:
In IPv4, a valid IP address is a 32-bit number, broken down into four groups of 8-bit numbers -- that is, four groups of digits, each of which can be in the range 0-255. For example, 10.254.254.1 is a valid IP address, as is 172.16.0.4 and 192.168.131.75. Technically, any grouping of octets from 0.0.0.0 to 255.255.255.255 would be valid for IP addressing. However, in practice, parts of the address space have been reserved for special purposes, and therefore, 224.0.0.0 through 255.255.255.255 are not usable for addressing hosts.

Because one of the primary drivers for IPv6 is a lack of IPv4 address space, an IPv6 address is rather more complex. Where IPv4 addresses are 32 bits in length, an IPv6 address is 128 bits in length. Where IPv4 addresses are typically written in decimal notation, IPv6 addresses are written in hexidecimal. Additionally, where an IPv4 address is divided into four groups of 8 bits, separated by a period ("."), IPv6 addresses are subdivided into eight groups of 16-bits each, separated by a colon (":"). For example:
2001:4840:af21:0000:0000:2112:2358:0042
fe80:0000:0000:0000:baca:8ffe:fe42:f138

Because hexidecimal numbers contain alphabetic characters between "A" and "F," you will often see IPv6 addresses with...ummm...clever (?)...words enmbedded in the addresses:
2016:00c0:ffee:4a11:0000:0000:0000:0001
2001:dead:beef:cafe:0000:0000:0000:0128

...which helps with memorizing frequently used addresses. Even better, if an address contains a long sequence of zeroes, you can abbreviate the IPv6 address by replacing the sequence with two colons (":"):
2016:00c0:ffee:4a11::0001

Actually, even that can be shortened, because it isn't necessary to include all of the leading zeroes in each 16-bit string, like so:
2016:c0:ffee:4a11::1

Note: This only applies to LEADING zeroes, however, because trailing zeroes are placeholders, and therefore are required! Consequently, you cannot shorten "2016:c0:ffee:4a11::1" any further, as the zero in "2016" and "c0" must be present. One other catch: you can only truncate sequences of zeroes ONCE in an IPv6 address. For example, if you had the complete IPv6 address, "2001:0000:0042:0000:0000:0000:0000:af41," you would have to choose which sequence of zeroes to truncate. These would be acceptable:
2001::42:0000:0000:0000:0000:af41
2001:0000:42::af41

...but this would not:
2001::42::af41

That is because with either of the first two examples, you can still determine where within the 128 bits of address the "42" lies, but "2001::42::af41" could be any of the following addresses:
2001:0000:0042:0000:0000:0000:0000:af41
2001:0000:0000:0042:0000:0000:0000:af41
2001:0000:0000:0000:0042:0000:0000:af41
2001:0000:0000:0000:0000:0042:0000:af41

Note: Wait a minute! When you abbreviated the full IPv6 address as "2001:0000:42::af41,", you dropped the two leading zeroes ahead of the "42" in "0042," even though you replaced all of the zeroes after "42!"

Yes, but since you can only drop the leading zeroes in a 16-bit segment (i.e., "0042" can be abbreviated as "42," but "4200" cannot), we still know exactly where it belongs in the full, expanded IPv6 address.
Subnetting:
Just as in IPv4, IPv6 addresses can be subnetted. Just as 10.254.254.1/32 is a host address in IPv4, 2001::192:168:1:1/128 is a host address in IPv6. You can subdivide networks in IPv6 to optimize the number of networks and hosts in exactly the same way that you would in IPv4. However, it is important to remember that IPv6 uses hexadecimal numbers, so if you decide to "encapsulate" a common IPv4 address in IPv6 as I did above, don't make the mistake of assuming that, for example, 2001::192:168:1:9/126 and 2001::192.168.1.10/126 are contiguous host addresses within the same subnet. They aren't, as I discovered in a lab recently ;) Between "::9" and "::10" in an IPv6 address, you will find "::a" through "::f" -- which spans two /126 subnets, with "::10" being the network address for a third!

Putting it into practice!
Let's create a lab in GNS3 (or actual hardware, if you'd prefer) where we start connecting devices with IPv6. We'll start with a very simple network consisting of two routers. For this first lab, all we'll do is enable IPv6 on the routers, apply an IPv6 address to the connected interfaces, and make sure we can ping across the connection:



Now, we'll turn up the IPv6 addresses on these two routers:
R1(config)#ipv6 unicast-routing
R1(config)#int fa0/0
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address 2001:00c0:ffee:0000:0000:0000:0004:0001/126
R1(config-if)#no shut
R1(config-if)#exit
R1(config#exit

...and on R2:
R2(config)#ipv6 unicast-routing
R2(config)#int fa0/0
R2(config-if)#ipv6 enable
R2(config-if)#ipv6 address 2001:00c0:ffee:0000:0000:0000:0004:0002/126
R2(config-if)#no shut
R2(config-if)#exit
R2(config#exit
>
Can we ping?
R1#ping ipv6 2001:00c0:ffee:0000:0000:0000:0004:0002

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::4:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/19/36 ms
R1#

How about from R2?
R2#ping ipv6 2001:00c0:ffee:0000:0000:0000:0004:0001

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::4:1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/12 ms
R2#

Perfect! We have met the objectives of this lab, so we'll call it a day.

Cisco Advanced Routing Lab: Redistribution, Default Routes, and Virtual Tunnels

Today, I felt like challenging myself a little bit, so I created a large, somewhat complex network in GNS3 to try putting several concepts together into one, cohesive network. As usual, we'll start with the network diagram:



R1, R2, R3 and R4 are the network core. These routers all live in Area 0 (in the center of the diagram). R1 also participates in Area 1 and shares routes via BGP with R5. R5 participates in an entirely separate OSPF domain with R6 (my idea was that R5 and R6 would be "Internet" hosts for this lab). Just like R1, R2 also participates in Area 1, providing a redundant link to this area. R3 participates in OSPF area 3 and is one of the endpoints for the virtual tunnel to Area 4. R4 also belongs to Area 2. R7, 8 and 9 are pretty straightforward, existing only in Area 1. Likewise, R10 and R11 only live in Area 2; there's nothing complex about their configurations, either. R12, however, is the boundary between Area 2 and the RIP network including R13. R14 and R15 are routers belonging to Area 3, but R16 is a little more tricky. R16 participates in both Area 3 and Area 4.

However, OSPF requires ALL OSPF areas connect to the backbone (area 0) by at least one router. If you notice, there is no direct link between Area 4 and Area 0 in this network diagram, so in order to have Area 4 share routes with the rest of the network, you need to create a "virtual link" between R16 and R3. If ever you find yourself with an OSPF area that doesn't connect to the backbone, it might be worth rethinking your network design so that all of your areas do connect to Area 0. Speaking in broad generalities, there's usually something flawed with your design if you can't connect various OSPF areas directly to the backbone, but if for some reason you can't, it's pretty easy to connect R16 and R3 via a virtual tunnel. First, on R3:
R3(config)#router ospf 42
R3(config-router)#area 0.0.0.3 virtual-link 10.254.254.16


...and on R16:
R16(config)#router ospf 42
R16(config-router)#area 0.0.0.3 virtual-link 10.254.254.3


That's it! There are several options -- such as the various timers -- that you can adjust to account for various network performance issues across the virtual tunnel, but that's essentially all there is to creating the tunnel. Inside the OSPF config on each tunnel endpoint, you list the area ID of the OSPF area that the tunnel will be transiting, and you give the IP address of the other router's OSPF router-ID. In this network, I am using 10.254.254.<router number> for the loopback0 IP address, so R3 is 10.254.254.3 and R16 is 10.254.254.16.

The next "interesting" feature of this lab is the redistribution between OSPF Area 2 and the RIP network on R12. On R13, I created several 172.16.x.y networks on loopback interfaces...:
R13#sho ip int brie
Interface         IP-Address    OK? Method Status...
FastEthernet0/0   unassigned    YES unset  admin...
FastEthernet1/0   10.128.12.2   YES manual up ...
FastEthernet2/0   unassigned    YES unset  admin...
FastEthernet3/0   unassigned    YES unset  admin...
Loopback0         10.254.254.13 YES manual up...
Loopback1         172.16.1.1    YES manual up...
Loopback2         172.16.2.1    YES manual up...
Loopback3         172.17.1.1    YES manual up...
Loopback4         172.17.3.1    YES manual up...

RIPv1 is classful, while we are using classless routing, so the first thing to do is make sure that we are using RIPv2 on both R12 and R13:
R12(config)#router rip
R12(config-router)#version 2

Next, on R12, I want to tell RIP to redistribute OSPF routes, but to add a metric that is sufficiently large that R12 and R13 will prefer local routes to routes that have been imported from OSPF:
R12(config-router)#redistribute ospf 42 metric 3

Since RIP, being a distance-vector protocol, uses hop count as a metric (with a maximum of 15 hops), we start routes imported from OSPF with a hop count of 3 (the "42" is the OSPF process ID I used in the lab -- "router ospf 42"). Now, we'll do the same thing with OSPF:
R12(config-router)#router ospf 42
R12(config-router)#redistribute rip metric 50000 subnets

Again, we are setting the OSPF metric for routes important from RIP to an arbitrarily large value, so that OSPF will prefer local routes to imported routes; the exact value may require some tweaking on your network. I am also using the "subnets" option to tell OSPF to import just the specific subnets that RIP is advertising. Otherwise, any subnets from Class A IP space will be imported as /8 networks; any subnets from Class B IP space will be imported as /16 subnets; and any subnets from Class C IP space will be imported as /24 subnets (in other words, the two 172.16.x.y/24 subnets on R13 would be imported as a single 172.16.0.0/16, the two 172.16.x.y/24 subnets would be imported as a single 172.17.0.0/16, and the 10.254.254.13/32 subnet would be imported as 10.0.0.0/8 -- not at all what we wanted!).

On R1, we are advertising all of the subnets hosted in all of the OSPF areas as well as the RIP network to R5 via BGP:
router bgp 2358
no synchronization
bgp router-id 100.64.0.2
bgp log-neighbor-changes
network 10.0.0.4 mask 255.255.255.252
network 10.0.0.8 mask 255.255.255.252
network 10.0.1.4 mask 255.255.255.252
... network 172.16.0.0
network 172.17.0.0
network 192.168.9.0
neighbor 100.64.0.1 remote-as 2112
no auto-summary
!
It would also be possible to simply import OSPF into BGP, rather than list all of the subnets individually. However, this raises an interesting point: how do you import the routes that R5 is sharing via BGP into the network? The whole point of BGP is to share extremely large routing tables between routers. You don't want to import the entire Internet's routing tables into OSPF, so what is the best way to share external routes with the other routers in your internal network?

In this case, I used a simple, one-line statement to have the other routers send traffic destined for external networks to R1:
R1(config)#router ospf 42
R1(config-router)#default-information originate always
Since R5 is sharing its routes with R1, R1 knows how to reach the external subnets. By adding the "default-information originate" command to R1's OSPF config, it is essentially telling the other routers within the network that is the default gateway -- that traffic destined for unknown networks should be sent to it. R5 has the exact same statement in its OSPF config, so that R6 can reach the networks R5 has received via BGP.

Advanced Cisco Routing: Summary Addresses

So this probably isn't really an advanced routing topic, but it's not something I ran into while working on my CCNA, either...

Anyway.

Consider the following network:


On the left, we have our server farm (okay, it's a rather small data center). On the right, we have our desktop users (see previous comment, lol). Because we actually engineer our network, we have divided our network up into logical units, each on its own subnet. R2, R3 and R4 are department routers, each hosting a subnet -- say, 192.168.2.0/24 for R2, 192.168.3.0/24 for R3 and 192.168.4.0/24 for R4. R5 is the data center router, and all of the hosts in the data center are on the 172.16.0.0/24 subnet. R1 is our dist router, and uses 192.168.1.x/30 for each of its links to R2, R3 and R4, as well as using 10.0.0.0/30 for the link to R5. IRL, we should probably be using another 192.168.1.x/30 subnet for the R1 -- R5 link, but I'm actually treating R5 as both an edge and dist router here. I've enabled EIGRP on all five routers.

By default, EIGRP will try to summarize all of the routes by class; i.e., networks from 0.0.0.0 to 127.255.255.255 will be Class-A networks, networks from 128.0.0.0 through 191.255.255.255 will be Class-B networks, and networks from 192.0.0.0 through 223.255.255.255 will be Class-C network, no matter how you've actually subnetted them.

Modern best-practice, however, is not to do that, as free IPv4 address space is becoming increasingly rare, and therefore, you tend to see Class-A, Class-B and even Class-C networks subnetted into smaller blocks of IP space, as we've done on R5's LAN, on the link between R1 and R5, and on each of the links between R1 and R2, R3 and R4 here. Consequently, when using EIGRP in modern production networks, you will typically see the command "no auto-summary" somewhere in the EIGRP configuration.

However, on a large production network, this can be really ugly, as you see /30 network after /30 network listed in the "sho ip route" ouptut:
R5#sho ip route
<...snip...>
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.0.0 is directly connected, Vlan10
D EX 192.168.4.0/24 [170/30976] via 10.0.0.1, 00:00:04, FastEthernet1/0
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D EX 10.254.254.2/32 [170/158720] via 10.0.0.1, 00:00:04, FastEthernet1/0
D EX 10.254.254.3/32 [170/158720] via 10.0.0.1, 00:00:04, FastEthernet1/0
C 10.0.0.0/30 is directly connected, FastEthernet1/0
D EX 10.254.254.1/32 [170/156160] via 10.0.0.1, 00:00:04, FastEthernet1/0
D EX 10.254.254.4/32 [170/158720] via 10.0.0.1, 00:00:04, FastEthernet1/0
C 10.254.254.5/32 is directly connected, Loopback0
192.168.1.0/30 is subnetted, 3 subnets
D 192.168.1.8 [90/30720] via 10.0.0.1, 00:00:04, FastEthernet1/0
D 192.168.1.0 [90/30720] via 10.0.0.1, 00:00:04, FastEthernet1/0
D 192.168.1.4 [90/30720] via 10.0.0.1, 00:00:04, FastEthernet1/0
D EX 192.168.2.0/24 [170/30976] via 10.0.0.1, 00:00:04, FastEthernet1/0
D EX 192.168.3.0/24 [170/30976] via 10.0.0.1, 00:00:04, FastEthernet1/0
R5#

Notice that there are six 192.168.x.x subnets shown in the output of the "sho ip route" command on this router, and this is a SMALL network, so imagine how it would look on the service-provider network where I work! Not only does it make it more difficult to parse the output of the "sho ip route" command, but EIGRP on R1 has to advertise each of these networks separately to R5, making the update larger than it has to be.

Fortunately, this isn't an all-or-nothing choice. It is possible to have EIGRP summarize some routes, but advertise individual subnets for others. Furthermore, you don't have to summarize into a classful network -- you can use any valid IP subnet to summarize the routes. In the example network shown in this lab, we have 192.168.1.0/30, 192.168.1.4/30, 192.168.1.8/30, 192.168.2.0/24, 192.168.3.0/24 and 192.168.4.0/24 in use. The smallest valid subnet that contains all of these networks would be 192.168.0.0/21 (192.168.0.0 -- 192.168.7.255). If we assume that that IP space is reserved for use by R1 and edge routers hanging off of R1, then we can have R1 summarize the 192.168.x.x subnets into one single route advertisement for this entire range:
R1(config)#int fa0/0
R1(config-if)#ip summary-address eigrp 10 192.168.0.0 255.255.248.0
R1(config-if)#
01:44:20: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.0.0.2 (FastEthernet0/0) is down: summary configured
R1(config-if)#
01:44:23: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.0.0.2 (FastEthernet0/0) is up: new adjacency
R1(config-if)#

Now, if we look at the routes on R5, we will see that, rather than advertising six 192.168.x.x subnets, R1 is only advertising a single /21 that contains each of the previous six subnets:
R5#sho ip route
<...snip...>
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.0.0 is directly connected, Vlan10
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D EX 10.254.254.2/32 [170/158720] via 10.0.0.1, 00:03:55, FastEthernet1/0
D EX 10.254.254.3/32 [170/158720] via 10.0.0.1, 00:03:55, FastEthernet1/0
C 10.0.0.0/30 is directly connected, FastEthernet1/0
D EX 10.254.254.1/32 [170/156160] via 10.0.0.1, 00:03:56, FastEthernet1/0
D EX 10.254.254.4/32 [170/158720] via 10.0.0.1, 00:03:55, FastEthernet1/0
C 10.254.254.5/32 is directly connected, Loopback0
D 192.168.0.0/21 [90/30720] via 10.0.0.1, 00:03:55, FastEthernet1/0  <---
R5#

Cool!