OSPF and Connected Networks: To Redistribute or Not?

A few days ago, I was discussing a data center design with a seasoned network architect. During the MPLS discussions, he made an offhand remark “There are still some switches running OSPF and using network 0.0.0.0 and redistribute connected.” My first thought was, “This can’t be good,” but I had no idea how bad it was until I ran a lab test.

The generic dilemma along the lines of “should I make connected interfaces part of my OSPF process (and make them passive) or should I redistribute them into OSPF” has no clear-cut answer (apart from the obvious “it depends”) ... and Google will quickly find you tons of lengthy discussions.

However, doing both is clearly harmful, as the router includes connected subnets as stub links in its Type-1 LSA (causing full SPF run every time an interface flaps) and generates Type-5 LSA for every connected subnet (and you know the pesky Type-5 LSAs will just whizz by any summarization boundary and plague the whole OSPF domain). To make matters even more complex, in some Cisco IOS releases, specifying the OSPF area on an interface (with the ip ospf area interface configuration command) disables the generation of Type-5 LSA whereas using the network statement does not.

The next printout shows the summary of the IP addressing/OSPF configuration I was using (I started a single router in one of the OSPF labs that you get as part of the DMVPN – From Basics to Scalable Networks webinar).

interface Loopback0
 ip address 10.0.1.5 255.255.255.255
 ip ospf 1 area 11
!
interface Tunnel0
 ip address 192.168.0.5 255.255.255.0
 ip ospf network broadcast
 ip ospf priority 0
!
interface Tunnel1
 ip address 192.168.1.5 255.255.255.0
 ip ospf network broadcast
 ip ospf priority 0
!
interface FastEthernet0/0
 ip address 172.16.11.1 255.255.255.0
 ip ospf 1 area 11
!
interface Serial1/0
 ip address 10.0.7.9 255.255.255.252
 encapsulation ppp
!
router ospf 1
 log-adjacency-changes
 redistribute connected subnets
 network 0.0.0.0 255.255.255.255 area 11

The router has five operational IP-enabled interfaces:

R2#show ip interface brief | include up
FastEthernet0/0       172.16.11.1     YES NVRAM  up          up
Serial1/0             10.0.7.9        YES NVRAM  up          up
Loopback0             10.0.1.5        YES NVRAM  up          up
Tunnel0               192.168.0.5     YES NVRAM  up          up
Tunnel1               192.168.1.5     YES NVRAM  up          up

OSPF is running on five interfaces (as expected), all of them covered by the network statement. OSPF area is specified on two of them with interface configuration commands:

R2#show ip ospf interface | include protocol|Area|Enabled
Loopback0 is up, line protocol is up
  Internet Address 10.0.1.5/32, Area 11
  Enabled by interface config, including secondary ip addresses
Tunnel1 is up, line protocol is up
  Internet Address 192.168.1.5/24, Area 11
Tunnel0 is up, line protocol is up
  Internet Address 192.168.0.5/24, Area 11
Serial1/0 is up, line protocol is up
  Internet Address 10.0.7.9/30, Area 11
FastEthernet0/0 is up, line protocol is up
  Internet Address 172.16.11.1/24, Area 11
  Enabled by interface config, including secondary ip addresses

The OSPF database has one Type-1 LSA (with five links) and three Type-5 LSAs:

R2#show ip ospf database

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

                Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.0.1.5        10.0.1.5        806         0x80000006 0x00C926 5

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
10.0.7.8        10.0.1.5        862         0x80000001 0x003644 0
192.168.0.0     10.0.1.5        812         0x80000001 0x00B670 0
192.168.1.0     10.0.1.5        808         0x80000001 0x00AB7A 0

The stub network links of the Type-1 LSA include all five directly connected interfaces:

R2#show ip ospf database router 10.0.1.5 | include Network
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.0.1.5
     (Link Data) Network Mask: 255.255.255.255
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 192.168.1.0
     (Link Data) Network Mask: 255.255.255.0
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 192.168.0.0
     (Link Data) Network Mask: 255.255.255.0
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.0.7.8
     (Link Data) Network Mask: 255.255.255.252
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 172.16.11.0
     (Link Data) Network Mask: 255.255.255.0

To summarize:

  • The router has five directly connected IP subnets; all of them are part of the OSPF routing protocol and redistributed into OSPF;
  • The Type-1 LSA has five stub networks (as expected)
  • Connected subnets are also inserted into the OSPF database as Type-5 LSAs (as expected)
  • However, only three connected subnets (those without ip ospf area interface configuration command) are redistributed into OSPF.

Weird? Absolutely. Confusing? You bet.

Recommendation

Use one or the other mechanism, not both. If you decide to redistribute connected subnets into OSPF with the redistribute connected subnets command, don’t use the network-based routing protocol configuration; use ip ospf area interface configuration commands on transit interfaces to minimize the number of Type-5 LSAs inserted into the OSPF database.

9 comments:

  1. I also try this with IOS 12.4(22)T
    * The router has four directly connected IP subnets; three of them are part of the OSPF routing protocol and all redistributed into OSPF
    * The Type-1 LSA has four stub networks
    * Connected subnets are inserted into the OSPF database as Type-5 LSAs only if OSPF is disabled on interface
    * ip ospf area interface configuration command configured on two interfaces but results are just like network statement

    interface Loopback0
    ip address 192.0.0.1 255.255.255.255
    ip ospf 1 area 0
    interface FastEthernet0/0
    ip address 192.0.1.1 255.255.255.0
    interface FastEthernet1/0
    ip address 192.0.2.1 255.255.255.0
    ip ospf 1 area 0
    interface FastEthernet2/0
    ip address 192.4.1.1 255.255.255.0

    router ospf 1
    redistribute connected subnets
    network 192.0.1.0 0.0.0.255 area 0
    network 192.0.2.0 0.0.0.255 area 0

    dyn1#sh ip ospf database
    OSPF Router with ID (192.0.0.1) (Process ID 1)
    Router Link States (Area 0)
    Link ID ADV Router Age Seq# Checksum Link count
    192.0.0.1 192.0.0.1 4 0x80000002 0x00F54D 3
    Type-5 AS External Link States
    Link ID ADV Router Age Seq# Checksum Tag
    192.4.1.0 192.0.0.1 4 0x80000001 0x001603 0


    dyn1#sh ip ospf database router 192.0.0.1 | i Network
    Link connected to: a Stub Network
    (Link ID) Network/subnet number: 192.0.0.1
    (Link Data) Network Mask: 255.255.255.255
    Link connected to: a Stub Network
    (Link ID) Network/subnet number: 192.0.1.0
    (Link Data) Network Mask: 255.255.255.0
    Link connected to: a Stub Network
    (Link ID) Network/subnet number: 192.0.2.0
    (Link Data) Network Mask: 255.255.255.0
  2. Just for fun, would you try it with "network 0.0.0.0 0.0.0.0 area 0"?
  3. router ospf 1
    redistribute connected subnets
    network 0.0.0.0 255.255.255.255 area 0


    OSPF Router with ID (192.0.0.1) (Process ID 1)
    Router Link States (Area 0)
    Link ID ADV Router Age Seq# Checksum Link count
    192.0.0.1 192.0.0.1 21 0x80000001 0x00C3A9 4

    interface Loopback0
    ip address 192.0.0.1 255.255.255.255
    ip ospf 1 area 0
    interface FastEthernet0/0
    ip address 192.0.1.1 255.255.255.0
    interface FastEthernet1/0
    ip address 192.0.2.1 255.255.255.0
    ip ospf 1 area 0
    interface FastEthernet2/0
    ip address 192.4.1.1 255.255.255.0
  4. So they obviously broke something in 15.0M ... and I just had to stumble upon the bug.
  5. MPLS - Sham-Link:
    (from 12-4T config giude)
    Before you create a sham-link between PE routers in an MPLS VPN, you must:
    Configure a separate /32 address on the remote PE so that OSPF packets can be sent over the VPN backbone to the remote end of the sham-link. The /32 address must meet the following criteria:
    –Not be advertised by OSPF.

    Redistribute connected breaks the above restriction.
    been there, done that.
  6. Found old link about Redistributing Connected Networks into OSPF
    www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094707.shtml
  7. Dejavu! I am cleaning up a bunch of OSPF after some discussions with a very experienced network architect. I have decided to move down the path of all interface based configuration where possible, even if only because this same network is also running IPv6 and OSPFv3 as well.
  8. Looks like a reappearance of a very old bug. Thank you!
  9. With IOS componetization some old bugs are being reintroduced, unfortunately. This is mostly in post 15.x releases as there has been a big push into getting more and more features componetized. In the long run it should make things more stable but there are some growing pains.
Add comment
Sidebar