Open Shortest Path Routing (OSPF) is a shortest path first (SPF) or link-state protocol. OSPF is an interior gateway protocol that distributes routing information between routers in a single autonomous system. OSPF chooses the least cost path as the best path. Suitable for complex networks with a large number of routers, OSPF provides equal cost multipath routing where packets to a single destination can be sent via more than one interface simultaneously.
In a link-state protocol, each router maintains a database describing the entire AS topology, which it builds out of the collected link state advertisements of all routers. Each participating router distributes its local state (i.e., the router's usable interfaces and reachable neighbors) throughout the AS by flooding. Each multiaccess network that has at least two attached routers has a designated router and a backup designated router. The designated router floods a link state advertisement for the multiaccess network and has other special responsibilities. The designated router concept reduces the number of adjacencies required on a multiaccess network.
OSPF allows networks to be grouped into areas. Routing information passed between areas is abstracted, potentially allowing a significant reduction in routing traffic. OSPF uses four different types of routes, listed in order of preference: intra-area, inter-area, type 1 external, and type 2 external. Intra-area paths have destinations within the same area. Inter-area paths have destinations in other OSPF areas. And Autonomous System External (ASE) routes are routes to destinations external to the AS. Routes imported into OSPF as type 1 routes are supposed to be from igps whose external metrics are directly comparable to OSPF metrics. When a routing decision is being made, OSPF will add the internal cost to the AS Border router to the external metric. Type 2 ASEs are used for egps whose metrics are not comparable to OSPF metrics. In this case, only the internal OSPF cost to the AS Border router is used in the routing decision.
From the topology database, each router constructs a tree of the shortest paths with itself as the root. This shortest-path tree gives the route to each destination in the AS. Externally derived routing information appears on the tree as leaves. The link-state advertisement format distinguishes between information acquired from external sources and information acquired from internal routers, so there is no ambiguity about the source or reliability of routes. Externally derived routing information (for example, routes learned from EGP or BGP) is passed transparently through the autonomous system and is kept separate from OSPF's internally derived data. Each external route can also be tagged by the advertising router, enabling a passing of additional information between routers on the borders of the autonomous system.
OSPF optionally includes type of service (TOS) routing and allows administrators to install multiple routes to a given destination for each type of service (e.g. low delay or high throughput.) A router running OSPF uses the destination address and the type of service to choose the best route to the destination.
OSPF intra- and inter-area routes are always imported into the GateD routing database with a preference of 10. It would be a violation of the protocol if an OSPF router did not participate fully in the area's OSPF; so it is not possible to override this. Although it is possible to give other routes lower preference values explicitly, it is ill-advised to do so.
Hardware multicast capabilities are also used where possible to deliver link-status messages. OSPF areas are connected by the backbone area, the area with identifier 0.0.0.0. All areas must be logically contiguous and the backbone is no exception. To permit maximum flexibility, OSPF allows the configuration of virtual links which enables the backbone area to appear contiguous despite the physical reality.
All routers in an area must agree on that area's parameters. A separate
copy of the link-state algorithm is run for each area. Because of this,
most configuration parameters are defined on a per area basis. All routers
belonging to an area must agree on that area's configuration. Misconfiguration
will lead to adjacencies not forming between neighbors, and routing information
might not flow, or even loop.
ospf yes | no | on | off [ { defaults { preference preference ; cost cost ; tag [ as ] tag ; type 1 | 2 ; inherit-metric ; } ; exportlimit routes ; exportinterval time ; traceoptions trace_options ; syslog [first pktcnt][ every every_pktcnt]; monitorauthkey authkey ; monitorauth none | ( [ simple | md5 ] authkey ) ; backbone | ( area area ) { authtype 0 | 1 | none | simple ; stub [ cost cost] ; networks { network [ restrict ] ; network mask mask [ restrict ] ; network masklen number [ restrict ] ; host host [ restrict ] ; } ; stubhosts { host cost cost ; } ; interface interface_list; [cost cost ] { interface_parameters } ; interface interface_list nonbroadcast [cost cost ] { pollinterval time ; routers { gateway [ eligible ] ; } ; interface_parameters } ; Backbone only: virtuallink neighborid router_id transitarea area { interface_parameters } ; } ; } ] ;
The following are the interface_parameters referred to above. These may be specified on any class of interface and are described under the interface clause.
enable | disable ; retransmitinterval time ; transitdelay time ; priority priority ; hellointerval time ; routerdeadinterval time ; auth [none | simple] auth_key ; auth md5 ospf_md5_key; secondary [none | simple | md5] auth_key ; tunnel host ;
ASE export rate
It is also useful to assign an additional address to the loopback interface (one not on the 127 network) and advertise it as a stub hosts. If this address is the same one used as the router-id, it enables routing to OSPF routers by router-id, instead of by interface address. This is more reliable than routing to one of the router's interface addresses which may not always be reachable.
Each interface has a cost. The costs of all interfaces that
a packet must cross to reach a destination are summed to get the cost to
that destination. The default cost is one, but another non-zero value may
be specified.
Interface parameters common to all types of interfaces are:
where: md5-key is: key auth-key id id-number [ { [start-generate date-time;] [stop-generate date-time;] [start-accept date-time;] [stop-accept date-time;] }; ] [auth-key: is one to eight character string id-number: is integer between 1-255) date-time: is YYYY/MM/DD HH:MM (all time fields required)]
Used by OSPF authentication to generate md5 authentication. See Section 6.2.2.2.2 on Authenticastion below for a more detailed desription of its use.
Point-to-point interfaces also support this additional parameter:
If the use of IP multicasting is not desired because the remote neighbor does not support it, the nomulticast parameter may be specified to force the use of unicast OSPF packets. This option may also be used to eliminate warnings when GateD detects the bug mentioned above.
A non-broadcast interface supports any of the standard interfaceclauses listed above, plus the following two that are specific to non-broadcast interfaces:
All OSPF protocol exchanges are authenticated. Authentication guarantees that routing information is only imported from trusted routers, to protect the Internet and its users. A variety of authentication schemes can be used but a single scheme must be configured for each area. This enables some areas to use much stricter authentication than others. OSPF protocol exchanges may be authenticated. Authentication guarantees that routing information is imported only from trusted routers, in order to protect the Internet and its users. There are three authentication schemes available per interface: none, simple and RFC 2178 OSPF MD5 authentication per interface. Each of the authentication schemes can be specified on an interface basis.
Earlier OSPF specification (1247 and 1583) allowed for the authentication type to be configured per area with the ability to configure separate passwords per interface. Earlier versions of GateD extended the RFC 1247 concepts to allow the configuration of different authentication types and keys per interface. These earlier versions of GateD specified a primary and a secondary authentication type and key on each interface. Outgoing packets use the primary authentication type, but incoming packets may match either the primary or secondary authentication type and key. While this functioning has been retained, it is suggested that users move to the new MD5 based format.
These can be supported in the OSPF configuration in the following ways:
auth none your-key;
auth simple your-key;
The first authentication uses a simple authentication key of up to 8 characters and is standardized. The simple password provides very little protection because in many cases it is possible to easily capture packets from the network and learn the authentication key. The MD5 algorithm provides much more protection as it does not include the authentication key in the packet.
auth md5 key md5-key where: md5-key is: key your-key id id-number [ { [start-generate date-time;] [stop-generate date-time;] [start-accept date-time;] [stop-accept date-time;] }; ] [id-number is integer between 1-255) date-time: is YYYY/MM/DD HH:MM (all time fields required)]
This version of GateD implements the MD5 specification of OSPF "RFC 2178 which uses the MD5 algorithm and an authentication key of up to 16 characters. RFC 2178 allows multiple MD5 keys per interface. Each key has two times associated with the key:
If you always want your key to be accepted, simply specify a sequence such as:
auth md5 key mikeyone id 1;
Without a value for keys, the default values for the key are:
auth md5 { md-5 key md-5 key . . . md-5 key }; where: md5-key is: key your-key id id-number [ { [start-generate date-time;] [stop-generate date-time;] [start-accept date-time;] [stop-accept date-time;] }; ] id-number: is integer 1-255 date-time: is YYYY/MM/DD HH:MM (all time fields required) The default value for the start times is the beginning of time. The default value for the stop times is the end of time.
An example of multiple keys is as follows:
Two routers may start out generating key 1 and switch to key 2 at 6:00 GMT. In order to make transitioning between keys easier, the routers agree to stop generating key 1 at 6:00 GMT but allow acceptance of key 1 until 6:10 GMT. The longer acceptance period allows the clocks between the routers to be slightly out of sync.
This sequence of keys would be specified by:
auth md5 key { key mikeyone id 1 { start-generate 1977/11/30 00:01; auth md5 { key mikeyone id 1 { start-generate 1977/11/30 00:01; stop-generate 1977/12/01 06:00; start-accept 1997/11/30 00:00; stop-accept 1977/12/01 06:10; }; key mikeytwo id 2 { start-generate 1977/12/01 05:50 stop-generate 1977/12/01 06:00; start-accept 1997/11/30 00:00; stop-accept 1977/12/01 06:10; }; };
In addition to the following OSPF specific trace flags, OSPF supports the state which traces interface and neighbor state machine transitions.
Packet tracing options (which may be modified with detail, send and recv):
OSPF2 selects an OSPF which is compliant to OSPF version 2 (RFC 1583).
By the time of release, many features of the RFC 2178 will be encoded in
OSPF2.
The GateD OSPF2 code is also a re-write of the current OSPF code, originally from University of Maryland. The rewrite of OSPF has the following goals:
Either OSPF or OSPF2 can be configured into GateD at build time. The user cannot build GateD with both.
The users desiring to use GateD version 2 of OSPF (OSPF2) should be aware that the code is in pre-alpha state. While the code contained in this release will build and function for certain limited topologies, the code has not passed all of the Merit GateD Testing Toolkit (GATT) OSPF tests. Snapshots of this code will be released in 1998, for external testing prior to an Alpha release.
For information on the snapshot, please refer to the GateD-Unicast source
code web page.
You can build OSPF version 2 by specifying in the GateD build file Config,
specify OSPF version two by setting the following on the protocol line
in GateF version 4.0.x (where x is the final digit of the release number).
protocols rip bgp icmp egp ospf2
OSPF version 2 will build instead of the current OSPF.
GateD Version 5.x build with OSPF by default at this time. You must modify the build options in "options.h" file in order to build with OSPF2.
Last updated December 2, 1997
gated@gated.merit.edu