There are 5 network types,

1. Point to Point – Should be used as the name implies on P2P links which support broadcast, nearly all OSPF traffic is sent to the ALLSPFRouters address which is 224.0.0.5, although retransmitted LSAs are sent to the unicast address as such these links should support broadcasting.
2. Broadcast – This is the default network type for Ethernet networks, as this network type is capable of having adjacencies with multiple routers. To prevent unnecessary meshing DR & BDR elections take place. Communications from the DR & BDR take place on the ALLDRRouters address 224.0.0.6 whilst all other communications on 224.0.0.5. As the name implies the layer 2 network must support broadcasting.
3. Non Broadcast Multiple Access (NBMA) – This is the default configuration on a serial interface, and is classified as a link which is able to send to multiple other routers via the single link but with no broadcasting, therefore neighbour statements must be manually set. A DR & BDR will still be elected but all communication is unicast, the hello and dead timers change from the defaults to 30 and 120 seconds.
4. Point to Multipoint networks – All communication is unicast and no DR or BDR election takes place an ideal placement for this would be in the hub in a hub and spoke topology.
5. Virtual Links – Packets sent over Virtual Links are unicast and perceived as unnumbered point to point connections

Its pretty simple to change the network type its all done under the interface like so.

Router(config-if)#ip ospf network ?
  broadcast            Specify OSPF broadcast multi-access network
  non-broadcast        Specify OSPF NBMA network
  point-to-multipoint  Specify OSPF point-to-multipoint network
  point-to-point       Specify OSPF point-to-point network

In hub and spoke enviornemnts before ODR there was generally two choices to the deployment

1. Have default routes on the spokes pointing to the hub and static routes back. But frankly this was a pain as there was an administrative burden as you have to manually add/remove each spoke as needed.
2. Run a routing protocol on the spokes which communicates reachability information with the hub but this is unnecessary as the spokes are dead end streets they don’t need more topology information than a default route and generally the spoke routers aren’t the best in the network so it an unneeded overhead.

But this is were On-Demand Routing (ODR) comes to the rescue . Now ODR is not a routing protocol, the spoke routers send details of attached networks via CDP to neighbouring routers and when ODR is enabled the network information is simply installed into the IP routing table. Each of the spokes only needs to have a default route pointing to the hub and have CDP enabled which is on by default and thats it. The routes it collects have an AD of 160 with a metric of 1 (only 1 hop away), the routes that ODR collected can then be redistributed into your IGP of choice.

If you don’t believe me that its that simple check out the configuration below

Firstly we just enable it with the

router odr

command, this is a single command which only needs to be configured on the hub, the spokes dont need it.

R0(config)#router odr

There are not many options in the protocol itself the most common you might wish to change is the timers

R0(config-router)#?
Router configuration commands:
  default            Set a command to its defaults
  default-metric     Set metric of redistributed routes
  distance           Define an administrative distance
  distribute-list    Filter networks in routing updates
  exit               Exit from routing protocol configuration mode
  help               Description of the interactive help system
  maximum-paths      Forward packets over multiple paths
  neighbor           Specify a neighbor router
  network            Enable routing on an IP network
  no                 Negate a command or set its defaults
  passive-interface  Suppress routing updates on an interface
  redistribute       Redistribute information from another routing protocol
  timers             Adjust routing timers
  traffic-share      How to compute traffic share over alternate paths

We can validate that its running and see the routes it has collected.

R0#sh ip protocols
Routing Protocol is "odr"
  Sending updates every 60 seconds, next due in 47 seconds
  Invalid after 180 seconds, hold down 0, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Maximum path: 4
  Routing Information Sources:
    Gateway         Distance      Last Update
    10.1.2.1             160      00:00:30
    10.1.1.1             160      00:00:47
  Distance: (default is 160)

And on the hub se should be able to see the routes installed into the IP routing table with the AD of 160 and metric of 1

R0#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 2 subnets
o       10.1.2.0 [160/1] via 10.1.2.1, 00:01:45, Serial0/1
                 [160/1] via 10.1.2.1, 00:00:45
o       10.1.1.0 [160/1] via 192.168.1.2, 00:00:02, Serial0/0
                 [160/1] via 10.1.1.1, 00:02:02, Serial0/0
                 [160/1] via 10.1.1.1, 00:01:02
     192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.1.0/24 is directly connected, Serial0/0
C       192.168.1.2/32 is directly connected, Serial0/0
     192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.2.2/32 is directly connected, Serial0/1
C       192.168.2.0/24 is directly connected, Serial0/1

Now to test it the view from R2 just shows the default route up to the hub

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

10.0.0.0/24 is subnetted, 1 subnets
C       10.1.2.0 is directly connected, Loopback0
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.2.0/24 is directly connected, Serial0/0
C       192.168.2.1/32 is directly connected, Serial0/0
S*   0.0.0.0/0 is directly connected, Serial0/0

Now to test if we can ping the other spoke router

R2#ping 10.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/39/60 ms

I am almost speechless at how simple it was to get spoke to spoke connectivity! Beautiful!

Dynamic Multipoint Virtual Private Network (DMVPN) solves many of these problems by using existing technologies such as IPsec, GRE tunnels and NHRP. The hub router is configured with a single mGRE interface for all the connections, and one IPsec profile and no crypto ACLS, the best bit is that no additional work is required at the hub router when a spoke router is being deployed (as much as I love configuring routers, anything to make life easy is always welcome).

Spoke routers learn about other spoke routers through routing as such a dynamic routing protocol will be required for this to operate effectively. Additionally DMVPN supports multiple hub routers for redundancy and load balancing and the spoke routers can be either statically or dynamically addressed.

A simple example of DMVPN is below, where each of the spoke routers has a permanent IPSec tunnel to the hub router, but each spoke router will establish direct IPSec tunnel to other spoke routers as and when required.

Per Destination – The original algorithm creates a 4 bit hash of the source and destination IP address and load balances based on this 16 value hash, an issue with this is that every router in the routing domain uses the same algorithm and this can cause something called CEF polarisation.

CEF polarisation occurs when traffic uses per destination load balancing and the same algorithm is used throughout the network which causes traffic to not be load balanced after the first distribution. In the example below if 100Mbs of traffic was coming into R1, it would be load balanced 50/50, with 50Mbs to R2 and 50Mbs to R3, but as R2 & R3 will use the same algorithm to determine which path the traffic will take, but as the algorithim is idential it will be a 100/0 split, with 50Mbs going to R4 and R7 and no data going to R5 or R6.

       R4-
     /
   R2
  /  \
 /    R5-
R1
 \     R6-
  \   /
    R3
      \
       R7-

To counter this issue a newer algorithm called the universal algorithm was developed where a 32 bit value is added to the algorithm, this value can be manually set but defaults to the highest loopback IP on the router. Per destination load balancing with the universal algorithm is the current default method of load balancing.

If there are a number of tunnels such as L2TP, GRE, MPLS etc operating through the router this could also cause route polarisation due to the low number of sessions, as such the tunnel algorithm was developed to solve this issue. It appears to be a pretty undocumented feature, so any more information on the algorithm would be appreciated.

The algorithm can be changed as required with the following command;

Router(config)#ip cef load-sharing algorithm ?
  include-ports  Algorithm that includes Layer 4 ports
  original       Original algorithm
  tunnel         Algorithm for use in tunnel only environments
  universal      Algorithm for use in most environments

Per Packet – In this mode packets are load shared in a round robin way, it can result in increased jitter due to multiple paths and as such generally not advisable.

Per Port – This is suitable for heavily NATed networks with a low number of hosts, and utilises a hashing function based on the layer 4 port numbers. As NATed hosts have a distributed range of source port numbers this allows for efficient load balancing in such situations.

Note:  Some more configuration examples to follower later

E1 or External Type Routes - The cost of E1 routes is the cost of the external metric with the additional of the internal cost within OSPF to reach that network.

E2 or External Type2 Routes – The cost of E2 routes will always be the external metric, the metric will takes no notice of the internal cost to reach that network.

If 2 external type 2 routes exist with the same metric to the same destination the route with the lowest metric to the ASBR will be used. Also if an E1 and and E2 route exist to the same destination the E1 route will always be preferred irrespective of the metric.

Cisco’s excellent reference on the topic is http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml#t33

Off Topic – The weather in the UK for some reason is always exceptional as its an island nation. For the last 5 or so days we have had an exception heatwave and it has been 30°C+ which were just not used to, and I have been surprised how much it has affected my ability to study, I just haven’t been able to concentrate for anywhere near as long as I can in the cold.

A designated Route Reflector router treats all neighbour routers as one of 3 types, clients, non-clients and eBGP. The relaxed rules for Route Reflectors are;

• Updates received from a client are sent to all clients & non-clients
• Updates received from a non-client are sent only to clients
• Updates received from eBGP peers are sent to all clients & non-clients

A Route Reflector and its clients combine to form a Route Reflector cluster, a BGP design could have multiple clusters or a cluster with multiple Route Reflectors. If muliple clusters exist then one Route Reflector per cluster must be peered directly with a Route Reflector in another cluster, although usually the Route Reflectors from all clusters peer directly.

As one of the loop prevention rules of BGP has been removed (never send iBGP learned routes to iBGP peers) it is possible that loops could form. To prevent this BGP route reflectors only reflect the best routes, also there are 2 optional non-transitive BGP attributes which further prevent looping these are;

ORIGINATOR_ID, this is a 4 byte attribute which contains the Router ID of the first iBGP peer which originated the route into the AS. Route Reflectors never send an update to the router specified in the ORIGINATOR_ID

CLUSTER_LIST, is list of the cluster IDs which the update has been passed through, each Route Reflector will add its own cluster ID to the list before sending an update. If a Route Reflector sees its own cluster ID in the list it ignores the update.

LSA type 1 – Router LSAs are sent from a router to other routers in the same area. It contains information regarding the routers interfaces in the same area, relevant interfaces IPs, its adjacent routers on those interfaces and sub networks

LSA type 2 – Network LSAs are generated by the DR on a multi access segment, and provides similar information to an LSA type 1 for the multi access segment and subnet which it belongs

LSA type 3 – Network Summary LSAs are generated by ABRs and contain the subnets & costs but omit the topological data from all subnets in one area and sent to another area via the ABR

LSA type 4 -ASBR summary LSAs are from ASBRs and are identical in structure to a type 3 LSA and sent when crossing an AS boundary

LSA type 5 -Are AS external LSAs which are originated by ASBRs and describe external networks

LSA type 6 – Is defined as a Group Membership LSA but not used in Cisco devices

LSA type 7 -NSSA External LSAs are generated by the ASBR in an NSSA area

LSA type 8 – Is defined as a External Attribute LSA but not used in Cisco devices

LSA types 9 to 11 – Defined as Opaque LSAs and are reserved for future expansion

The Backbone Area or Area 0

The backbone area which is also configured as area 0, which is the area number which is used in the configuration. Area 0 which must be directly connected (except for a few very rare circumstances) to every other area. Area 0 must be continuous and is used for inter area routing between the OSPF areas.

Standard Area

This is the default area type which accepts link updates, route summaries and external routes.

Stub Areas

A stub area (sometimes referred to as a stubby area), is an area which does not receive type 4 or 5 LSA’s which are external routes from ASBRs. But a stubby area will receive type 3 LSAs which are summary routes from ABRs. If there are multiple ABRs in a stub area the route will be chosen which has the shortest path to the destination.

Totally Stubby Areas

Totally Stubby Areas, is a non standard area type used in Ciscos implementation of multi area OSPF. Totally Stubby Areas do not accept type 3, 4 or 5 LSAs, the ABRs only injects a single default route into the area. If there are multiple ABRs in the Totally Stubby Area each router routes to the closest (lowest metric) ABR in its area.

Not So Stubby Area (NSSA)

A Not So Stubby Area (NSSA) is a stub area which contains an an ASBR. It operates in the same way as a stub area but originates type 7 LSAs which are external routes from a ASBR in a NSSA area.

Not So Stubby Totally Stubby Area

This area name has got to be one of the craziest names I have come across, and I thought a Not So Stubby Area was bad. Its another non standard area type used by Cisco which is a Totally Stubby Area which has an ASBR which originates type 7 LSAs.

If OSPF did not use the concept of having a DR then each router on the multiaccess segment would directly share its LSDB with each other, we can calculate the number of instances of  LSDB flooding that would occur if there wasn’t a DR on a multiaccess segment with the full mesh formula which is N(N-1)/2.

So without OSPF DRs if we had 10 routers then where would be 45 LSDBs flooded between the adjacent OSPF routers (N(N1-1)/2 = 10(10-1)/2 = 45). This could potentially cause a serious amount of overhead due to the massive amount of redundant LSAs that would be propagating the network. This is the main reason why OSPF DRs are used, another good point about OSPF DRs is that they originate type 2 LSAs which represent a subnet. I will make a post on all of the LSA types soon.

OSPF will start to perform a DR election when it starts 2-way state on the first neighbor it sees on an interface if the hello received from the neighbor has a DR of 0.0.0.0 (0.0.0.0 as the DR in a hello packet means a DR has not yet been elected). OSPF will then wait the period specified in the Dead Timer, where it is waiting for other routers to communicate and come online. This timer is called the wait time and is used to allow other routers to come online and be active for the DR elections after a failure, if this did not occur then one of the first routers to be online would always be the DR.

If the received OSPF hello has a DR of anything else apart from 0.0.0.0 that indicates that DR elections have already taken place and OSPF will use the DR specified in the hello.

In each OSPF hello it sends the current DR and its Priority, if the DR priority of a received hello is higher than the current DR it recognises that as the current DR. The router priority is a value between 0 and 255 with the higher being better, the default is 1 and if it is set to 0 then the router will never become a DR. If there is a tie between OSPF priorities then the highest Router ID wins the tie breaker. The second most preferable DR becomes the Backup DR (BDR) and is used as a failover. Routers which are not the DR or BDR assume the DROther state. Once the DR election is complete the router will move into ExStart and start exchange Database Descriptors (DD).

All OSPF routers send their DDs to the multicast address of 224.0.0.6, this gets acknowledged by the DR sending the same packet back to the source as unicast. The DR then sends the DD it has received to all OSPF routers on the multi access segment via the multicast address of 224.0.0.5. This means that all routers on a multi access network to not need to constantly keep updating one another, they only have to update a central source and this is then sent to the segment.

For a router to send OSPF messages it has to define its OSPF Router Identifier (RID). This is a 32bit dotted decimal number which uniquely identifies the router.

Its a simple 3 steps for the router to choose what the RID will be

1. If the router-id id command is configured under router ospf then that that will always be used as the RID
2. If there is no router-id configured it uses the numerically highest up loopback interface
3. Finally if there is no router-id command set or no loopback interfaces up then it uses the highest interface IP address which is up.

It should be noted that the RID is only used to uniquely identify the OSPF router and does not need to be reachable or exist in the routing table. If the RID is changed then all OSPF routers in the area will have to recalculate SPF as its unique identifier has changed.

The final point is that the RID will only change when the router-id command is entered, or OSPF is restarted.