1. Home
  2. Cisco Systems
  3. ospf network statement - correct use (long)

ospf network statement - correct use (long)

I'm hoping someone out there has the definitive answer to this one, as I'm getting really confused! I've read, and been told, that the network statement for OSPF should be used with subnets on which you only want the OSPF process to run, not for networks you want to advertise out through OSPF (although I've also read the reverse, hence the post). Consider the following (I've changed the IPs but the principles of what I'm experiencing are the same):

Suppose you have a large network and have decided to use 172.16.0.0/16 for all IP devices, subnetting where appropriate. You assign

172.16.1.0/24 through to 172.16.20.0/24 for various departments on one router, and 172.16.21.0/24 through to 172.16.40.0/24 for others on another router. 172.16.254.0/24 is assigned for router management and router-to-router interfaces and is subnetted further, for example:

172.16.254.0/30 router 1 to router 2

172.16.254.253/32 router 1 loopback 172.16.254.254/32 router 2 loopback

Snippets of the basic interface config for each router are as follows:

router 1

------------ interface vlan 2 ip address 172.16.2.1 255.255.255.0

interface vlan 3 ip address 172.16.3.1 255.255.255.0

interface vlan 100 ip address 172.16.254.1 255.255.255.252

router 2

------------ interface vlan 10 ip address 172.16.10.1 255.255.255.0

interface vlan 11 ip address 172.16.11.1 255.255.255.0

interface vlan 100 ip address 172.16.254.2 255.255.255.252

Vlan 100 is used to connect the routers together and each router runs one OSPF process:

router ospf 1 passive-interface default no passive-interface Vlan100

So the question is, what exactly should the network statements look like? If you go by the book then it should read something like:

network 172.16.254.0 0.0.0.3 area 172.16.0.0

for each router (or even stricter by referencing the exact IP address with a 0.0.0.0 wildcard mask - apparently this is commonly quoted in cisco material as the method to use).

In this case, the 2 routers will become OSPF neighbours, but will need a 'redistribute connected' statement in order for subnets on router 1 to be advertised to router 2 (and vice versa). The problem here is that router 2 will 'learn' 172.16.1.0/24 as an external route, either type 1 or 2 depending on the metric type specified in the redistribute statement of router 1. ie, 'show ip route 172.16.1.0' on router 2 will have a code of 'O E1' or 'O E2'.

However, if you use the following network statement on each router:

network 172.16.0.0 0.0.255.255 area 172.16.0.0

then you don't need to use 'redistribute connected' and 'show ip route

172.16.1.0' on router 2 will have a code of 'O', ie an internal OSPF route. I'm using 'passive-interface default' to prevent OSPF packets on interfaces that don't have routers connected to them.

To me, logic would suggest that routes advertised between routers in the same area should not appear as external and therefore the first method is flawed. Also, the only routes with code 'O' will be the ones used to interconnect the routers together ... or is this what an OSPF code 'O' route indicates? With the 2nd method all routes will be in the routing tables as code 'O', which makes more sense.

On a related matter, if I wanted my area to be a stub area (it is connected to backbone 0, I've just left this out for clarity) I believe none of the routers can be ASBRs ... which they all are due to the prescence of a 'redistribute' statement. Which would suggest that the use of 'redistribute connected' is not the preferred way to go.

Any advice gratefully received.

Darren

Reply to
Darren Hughes
Loading thread data ...

This is sufficient and acceptable.

You would not use the redistribute connected command unless something was broken in IOS code which happens from time to time

Reply to
Merv

what this is saying is ospf on the interconnect between the routers no ospf on the loopbacks and other interfaces

this is how the OSPF standard specifies it should work.

The only routes that are "internal" are those where OSPF is running on the interface on the advertising router. Everything else is an external.

because this statement says "all interfaces are running ospf"

"Passive" is a frig invented by cisco and others to get aorund the ospf strict definitions of interface type.

internal routes are useful, since they can be summarised.

but ospf adjacencies are expensive in router resources such as CPU, memory, and bursts of database replication if you have the same neighbour by many routes. imagine a pair of campus core switches in parallel with 200 subnets - each core switch has 200 adjacencies with the same partner device, all needing any ospf change to be propagated, and 99% of them are useless. Far better to have 198 interfaces passive, and just 1 or 2 chosen for the preferred interconnects - then all the routes can be summarised at an ABR.

the reasoning is backward - externals are not really part of the area, and are flooded throughout the AS.

so - if you want routes limited to the area, they shouldnt be externals.

flip side is that many ospf implementations use less resources to handle an external so scaling may be an issue - 1 Nortel device i worked on was characterised to handle 2000 ospf internal routes but 20k externals.

Also, the only routes with code 'O' will be the ones

Yes - stub areas dont have (or strictly should not be able to inject) external routes.

note - ospf gets more complicated and stops being fully dykstra once you introduce areas, since link state is only used within an area.

some of the extensions relax the rules - have a look at not so stubby areas (NSSAs)

Reply to
stephen

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.