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 comparible 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 enable 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.
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 experimental MD5 algorithm provides much more protection as it does not include the authentication key in the packet.
The OSPF specification currently specifies that the authentication type be configured per area with the ability to configure seperate passwords per interface. This has been extended to allow the configuration of different authentication types and keys per interface. In addition it is possible to specify both 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.
ospf yes | no | on | off [ {
defaults {
preference preference ;
cost cost ;
tag [ as ] tag ;
type 1 | 2 ;
} ;
exportlimit routes ;
exportinterval time ;
traceoptions trace_options ;
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 refered to
above. The 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 ;
authkey auth_key ;
as keyword is specified
aht the tag is limited to 12 bits of information. If not
specified, the tag is set to zero.
ospf_monitor
(This should be a hyperlink) utility. This utility sends non-standard
OSPF packets which generate a text response from OSPF. By default
these requests are not authenticated, if an authentication key is
configured, the incoming requests must match the specified
authentication key. No OSPF state may be changed by these packets,
but the act of quering OSPF can utilize system resouces.
backbone. The backbone may only be configured using the
backbone keyword, it may not be specified as
area 0. The backbone interface may be a
virtuallink.
authenticationkey. The currently valid
values are none (0) for no
authentication, or simple (1)
for simple password authentication.
stub area is one in which there are no ASE
routes. If a cost is specified, this is
used to inject a default route into the area with the
specified cost.
networks list describes the scope of an
area. Intra-area LSAs that fall within the specified
ranges are not advertised into other areas as inter-area
routes. Instead, the specified ranges are advertised as
summary network LSAs. If
restrict is specified, the summary
network LSAs are not advertised. Intra-area LSAs
that do not fall into any range are also advertised as
summary network LSAs. This option is very useful on well
designed networks in reducing the amount of routing
information propagated between areas. The entries in
this list are either networks, or a subnetwork/mask pair.
See the section on Route
Filtering for more detail about specifying ranges.
It is also useful to assign a 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 routers interface addresses which may not always be reachable.
broadcast (which requires IP multicast support) or a
point-to-point interface. See the section on inteface list
specification for the description of the
interface_list.
Each interface has a cost. The costs of all
interfaces 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:
0x, or a one to eight character string in
double quotes.
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.
nonbroadcast interface on a non-broadcast
multi-access (NBMA) media. Since an OSPF
broadcast media must support IP multicasting, a
broadcast capable media, such as Ethernet, that does not support
IP multicasting must be configured as a non-broadcast interface.
A non-broadcast interface supports any of the standard interface clauses listed
above, plus the following two that are specific to non-broadcast
interfaces:
pollinterval.
neighborid is the
router_id of the other end of the virtual link. The
transit area specified must also configured on this
system. All standard interface parameters defined by the interface clause above may be
specified on a virtual link.
state which traces interface and neighbor state
machine transitions.
detail, send and recv):
HELLO packets which are used to
determine neighbor reachability.