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!

Cisco Intro to QoS and CoS, Part 4 -- Shape Average vs. Bandwidth in Policy Maps

If you've poked around at all with the policy-map statement, you've probably noticed that there are several options for configuring how much bandwidth to allocate to different classes within the QoS config. Let's look at two of the options, shape average and bandwidth.

We'll use the following network...:


...and the following configuration:
ip access-list extended PRIORITY-IN
 permit ip 192.168.1.0 0.0.0.255 any
 permit ip any 192.168.1.0 0.0.0.255
 deny ip any any
ip access-list extended SCAVENGER-IN
 permit ip 192.168.2.0 0.0.0.255 any
 permit ip any 192.168.2.0 0.0.0.255
 deny ip any any
!
class-map match-any PRIORITY
 match dscp af41
class-map match-any SCAVENGER
 match dscp cs1
!
class-map match-any PRIORITY-IN
 match access-group name PRIORITY-IN
class-map match-any SCAVENGER-IN
 match access-group name SCAVENGER-IN
!
policy-map REMARK_ALL
 class PRIORITY-IN
  set dscp af41
 class SCAVENGER-IN
  set dscp cs1
policy-map EGRESS-SHAPER
 class PRIORITY
  shape average percent 70
 class SCAVENGER
  shape average percent 5
policy-map EGRESS-BANDWIDTH
 class PRIORITY
  bandwidth percent 70
 class SCAVENGER
  bandwidth percent 5
!

For my first test, I set up the policy-map, "EGRESS-SHAPER," on interface eth3/0 on both routers, and set up the "REMARK_ALL" service policy on the ingress interfaces (fa0/0 on both routers, and fa1/0 on R1):
interface FastEthernet0/0
 service-policy input REMARK_ALL
!
interface FastEthernet1/0
 service-policy input REMARK_ALL
!
interface Ethernet3/0
 service-policy output EGRESS-SHAPER
!

Then, I set up iperf as a service on host "Knoppix" and ran iperf as a client on both Knoppix Clones, using the flags "-i 1 -t 120," finding that Knoppix Clone 1 could send data at a little over 5Mbps, and Knoppix Clone 2 sent data at about 500Kbps. I then re-ran the test using the service policy "EGRESS-BANDWIDTH," where I saw a transfer speed of just over 4Mbps for Knoppix Clone 1 and about 1 1/3Mbps for Knoppix Clone 2. That surprised me; I didn't really understand why my bandwidth decreased in class PRIORITY (Knoppix Clone 1) and increased in class SCAVENGER (Knoppix Clone 2). To understand what was happening, I did some more tests, using both TCP and UDP transfers ("-u -b 10M" for the flags to set a UDP test at up to 10Mbps), and with both hosts in contention for bandwidth as well as with the hosts transferring data one at a time (i.e., run iperf on Knoppix Host 1, and then running it on Knoppix Clone 2 after the test completed on Knoppix Clone 1). Here are the results from all of the tests:

Congested:
  TCP:
    Using EGRESS-SHAPER:
      192.168.1.x: 5.15Mbps
      192.168.2.x: 0.48Mbps

    Using EGRESS-BANDWIDTH:
      192.168.1.x: 4.16Mbps
      192.168.2.x: 1.36Mbps


  UDP:
    Using EGRESS-SHAPER:
      192.168.1.x: 3.07Mbps
      192.168.2.x: 0.16Mbps

    Using EGRESS-BANDWIDTH:
      192.168.1.x: 2.8Mbps
      192.168.2.x: 1.26Mbps


Uncongested:
  TCP:
    Using EGRESS-SHAPER:
      192.168.1.x: 5.76Mbps
      192.168.2.x: 0.50Mbps

    Using EGRESS-BANDWIDTH:
      192.168.1.x: 5.52Mbps
      192.168.2.x: 5.51Mbps

  UDP:
    Using EGRESS-SHAPER:
      192.168.1.x: 5.82Mbps
      192.168.2.x: 0.47Mbps

    Using EGRESS-BANDWIDTH:
      192.168.1.x: 6.03Mbps
      192.168.2.x: 6.14Mbps

What's happening here is that "shape average" tells the router to strictly allocate the specified amount of bandwidth to the various traffic classes. Even if more bandwidth is available through the interface, the allocated bandwidth is all that the traffic class will receive. When using the "bandwidth" statement, however, the router will allow the traffic classes to use all of the available bandwidth. Since class PRIORITY takes, well, priority over class SCAVENGER, when there is traffic in both traffic classes, class SCAVENGER will only receive the allocated bandwidth. However, when there is little or no priority traffic on the interface, the router will allow class SCAVENGER to "borrow" bandwidth from the other traffic classes in the service policy (in this case, class PRIORITY). Consequently, when there was no contention for bandwidth, class SCAVENGER can get the full data rate on the interface*.

*Q: Wait a minute! An Ethernet port runs at 10Mbps, but these results are showing about 6Mbps. What happened to the other 4Mbps?
A: Keep in mind that an Ethernet port runs at half duplex, meaning that the same copper wire is used for both transmit and receive. Therefore, the 10Mbps bandwidth available on the Ethernet port has to be shared between transmit and receive.**

**Q: Okay, so that explains why it's not 10Mbps, but in that case, shouldn't the data rate be lower, like 5Mbps?
A: If both sides were transmitting data at line rate, then yes. However, in this case the flow of data is mostly one-sided, especially with the UDP traffic, where there is no ACK being sent back to the two Knoppix Clones.***

***Q: In that case, should the data rate be higher?
A: The devil is in the details, and there are a lot of details to consider ;) "Customer" data isn't all that is flowing between R1 and R2. R1 and R2 are also sending their own data back and forth, for example, OSPF updates, CDP updates, etc. Consequently, while the flow of data between R1 and R2 is mostly one-sided, it's not completely one sided. If you REALLY want a good understanding of what's happening, replace R2 with the Knoppix host and run wireshark to capture the packets during a test. I'll leave that as an exercise for the reader ;)

Cisco Intro to QoS and CoS, Part 3 -- Classifying Traffic with NBAR

In our QoS labs so far, we've had to find some way to identify traffic, usually by creating an ACL to match packets against some criteria, such as source/destination port, source/destination IP address, or protocol (TCP/UDP/ICMP), etc. However, Cisco offers another way to match traffic: NBAR, or "Network Based Application Recognition. I created the following network in GNS3 to start playing with NBAR:

To enable NBAR on a router, you first need to turn on CEF, and then you need to enable NBAR on any interface that will have a service policy to mark and classify traffic. In this network, I am using an NM-16ESW switchport module in slot 0, so while Fa0/0 is technically the ingress port, I would enable NBAR on my VLAN interface (int VLAN10). If you are using a plain FastEthernet port rather than a switch module, then you would enable NBAR on the Fa port. In either case, here is how to do it:
R4(config)#ip cef
R4(config)#int vlan 10
R4(config-if)#ip nbar protocol-discovery

After enabling NBAR, we'll need to design our QoS schema. Let's start by identifying the types of traffic on our network, and by deciding what traffic will take priority over other traffic. I came up with the following (admittedly hokey) schema, ordered by priority:

1. EIGRP
2. HTTP (simulating voice/video with a streaming mp4 file)
3. Telnet
4. SNMP
5. SSH
6. ICMP

I then mapped this traffic to the following traffic classes:

Traffic	DSCP Value
EIGRP	CS6
HTTP	EF
Telnet	AF41
SNMP	CS3
SSH	AF21
ICMP	CS2

Cool! Let's start configuring the class-maps on R4, R5 and R6:
R4(config)#class-map match-all EIGRP
R4(config-cmap)#match protocol eigrp
R4(config-cmap)#class-map match-all HTTP
R4(config-cmap)# match protocol http
R4(config-cmap)#class-map match-all SSH
R4(config-cmap)# match protocol ssh
R4(config-cmap)#class-map match-all TELNET
R4(config-cmap)# match protocol telnet
R4(config-cmap)#class-map match-all SNMP
R4(config-cmap)# match protocol snmp
R4(config-cmap)#class-map match-all ICMP
R4(config-cmap)#match protocol icmp

...and now, the policy-map to use these classes:
R4(config-cmap)#policy-map REMARK_ALL
R4(config-pmap)#description policy-map to place traffic into the appropriate traffic class
R4(config-pmap)# class EIGRP
R4(config-pmap-c)# set ip dscp cs6
R4(config-pmap-c)# class HTTP
R4(config-pmap-c)# set ip dscp ef
R4(config-pmap-c)# class SSH
R4(config-pmap-c)# set ip dscp af21
R4(config-pmap-c)# class TELNET
R4(config-pmap-c)# set ip dscp af41
R4(config-pmap-c)# class SNMP
R4(config-pmap-c)# set ip dscp cs3
R4(config-pmap-c)# class ICMP
R4(config-pmap-c)# set ip dscp cs2

Now, just enable the policy map in your ingress interface (VLAN10 in this lab), and you are done:
R4(config-if)#int vlan10
R4(config-if)# service-policy input REMARK_ALL

Pretty easy, huh? To utilize NBAR to identify traffic from various protocols, all you have to do is use the "match protocol <protocol>" statement inside a class-map and NBAR will identify the traffic for you! Keep in mind, however, that NBAR is deep-packet inspection -- it isn't just a simple match for port number and IP address -- and therefore, this functionality comes at a cost of CPU cycles (unless you are using a more recent model switch/router that off-loads the packet inspection to a separate processor). Consequently, if a simple ACL will meet your needs, it MAY be less resource intensive to use the ACL, as we've done in earlier labs. However, if you have a higher-powered router, NBAR certainly makes identifying and classifying traffic much easier on the network admin.

Note:
This is just a really simple example of NBAR, and doesn't even begin to scratch the surface of what NBAR can do for you. For example, when matching the HTTP protocol, you can create multiple classes based upon the host in the HTTP request and you can even use a regex to pattern-match within the URL. You can also extend NBAR with external files to add support for protocols that are not already built in.

For the sake of completeness, here is the rest of the QoS configuration on R4: R4(config)#class-map match-any PRIORITY
R4(config-cmap)# match ip dscp ef
R4(config-cmap)#class-map match-any CONTROL
R4(config-cmap)# match ip dscp cs6
R4(config-cmap)#class-map match-any CRITICAL
R4(config-cmap)# match ip dscp af41
R4(config-cmap)# match ip dscp cs3
R4(config-cmap)#class-map match-any ROUTINE
R4(config-cmap)# match ip dscp cs2
R4(config-cmap)# match ip dscp af21
R4(config-cmap)#class-map match-any SCAVENGER
R4(config-cmap)# match ip dscp CS1
R4(config)#policy-map EDGE_CHILD
R4(config-pmap)# description Core links
R4(config-pmap)# class PRIORITY
R4(config-pmap-c)# priority percent 25
R4(config-pmap-c)# class CONTROL
R4(config-pmap-c)# bandwidth percent 10
R4(config-pmap-c)# class CRITICAL
R4(config-pmap-c)# bandwidth percent 15
R4(config-pmap-c)# random-detect dscp-based
R4(config-pmap-c)# class ROUTINE
R4(config-pmap-c)# bandwidth percent 10
R4(config-pmap-c)# random-detect dscp-based
R4(config-pmap-c)# class SCAVENGER
R4(config-pmap-c)# bandwidth percent 1
R4(config-pmap-c)# random-detect dscp-based
R4(config-pmap-c)# class class-default
R4(config-pmap-c)# fair-queue
R4(config-pmap-c)# random-detect dscp-based
R4(config-pmap-c)#!
R4(config-pmap-c)#policy-map EDGE2CORE
R4(config-pmap)# description Parent policy for Edge-to-Core links
R4(config-pmap)# class class-default
R4(config-pmap-c)# shape average 10000000
R4(config-pmap-c)# service-policy EDGE_CHILD
R4(config-pmap-c)#!
R4(config-if)#int fa1/0
R4(config-if)# service-policy output EDGE2CORE
R4(config-if)#!
R4(config-if)#int fa3/0
R4(config-if)# service-policy output EDGE2CORE
R4(config-if)#!