IPv6 Intro: Routing with OSPFv3 for IPv6

Continuing on with our last lab, let's remove the RIPng config, and set up OSPFv3, instead. Here's the network diagram again, just so you don't have to jump back to the RIPng lab again:



Just like configuring RIPng, we will start by enabling IPv6 OSPF in the interface configurations. Once again, only R1 is shown, but the other routers are configured in exactly the same way:
R1(config)#int fa0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.0
R1(config-if)#int s0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.1
R1(config-if)#exit
R1(config)#do sho ipv6 route
IPv6 Routing Table - 8 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
LC  2001:C0:FFEE::1/128 [0/0]
     via ::, Loopback0
C   2001:C0:FFEE::1:0/125 [0/0]
     via ::, FastEthernet0/0
L   2001:C0:FFEE::1:1/128 [0/0]
     via ::, FastEthernet0/0
C   2001:C0:FFEE::1111:0/126 [0/0]
     via ::, Serial0/0
L   2001:C0:FFEE::1111:1/128 [0/0]
     via ::, Serial0/0
OI  2001:C0:FFEE::2222:0/126 [110/65]
     via FE80::CA03:3CFF:FEAE:0, FastEthernet0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
R1(config)#

If this looks very familiar from the RIPng lab, it should. Any guesses on how to configure redistribution of connected networks?
R1(config)#ipv6 router ospf 42
R1(config-rtr)#router-id 10.254.254.1
R1(config-rtr)#redist conn
R1(config-rtr)#exit
R1(config)#

At this point, you might be scratching your head, wondering WHY I used an IPv4 address for the router ID. Actually...I didn't. The RFC for OSPF specifies that the router ID is a 32-bit, unique (at least within the AS) identifier. Since IPv4 addresses are ALSO 32-bit, unique identifiers, convention (and, unless a different router ID is specified in the config, Cisco's default behaviour) has set the loopback interface's IPv4 address as the router ID. I also chose to set an IPv4 address on the loopback interface, and I used it as the router ID in this lab. However, technically the OSPFv3 router ID is any random 32-bit number (see the footnote at the end of this lab for more).

After setting up redistribution, the routing table on R1 looks a little more populated:
R1(config)#do sho ipv6 route
IPv6 Routing Table - 12 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
LC  2001:C0:FFEE::1/128 [0/0]
     via ::, Loopback0
OE2  2001:C0:FFEE::2/128 [110/20]
     via FE80::CA03:3CFF:FEAE:0, FastEthernet0/0
OE2  2001:C0:FFEE::3/128 [110/20]
     via FE80::CA04:3CFF:FEAE:0, FastEthernet0/0
OE2  2001:C0:FFEE::4/128 [110/20]
     via FE80::CA00:3CFF:FEAE:0, Serial0/0
OE2  2001:C0:FFEE::5/128 [110/20]
     via FE80::CA03:3CFF:FEAE:0, FastEthernet0/0
C   2001:C0:FFEE::1:0/125 [0/0]
     via ::, FastEthernet0/0
L   2001:C0:FFEE::1:1/128 [0/0]
     via ::, FastEthernet0/0
C   2001:C0:FFEE::1111:0/126 [0/0]
     via ::, Serial0/0
L   2001:C0:FFEE::1111:1/128 [0/0]
     via ::, Serial0/0
OI  2001:C0:FFEE::2222:0/126 [110/65]
     via FE80::CA03:3CFF:FEAE:0, FastEthernet0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
R1(config)#

There you go: we have a basic OSPFv3 (IPv6) configuration, sharing routes between each of the five routers in our network. We even set up three separate areas: the backbone, consisting of R1, R2 and R3; Area 1, consisting of R1 and R4; and Area 2, consisting of R2 and R5.

Footnote:
At this point, you may be wondering -- well, I am, anyway -- what OSPFv3 uses for a router ID if there are no IPv4 interfaces in use on the router, and there is no router ID specified in the OSPFv3 config. Let's find out, shall we?
R1(config)#int lo0
R1(config-if)#no ip addr
R1(config-if)#shut
R1(config-if)#no shut
R1(config-if)#no ipv6 router ospf 42
R1(config)#int fa0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.0
R1(config-if)#int s0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.1
R1(config-if)#exit
R1(config-if)#ipv6 router ospf 42
R1(config-rtr)# redistribute connected
R1(config-rtr)#exit
R1(config)#exit
R1#
00:36:49: %OSPFv3-4-NORTRID: OSPFv3 process 42 could not pick a router-id,
please configure manually
R1#sho ipv6 ospf neigh
%OSPFv3: Router process 42 is not running, please configure a router-id
R1#

Well, that's interesting! What happens if you don't have an IPv4 address on the loopback interface, but you have an IPv4 address on another interface?
R1(config-if)#int vlan 10
R1(config-if)#ip addr 10.254.254.1 255.255.255.252
R1(config-if)#no shut
R1(config-if)#no ipv6 router ospf 42
R1(config)#ipv6 router ospf 42
R1(config-rtr)#redist conn
R1(config-rtr)#exit
R1(config)#int fa0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.0
R1(config-if)#int s0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.1
R1(config-if)#exit
R1(config)#exit
R1#sho ipv6 ospf 42 neigh

Neighbor ID    Pri  State      Dead Time  Interface ID  Interface
10.254.254.2     1  FULL/BDR   00:00:39   4             FastEthernet0/0
10.254.254.3     1  FULL/DR    00:00:36   4             FastEthernet0/0
10.254.254.4     1  FULL/  -   00:00:38   5             Serial0/0
R1#

There you have it. If there is an IPv4 address configured anywhere on the router, OSPFv3 will use it for the router ID. If not, then you MUST configure a router ID in the OSPFv3 configuration.

Advanced Cisco Routing -- BGP and OSPF

If you wish to configure network gear for Service Provider networks, or even for Enterprise networks in large enough companies, you will eventually need to understand BGP. While I have worked for Service Providers for my entire professional career, I have never had the opportunity to work with BGP. However, due to some changes in my current work environment, I realized that I would need to come up to speed on BGP in the fairly near future, so I decided it was time to start playing with that particular routing protocol.

First, a little background. In my earlier Cisco and Juniper posts, we've discussed setting up and configuring OSPF, RIP, and EIGRP, so it might be reasonable to ask, what's so different about BGP? Without getting into too much detail, the bottom line is that the other routing protocols are designed for use within a single provider's network. You might have a lot of routers and a lot of routes, but the Internet's routing tables (for example) are much, much larger than your internal routing tables -- far too big, in fact, to fit on just about any router if you are using one of these protocols. BGP is the answer to this problem. It was designed to efficiently store and share very, very large routing tables on service provider networks. Consequently, you most often (but not exclusively!) see BGP on routers that are sharing publicly accessible routes on the Internet. It is important to note that BGP comes in two flavors: iBGP (internal BGP) that is used to share routes among your own networks, much like the routing protocols we have alread discussed; and eBGP (external BGP), which is used to share routes among other organizations. For this post, we will be discussing eBGP exclusively.

So, let's get started!

Here is the network that I created in GNS3:

Why GNS3 rather than a real hardware network? Well, first, I built this while at work (it was a slow day, and it is work-related learning), and second, because I have had to tear down my Cisco lab at home for reasons I'm sure you don't want to read about now :) Besides...I tried to get GNS3 to work a little while ago and failed, so I figured it was time to figure out how to make this puppy sing! It really wasn't all that difficult, but it did require some non-intuitive experimentation with settings until I got everything working.

Anyway, here's the description of the topology:

R1 and R2 are my core routers on this network -- they are the ones doing the BGP peering with each other. R1 is using AS64512 and R2 is using AS64513. Those AS numbers are not entirely random; they are, in fact, the first two private, reserved AS numbers according to the RFC's (think RFC-1918 for BGP autonomous system numbers, and you'll be pretty close). In GNS3, it doesn't really matter, but if you want to build BGP routers with real iron that might ever be connected to the Internet, you should probably use an AS number in the range 64512 - 65535 until/unless you get a real AS number from ARIN.

R3 and R4 are edge routers connected to R1; R5 and R6 are likewise edge routers connected to R2. R1, R3 and R4 make up the autonomous system in OSPF area 42. R2, R5 and R6 make up the autonomous system in OSPF area 51.

Finally, these are the networks connected to each router:

Router	Interface	IP Address	Subnet Mask	Description
R1	fa0/0	10.0.0.1	255.255.255.252	Uplink to R2
R1	fa1/0	192.168.1.1	255.255.255.0	Uplink to R3
R1	fa3/0	192.168.2.1	255.255.255.0	Uplink to R4
R2	fa0/0	10.0.0.2	255.255.255.252	Uplink to R1
R2	fa1/0	172.16.1.1	255.255.255.252	Uplink to R5
R2	fa2/0	172.16.20.1	255.255.255.252	Uplink to R6
R3	e0/0	192.168.10.1	255.255.255.0	LAN
R3	fa1/0	192.168.1.2	255.255.255.0	Uplink to R1
R4	e0/0	192.168.20.1	255.255.255.0	LAN
R4	fa1/0	192.168.2.2	255.255.255.0	Uplink to R1
R5	e0/0	172.16.10.1	255.255.255.0	LAN
R5	fa1/0	172.16.1.2	255.255.255.252	Uplink to R1
R6	e0/0	172.16.20.1	255.255.255.0	LAN
R6	fa1/0	172.16.2.2	255.255.255.252	Uplink to R1

I started by configuring OSPF on R1, R3 and R4:
R1#sho run | begin router ospf 42
router ospf 42
router-id 10.0.0.1
log-adjacency-changes
network 192.168.1.0 0.0.0.255 area 0
network 192.168.2.0 0.0.0.255 area 0
!

R3#sho run | begin router ospf 42
router ospf 42
router-id 192.168.10.1
log-adjacency-changes
redistribute connected subnets
network 192.168.1.0 0.0.0.255 area 0
!

R4#sho run | begin router ospf 42
router ospf 42
router-id 192.168.20.1
log-adjacency-changes
redistribute connected subnets
network 192.168.2.0 0.0.0.255 area 0
!

Once I had verified that I was routing between these three routers, I configured OSPF on R2, R5 and R6:
R2#sho run | begin ospf 51
router ospf 51
router-id 10.0.0.2
log-adjacency-changes
network 172.16.1.0 0.0.0.3 area 0
network 172.16.2.0 0.0.0.3 area 0
!

R5#sho run | begin ospf 51
router ospf 51
router-id 172.16.10.1
log-adjacency-changes
redistribute connected subnets
network 172.16.1.0 0.0.0.3 area 0
network 172.16.10.0 0.0.0.255 area 0
!

R6#sho run | begin router ospf 51
router ospf 51
router-id 172.16.20.1
log-adjacency-changes
redistribute connected subnets
network 172.16.2.0 0.0.0.3 area 0
network 172.16.20.0 0.0.0.255 area 0
!


...and checked to make sure that I had routing between these three routers, which I did.
Note: if any of this does not look familiar to you, I'd highly recommend you take a look at my blog entries on OSPF here and here to come up to speed on OSPF before digging into BGP.

Next, I configured the BGP routing process between R1 and R2:
R1#sho run | begin router bgp
router bgp 64512
bgp log-neighbor-changes
neighbor 10.0.0.2 remote-as 64513
address-family ipv4
neighbor 10.0.0.2 activate
no auto-summary
no synchronization
exit-address-family
!

R2#sho run | begin router bgp
router bgp 64513
bgp log-neighbor-changes
neighbor 10.0.0.1 remote-as 64512
address-family ipv4
neighbor 10.0.0.1 activate
no auto-summary
no synchronization
exit-address-family
!


First, note the AS numbers I mentioned earlier in the "router bgp..." command. In OSPF, we provide a process ID for the OSPF process; in BGP, we provide the AS number that we are advertising with BGP. We use those AS numbers on the very next line on the peer router to specify who we wish to be sharing routes with. Unlike OSPF, with BGP we specify the neighbor router(s) that we want to peer with. After that, we tell BGP what address family (IPv4, IPv6, etc.) that we will be advertising, and then we tell BGP to activate the peering session with our peer at <IP Address>. The rest of the lines were defaults automatically populated by IOS.

Unfortunately, at this point, I didn't see routes propagating between routers like I expected. After a little quality time with Google, I discovered that I hadn't told BGP what routes I wanted to share. Adding the line, "redistribute ospf 42 match internal external 1 external 2" on R1 and "redistribute ospf 51" on R2 solved that problem -- I was now able to see OSPF routes from the BGP peer showing up on R1 and R2.

Note: notice that R1 includes some extra syntax that R2 is missing on the "redistribute ospf..." statement. I don't have time right now to explain why that is necessary, but I'll try to add a post later to discuss what is different about the two networks.

However, all was not well in Mudville. When I got on the console for R6, I found that I could not ping R3 or R4. I ran "sho ip route" and found that, even though BGP had propagated routes from R1 onto R2 and vice versa, R2 hadn't shared those routes with R5 and R6, nor had R1 shared the routes learned through BGP with R3 and R4. That was because, even though I had told BGP to share OSPF routes (which it had), I hadn't told OSPF to share BGP routes! On R1, I added "redistribute bgp 64512 subnets" to the OSPF config, and on R2, I added "redistribute bgp 64513 subnets" which solved the problem. I could now ping any of the six routers from any of the five remaining routers.

Appendix B -- More Detail on OSPF

OSPF is a very, very deep subject, and my original post on the topic didn't even begin to do justice to the complexity and intricacy of OSPF. As I began preparing for the CCNA exam, I realized there were some fundamentals of OSPF that I didn't quite grasp, and so -- just as I did with Spanning Tree -- I powered up my Cisco lab and set to work trying to fill in some of the gaps in my knowledge.

Classful vs. Classless Routing: The first thing I wanted to understand was why I was getting the following error on my Cisco routers when I would run the "redistribute connected" command:

lab3640rtr#conf t
lab3640rtr(config)#router ospf 42
lab3640rtr(config-router)#redistribute connected
% Only classful networks will be redistributed
lab3640rtr(config-router)#


Ummm...what? I would understand that error on RIPv1, since it's a classful protocol, but why am I getting it in OSPF?!?! I tried adding the "ip classless" command in global config mode since maybe the router wasn't operating in classless mode, but that made no difference.

Apparently, this isn't just a nuisance message either, because my lab2651rtr router (the one with 192.168.1.0/24 divided into multiple /27 and /28 subnets), isn't propagating those 192.168.1.x routes to the other routers:

lab3640rtr#sho ip route
<...snip...>
Gateway of last resort is not set

     100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O IA    100.64.1.0/24 [110/128] via 192.168.3.5, 00:09:29, Serial0/1
O E2    100.64.1.22/32 [110/20] via 192.168.3.5, 00:09:29, Serial0/1
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O IA    10.254.254.0/30 [110/129] via 192.168.3.5, 00:09:29, Serial0/1
O E2    10.100.64.2/32 [110/20] via 192.168.3.5, 00:09:29, Serial0/1
O E2    10.100.64.1/32 [110/20] via 192.168.3.5, 00:09:29, Serial0/1
     192.168.3.0/30 is subnetted, 1 subnets
C       192.168.3.4 is directly connected, Serial0/1
lab3640rtr#


After poking around with OSPF configurations, and with the help of the friendly "?" character on the CLI ;) I managed to find an additional parameter on the "redistribute connected" command:

lab3640rtr(config-router)#no redistribute connected
lab3640rtr(config-router)#redistribute connected subnets
lab3640rtr(config-router)#


Hey, what do you know! No error message! I applied the command on my routers, then checked my routing tables:

lab3640rtr#sho ip route
<...snip...>
     100.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O E2    100.64.1.1/32 [110/20] via 192.168.3.5, 00:02:43, Serial0/1
O IA    100.64.1.0/24 [110/128] via 192.168.3.5, 00:02:43, Serial0/1
O E2    100.64.1.22/32 [110/20] via 192.168.3.5, 00:02:43, Serial0/1
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O IA    10.254.254.0/30 [110/129] via 192.168.3.5, 00:02:43, Serial0/1
O E2    10.100.64.2/32 [110/20] via 192.168.3.5, 00:02:43, Serial0/1
O E2    10.100.64.1/32 [110/20] via 192.168.3.5, 00:02:43, Serial0/1
     192.168.1.0/24 is variably subnetted, 7 subnets, 2 masks
O E2    192.168.1.96/28 [110/20] via 192.168.3.5, 00:02:43, Serial0/1
O E2    192.168.1.112/28 [110/20] via 192.168.3.5, 00:02:43, Serial0/1
O E2    192.168.1.64/28 [110/20] via 192.168.3.5, 00:02:43, Serial0/1
O E2    192.168.1.80/28 [110/20] via 192.168.3.5, 00:02:43, Serial0/1
O E2    192.168.1.32/27 [110/20] via 192.168.3.5, 00:02:43, Serial0/1
O E2    192.168.1.0/27 [110/20] via 192.168.3.5, 00:02:43, Serial0/1
O E2    192.168.1.128/27 [110/20] via 192.168.3.5, 00:02:43, Serial0/1
     192.168.3.0/30 is subnetted, 1 subnets
C       192.168.3.4 is directly connected, Serial0/1
lab3640rtr#


w00t! There are my subnets!

As an aside, there is also a "redistribute static subnets" as well, which I assume serves the same purpose.

Router ID's: One other concept I had difficulty with is how a router running OSPF automatically assigns a router ID. Conceptually, it is simple -- if the administrator doesn't statically assign a router ID, then the router ID is chosen from the IP addresses configured on the router. Unfortunately, between the multiple websites I visited, the numerous CCNA prep books I read, and the various practice tests I used to study, I got thoroughly confused as to which IP address the router will use as its router ID. I could always search for the most popular answer among my numerous resources, but...it's more fun (and it will stick with me better) if I actually test it on live equipment. To that end, I took my trusty 2651 router and one of the 3640 routers, configured OSPF, and left the router-id statement out of the config. Then, I mucked about with the various interfaces until I understood how the routers assign a router ID.

I started by removing all of the IP addresses from the lab3640rtr router, except for the serial interface connecting to the lab2651rtr (192.168.3.6/30), then ran the "sho ip ospf int" command:

lab3640rtr#sho run | inc address
no ip address
no ip address
ip address 192.168.3.6 255.255.255.252
lab3640rtr#sho ip ospf int
Serial0/1 is up, line protocol is up
  Internet Address 192.168.3.6/30, Area 3
  Process ID 42, Router ID 192.168.3.6, Network Type POINT_TO_POINT, Cost: 64
<...snip...>


No surprise, there. The router ID is the one IP address available on the router, 192.168.3.6. What happens if I put an IP address back on Fa0/0, but leave the interface shut down? Well, there's only one way to find out:

lab3640rtr#conf t
lab3640rtr(config)#int fa0/0
lab3640rtr(config-if)#ip address 192.168.2.1 255.255.255.0
lab3640rtr(config-if)#shut
lab3640rtr(config-if)#exit
lab3640rtr(config)#exit
lab3640rtr#sho ip ospf intSerial0/1 is up, line protocol is up
  Internet Address 192.168.3.6/30, Area 3
  Process ID 42, Router ID 192.168.3.6, Network Type POINT_TO_POINT, Cost: 64
<...snip...>


It's still using the address of the serial interface; not entirely unexpected. What if we enable Fa0/0?

lab3640rtr#conf t
lab3640rtr(config)#int fa0/0
lab3640rtr(config-if)#no shut
lab3640rtr(config-if)#exit
lab3640rtr(config)#exit
lab3640rtr#sho ip ospf int
Serial0/1 is up, line protocol is up
  Internet Address 192.168.3.6/30, Area 3
  Process ID 42, Router ID 192.168.3.6, Network Type POINT_TO_POINT, Cost: 64
<...snip...>


Still using the 192.168.3.6 address for the router ID. Is that just because Fa0/0 is not up (there's no device connected to it)? Let's connect an Ethernet cable to the 2924 switch and see what happens:

lab3640rtr#sho ip int brief | inc FastEthernet0/0
FastEthernet0/0            192.168.2.1     YES manual up                    down
lab3640rtr#sho ip int brief | inc FastEthernet0/0
00:25:13: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
lab3640rtr#sho ip int brief | inc FastEthernet0/0
FastEthernet0/0            192.168.2.1     YES manual up                    up
lab3640rtr#sho ip ospf int
Serial0/1 is up, line protocol is up
  Internet Address 192.168.3.6/30, Area 3
  Process ID 42, Router ID 192.168.3.6, Network Type POINT_TO_POINT, Cost: 64


Apparently not; 192.168.3.6 is still the router ID. Maybe it's because 192.168.2.0/24 is not in the OSPF configuration?

lab3640rtr#sho ip ospf int | inc ID
  Process ID 42, Router ID 192.168.3.6, Network Type BROADCAST, Cost: 1
  Designated Router (ID) 192.168.3.6, Interface address 192.168.2.1
  Process ID 42, Router ID 192.168.3.6, Network Type POINT_TO_POINT, Cost: 64
lab3640rtr#


Maybe the router is picking the highest IP address for the router ID?

lab3640rtr(config)#int fa0/0
lab3640rtr(config-if)#no ip address
lab3640rtr(config-if)#ip address 192.168.168.192 255.255.255.0
lab3640rtr(config-if)#router ospf 42
lab3640rtr(config-router)#no network 192.168.2.0 0.0.0.255 area 3
lab3640rtr(config-router)#network 192.168.168.192 0.0.0.255 area 3
lab3640rtr(config-router)#exit
lab3640rtr(config)#exit
lab3640rtr#sho ip ospf int | inc ID
  Process ID 42, Router ID 192.168.3.6, Network Type BROADCAST, Cost: 1
  Process ID 42, Router ID 192.168.3.6, Network Type POINT_TO_POINT, Cost: 64
lab3640rtr#


Hmmm...I really thought the router ID would have changed at some point now. Let's try restarting the OSPF process, and see what happens:

lab3640rtr(config)#no router ospf 42
lab3640rtr(config)#router ospf 42
lab3640rtr(config-router)# log-adjacency-changes
lab3640rtr(config-router)# redistribute connected subnets
lab3640rtr(config-router)# network 192.168.3.4 0.0.0.3 area 3
lab3640rtr(config-router)# network 192.168.168.0 0.0.0.255 area 3
lab3640rtr(config-router)#exit
lab3640rtr(config)#exit
lab3640rtr#sho ip ospf int | inc ID
  Process ID 42, Router ID 192.168.168.192, Network Type BROADCAST, Cost: 1
  Designated Router (ID) 192.168.168.192, Interface address 192.168.168.192
  Process ID 42, Router ID 192.168.168.192, Network Type POINT_TO_POINT, Cost: 64
lab3640rtr#


And we have a winner!!! Restarting OSPF with a higher numbered interface did the trick. What if we configure a loopback interface? Will OSPF use a loopback interface for a router ID over a FastEthernet or Serial interface? We'll configure a low-numbered loopback0 and see if OSPF grabs it or sticks with the high-numbered Fa0/0:

lab3640rtr(config)#int loopback0
lab3640rtr(config-if)#ip address 192.168.2.1 255.255.255.255
lab3640rtr(config-if)#no router ospf 42
lab3640rtr(config)#router ospf 42
lab3640rtr(config-router)# log-adjacency-changes
lab3640rtr(config-router)# redistribute connected subnets
lab3640rtr(config-router)# network 192.168.3.4 0.0.0.3 area 3
lab3640rtr(config-router)# network 192.168.168.0 0.0.0.255 area 3
lab3640rtr(config-router)# network 192.168.2.1 0.0.0.0 area 3
lab3640rtr(config-router)#exit
lab3640rtr(config)#exit
lab3640rtr#sho ip ospf int | inc ID
  Process ID 42, Router ID 192.168.2.1, Network Type LOOPBACK, Cost: 1
  Process ID 42, Router ID 192.168.2.1, Network Type BROADCAST, Cost: 1
  Designated Router (ID) 192.168.2.1, Interface address 192.168.168.192
  Process ID 42, Router ID 192.168.2.1, Network Type POINT_TO_POINT, Cost: 64
lab3640rtr#


Weird...I didn't expect that. I can see why a router might prefer a loopback interface for an OSPF router ID (a loopback interface never goes down, for one thing). Let's just double-check the preference for the loopback by swapping the networks for the loopback and Fa0/0:

lab3640rtr(config)#int loopback0
lab3640rtr(config-if)#no ip address
lab3640rtr(config-if)#int fa0/0
lab3640rtr(config-if)#no ip address
lab3640rtr(config-if)#ip address 192.168.2.1 255.255.255.0
lab3640rtr(config-if)#int loopback0
lab3640rtr(config-if)#ip address 192.168.168.192 255.255.255.255
lab3640rtr(config-if)#no router ospf 42
lab3640rtr(config)#router ospf 42
lab3640rtr(config-router)#log-adjacency-changes
lab3640rtr(config-router)#redistribute connected subnets
lab3640rtr(config-router)#network 192.168.3.4 0.0.0.3 area 3
lab3640rtr(config-router)#network 192.168.168.192 0.0.0.0 area 3
lab3640rtr(config-router)#network 192.168.2.0 0.0.0.255 area 3
lab3640rtr(config-router)#exit
lab3640rtr(config)#exit
lab3640rtr#sho ip ospf int | inc ID
  Process ID 42, Router ID 192.168.168.192, Network Type BROADCAST, Cost: 1
  Designated Router (ID) 192.168.168.192, Interface address 192.168.2.1
  Process ID 42, Router ID 192.168.168.192, Network Type LOOPBACK, Cost: 1
  Process ID 42, Router ID 192.168.168.192, Network Type POINT_TO_POINT, Cost: 64
lab3640rtr#


Yep, it still preferred to use the loopback. Okay, that makes sense. But that raises a question: I didn't get Fa0/0's IP address to become the router ID until I restarted the OSPF process. Did Fa0/0's IP address become the router ID because its IP address was greater than Serial0/0's address, or because it was a FastEthernet interface? Let's find out:

lab3640rtr(config)#no int loopback0
lab3640rtr(config)#no router ospf 42
lab3640rtr(config)#router ospf 42
lab3640rtr(config-router)# log-adjacency-changes
lab3640rtr(config-router)# redistribute connected subnets
lab3640rtr(config-router)# network 192.168.2.0 0.0.0.255 area 3
lab3640rtr(config-router)# network 192.168.3.4 0.0.0.3 area 3
lab3640rtr(config-router)#exit
lab3640rtr(config)#exit
lab3640rtr#sho ip ospf int | inc ID
  Process ID 42, Router ID 192.168.3.6, Network Type POINT_TO_POINT, Cost: 64
  Process ID 42, Router ID 192.168.3.6, Network Type BROADCAST, Cost: 1
  Designated Router (ID) 192.168.3.6, Interface address 192.168.2.1
lab3640rtr#


There you have it: if a loopback interface is present, OSPF will use it as the router ID, and if not, OSPF will use the highest IP address configured on the system. HOWEVER, OSPF will NOT change the router ID until the OSPF process is restarted, which makes sense if you think about it.

And now...it's late. I'm going to bed ;)