OSPF version 2 is a routing protocol which is described in RFC 2328. OSPF is an IGP. Compared with RIP, OSPF can provide scalable network support and faster convergence times. OSPF is widely used in large networks such as ISP backbone and enterprise networks.
OSPF is, mostly, a link-state routing protocol. In contrast to distance-vector protocols, such as RIP or BGP, where routers describe available paths (i.e. routes) to each other, in link-state protocols routers instead describe the state of their links to their immediate neighbouring routers.
Each router describes their link-state information in a message known as an LSA, which is then propagated through to all other routers in a link-state routing domain, by a process called flooding. Each router thus builds up an LSDB of all the link-state messages. From this collection of LSAs in the LSDB, each router can then calculate the shortest path to any other router, based on some common metric, by using an algorithm such as Edsger Dijkstra’s SPF algorithm.
By describing connectivity of a network in this way, in terms of routers and links rather than in terms of the paths through a network, a link-state protocol can use less bandwidth and converge more quickly than other protocols. A link-state protocol need distribute only one link-state message throughout the link-state domain when a link on any single given router changes state, in order for all routers to reconverge on the best paths through the network. In contrast, distance vector protocols can require a progression of different path update messages from a series of different routers in order to converge.
The disadvantage to a link-state protocol is that the process of computing the best paths can be relatively intensive when compared to distance-vector protocols, in which near to no computation need be done other than (potentially) select between multiple routes. This overhead is mostly negligible for modern embedded CPUs, even for networks with thousands of nodes. The primary scaling overhead lies more in coping with the ever greater frequency of LSA updates as the size of a link-state area increases, in managing the LSDB and required flooding.
This section aims to give a distilled, but accurate, description of the more important workings of OSPF which an administrator may need to know to be able best configure and trouble-shoot OSPF.
OSPF defines a range of mechanisms, concerned with detecting, describing and propagating state through a network. These mechanisms will nearly all be covered in greater detail further on. They may be broadly classed as:
The Hello Protocol¶
The OSPF Hello protocol allows OSPF to quickly detect changes in two-way reachability between routers on a link. OSPF can additionally avail of other sources of reachability information, such as link-state information provided by hardware, or through dedicated reachability protocols such as BFD.
OSPF also uses the Hello protocol to propagate certain state between routers sharing a link, for example:
- Hello protocol configured state, such as the dead-interval.
- Router priority, for DR/BDR election.
- DR/BDR election results.
- Any optional capabilities supported by each router.
The Hello protocol is comparatively trivial and will not be explored in greater detail than here.
At the heart of OSPF are LSA messages. Despite the name, some LSA s do not, strictly speaking, describe link-state information. Common LSA s describe information such as:
Routers, in terms of their links.
Networks, in terms of attached routers.
Routes, external to a link-state domain:
- External Routes
Routes entirely external to OSPF. Routers originating such routes are known as ASBR routers.
- Summary Routes
Routes which summarise routing information relating to OSPF areas external to the OSPF link-state area at hand, originated by ABR routers.
OSPF defines several related mechanisms, used to manage synchronisation of LSDB s between neighbours as neighbours form adjacencies and the propagation, or flooding of new or updated LSA s.
OSPF provides for the protocol to be broken up into multiple smaller and independent link-state areas. Each area must be connected to a common backbone area by an ABR. These ABR routers are responsible for summarising the link-state routing information of an area into Summary LSAs, possibly in a condensed (i.e. aggregated) form, and then originating these summaries into all other areas the ABR is connected to.
Note that only summaries and external routes are passed between areas. As these describe paths, rather than any router link-states, routing between areas hence is by distance-vector, not link-state.
The core objects in OSPF are LSA s. Everything else in OSPF revolves around detecting what to describe in LSAs, when to update them, how to flood them throughout a network and how to calculate routes from them.
There are a variety of different LSA s, for purposes such as describing actual link-state information, describing paths (i.e. routes), describing bandwidth usage of links for TE purposes, and even arbitrary data by way of Opaque LSA s.
All LSAs share a common header with the following information:
Different types of LSA s describe different things in OSPF. Types include:
- Router LSA
- Network LSA
- Network Summary LSA
- Router Summary LSA
- AS-External LSA
The specifics of the different types of LSA are examined below.
The Router ID of the router originating the LSA.
ospf router-id A.B.C.D.
The ID of the LSA, which is typically derived in some way from the information the LSA describes, e.g. a Router LSA uses the Router ID as the LSA ID, a Network LSA will have the IP address of the DR as its LSA ID.
The combination of the Type, ID and Advertising Router ID must uniquely identify the LSA. There can however be multiple instances of an LSA with the same Type, LSA ID and Advertising Router ID, see sequence number.
A number to allow stale LSA s to, eventually, be purged by routers from their LSDB s.
The value nominally is one of seconds. An age of 3600, i.e. 1 hour, is called the MaxAge. MaxAge LSAs are ignored in routing calculations. LSAs must be periodically refreshed by their Advertising Router before reaching MaxAge if they are to remain valid.
Routers may deliberately flood LSAs with the age artificially set to 3600 to indicate an LSA is no longer valid. This is called flushing of an LSA.
It is not abnormal to see stale LSAs in the LSDB, this can occur where a router has shutdown without flushing its LSA(s), e.g. where it has become disconnected from the network. Such LSAs do little harm.
A number used to distinguish newer instances of an LSA from older instances.
Of all the various kinds of LSA s, just two types comprise the actual link-state part of OSPF, Router LSA s and Network LSA s. These LSA types are absolutely core to the protocol.
Instances of these LSAs are specific to the link-state area in which they are originated. Routes calculated from these two LSA types are called intra-area routes.
Each OSPF Router must originate a router LSA to describe itself. In it, the router lists each of its OSPF enabled interfaces, for the given link-state area, in terms of:
The output cost of that interface, scaled inversely to some commonly known reference value,
auto-cost reference-bandwidth (1-4294967.
- Link Type
A link to a multi-access network, on which the router has at least one Full adjacency with another router.
A link to a single remote router, with a Full adjacency. No DR is elected on such links; no network LSA is originated for such a link.
A link with no adjacent neighbours, or a host route.
Link ID and Data
These values depend on the Link Type:
Link Type Link ID Link Data Transit Link IP address of the DR Interface IP address Point-to-Point Router ID of the remote router Local interface IP address, or the ifindex for unnumbered links Stub IP address Subnet Mask
Links on a router may be listed multiple times in the Router LSA, e.g. a PtP interface on which OSPF is enabled must always be described by a Stub link in the Router LSA, in addition to being listed as PtP link in the Router LSA if the adjacency with the remote router is Full.
Stub links may also be used as a way to describe links on which OSPF is not spoken, known as passive interfaces, see
On multi-access links (e.g. ethernets, certain kinds of ATM and X.25 configurations), routers elect a DR. The DR is responsible for originating a Network LSA, which helps reduce the information needed to describe multi-access networks with multiple routers attached. The DR also acts as a hub for the flooding of LSA s on that link, thus reducing flooding overheads.
The contents of the Network LSA describes the:
As the LSA ID of a Network LSA must be the IP address of the DR, the Subnet Mask together with the LSA ID gives you the network address.
Each router fully-adjacent with the DR is listed in the LSA, by their Router-ID. This allows the corresponding Router LSA s to be easily retrieved from the LSDB.
Summary of Link State LSAs:
|LSA Type||LSA ID||LSA Data Describes|
|Router LSA||Router ID||The OSPF enabled links of the router, within a specific link-state area.|
|Network LSA||The IP address of the DR for the network||The subnet mask of the network and the Router IDs of all routers on the network|
With an LSDB composed of just these two types of LSA, it is possible to construct a directed graph of the connectivity between all routers and networks in a given OSPF link-state area. So, not surprisingly, when OSPF routers build updated routing tables, the first stage of SPF calculation concerns itself only with these two LSA types.
Link-State LSA Examples¶
The example below shows two LSA s, both originated by the same router (Router ID 192.168.0.49) and with the same LSA ID (192.168.0.49), but of different LSA types.
The first LSA being the router LSA describing 192.168.0.49’s links: 2 links to multi-access networks with fully-adjacent neighbours (i.e. Transit links) and 1 being a Stub link (no adjacent neighbours).
The second LSA being a Network LSA, for which 192.168.0.49 is the DR, listing the Router IDs of 4 routers on that network which are fully adjacent with 192.168.0.49.
# show ip ospf database router 192.168.0.49 OSPF Router with ID (192.168.0.53) Router Link States (Area 0.0.0.0) LS age: 38 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 Flags: 0x2 : ASBR LS Type: router-LSA Link State ID: 192.168.0.49 Advertising Router: 192.168.0.49 LS Seq Number: 80000f90 Checksum: 0x518b Length: 60 Number of Links: 3 Link connected to: a Transit Network (Link ID) Designated Router address: 192.168.1.3 (Link Data) Router Interface address: 192.168.1.3 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: a Transit Network (Link ID) Designated Router address: 192.168.0.49 (Link Data) Router Interface address: 192.168.0.49 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: Stub Network (Link ID) Net: 192.168.3.190 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 39063 # show ip ospf database network 192.168.0.49 OSPF Router with ID (192.168.0.53) Net Link States (Area 0.0.0.0) LS age: 285 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x6 LS Type: network-LSA Link State ID: 192.168.0.49 (address of Designated Router) Advertising Router: 192.168.0.49 LS Seq Number: 80000074 Checksum: 0x0103 Length: 40 Network Mask: /29 Attached Router: 192.168.0.49 Attached Router: 192.168.0.52 Attached Router: 192.168.0.53 Attached Router: 192.168.0.54
Note that from one LSA, you can find the other. E.g. Given the Network-LSA you have a list of Router IDs on that network, from which you can then look up, in the local LSDB, the matching Router LSA. From that Router-LSA you may (potentially) find links to other Transit networks and Routers IDs which can be used to lookup the corresponding Router or Network LSA. And in that fashion, one can find all the Routers and Networks reachable from that starting LSA.
Given the Router LSA instead, you have the IP address of the DR of any attached transit links. Network LSAs will have that IP as their LSA ID, so you can then look up that Network LSA and from that find all the attached routers on that link, leading potentially to more links and Network and Router LSAs, etc. etc.
From just the above two LSA s, one can already see the following partial topology:
------------------------ Network: ...... | Designated Router IP: 192.168.1.3 | IP: 192.168.1.3 (transit link) (cost: 10) Router ID: 192.168.0.49(stub)---------- IP: 192.168.3.190/32 (cost: 10) (cost: 39063) (transit link) IP: 192.168.0.49 | | ------------------------------ Network: 192.168.0.48/29 | | | Designated Router IP: 192.168.0.49 | | | | | Router ID: 192.168.0.54 | | | Router ID: 192.168.0.53 | Router ID: 192.168.0.52
Note the Router IDs, though they look like IP addresses and often are IP addresses, are not strictly speaking IP addresses, nor need they be reachable addresses (though, OSPF will calculate routes to Router IDs).
External, or “Type 5”, LSA s describe routing information which is entirely external to OSPF, and is “injected” into OSPF. Such routing information may have come from another routing protocol, such as RIP or BGP, they may represent static routes or they may represent a default route.
An OSPF router which originates External LSA s is known as an ASBR. Unlike the link-state LSA s, and most other LSA s, which are flooded only within the area in which they originate, External LSA s are flooded through-out the OSPF network to all areas capable of carrying External LSA s (Areas).
Routes internal to OSPF (intra-area or inter-area) are always preferred over external routes.
The External LSA describes the following:
- IP Network number
- The IP Network number of the route is described by the LSA ID field.
- IP Network Mask
- The body of the External LSA describes the IP Network Mask of the route. This, together with the LSA ID, describes the prefix of the IP route concerned.
- The cost of the External Route. This cost may be an OSPF cost (also known as a “Type 1” metric), i.e. equivalent to the normal OSPF costs, or an externally derived cost (“Type 2” metric) which is not comparable to OSPF costs and always considered larger than any OSPF cost. Where there are both Type 1 and 2 External routes for a route, the Type 1 is always preferred.
- Forwarding Address
- The address of the router to forward packets to for the route. This may be, and usually is, left as 0 to specify that the ASBR originating the External LSA should be used. There must be an internal OSPF route to the forwarding address, for the forwarding address to be usable.
- An arbitrary 4-bytes of data, not interpreted by OSPF, which may carry whatever information about the route which OSPF speakers desire.
AS External LSA Example¶
To illustrate, below is an example of an External LSA in the LSDB of an OSPF router. It describes a route to the IP prefix of 192.168.165.0/24, originated by the ASBR with Router-ID 192.168.0.49. The metric of 20 is external to OSPF. The forwarding address is 0, so the route should forward to the originating ASBR if selected.
# show ip ospf database external 192.168.165.0 LS age: 995 Options: 0x2 : *|-|-|-|-|-|E|* LS Flags: 0x9 LS Type: AS-external-LSA Link State ID: 192.168.165.0 (External Network Number) Advertising Router: 192.168.0.49 LS Seq Number: 800001d8 Checksum: 0xea27 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0
We can add this to our partial topology from above, which now looks like::
--------------------- Network: ...... | Designated Router IP: 192.168.1.3 | IP: 192.168.1.3 /---- External route: 192.168.165.0/24 (transit link) / Cost: 20 (External metric) (cost: 10) / Router ID: 192.168.0.49(stub)---------- IP: 192.168.3.190/32 (cost: 10) (cost: 39063) (transit link) IP: 192.168.0.49 | | ------------------------------ Network: 192.168.0.48/29 | | | Designated Router IP: 192.168.0.49 | | | | | Router ID: 192.168.0.54 | | | Router ID: 192.168.0.53 | Router ID: 192.168.0.52
Summary LSAs are created by ABR s to summarise the destinations available within one area to other areas. These LSAs may describe IP networks, potentially in aggregated form, or ASBR routers.
ospfd accepts all Common Invocation Options.
Specify the instance number for this invocation of ospfd.
Enable the OSPF API server. This is required to use
ospfd must acquire interface information from zebra in order to function. Therefore zebra must be running before invoking ospfd. Also, if zebra is restarted then ospfd must be too.
Like other daemons, ospfd configuration is done in OSPF specific
ospfd.conf when the integrated config is not used.
OSPF supports multiple instances. Each instance is identified by a positive
nonzero integer that must be provided when adding configuration items specific
to that instance. Enabling instances is done with
the following manner:
... ospfd=yes ospfd_instances=1,5,6 ...
ospfd_instances variable controls which instances are started and what
their IDs are. In this example, after starting FRR you should see the following
# ps -ef | grep "ospfd" frr 11816 1 0 17:30 ? 00:00:00 /usr/lib/frr/ospfd --daemon -A 127.0.0.1 -n 1 frr 11822 1 0 17:30 ? 00:00:00 /usr/lib/frr/ospfd --daemon -A 127.0.0.1 -n 2 frr 11828 1 0 17:30 ? 00:00:00 /usr/lib/frr/ospfd --daemon -A 127.0.0.1 -n 3
The instance number should be specified in the config when addressing a particular instance:
router ospf 5 ospf router-id 18.104.22.168 area 0.0.0.0 authentication message-digest ...
To start OSPF process you have to specify the OSPF router.
router ospf [(1-65535)] vrf NAME¶
no router ospf [(1-65535)] vrf NAME¶
Enable or disable the OSPF process.
ospf router-id A.B.C.D¶
no ospf router-id [A.B.C.D]¶
This sets the router-ID of the OSPF process. The router-ID may be an IP address of the router, but need not be - it can be any arbitrary 32bit number. However it MUST be unique within the entire OSPF domain to the OSPF speaker - bad things will happen if multiple OSPF speakers are configured with the same router-ID! If one is not specified then ospfd will obtain a router-ID automatically from zebra.
ospf abr-type TYPE¶
no ospf abr-type TYPE¶
type can be cisco|ibm|shortcut|standard. The “Cisco” and “IBM” types are equivalent.
The OSPF standard for ABR behaviour does not allow an ABR to consider routes through non-backbone areas when its links to the backbone are down, even when there are other ABRs in attached non-backbone areas which still can reach the backbone - this restriction exists primarily to ensure routing-loops are avoided.
With the “Cisco” or “IBM” ABR type, the default in this release of FRR, this restriction is lifted, allowing an ABR to consider summaries learned from other ABRs through non-backbone areas, and hence route via non-backbone areas as a last resort when, and only when, backbone links are down.
Note that areas with fully-adjacent virtual-links are considered to be “transit capable” and can always be used to route backbone traffic, and hence are unaffected by this setting (
area A.B.C.D virtual-link A.B.C.D).
More information regarding the behaviour controlled by this command can be found in RFC 3509, and draft-ietf-ospf-shortcut-abr-02.txt.
Quote: “Though the definition of the ABR in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers.”
no ospf rfc1583compatibility¶
RFC 2328, the successor to RFC 1583, suggests according to section G.2 (changes) in section 16.4 a change to the path preference algorithm that prevents possible routing loops that were possible in the old version of OSPFv2. More specifically it demands that inter-area paths and intra-area backbone path are now of equal preference but still both preferred to external paths.
This command should NOT be set normally.
no log-adjacency-changes [detail]¶
Configures ospfd to log changes in adjacency. With the optional detail argument, all changes in adjacency status are shown. Without detail, only changes to full or regressions are shown.
no passive-interface INTERFACE¶
Do not speak OSPF interface on the given interface, but do advertise the interface as a stub link in the router-LSA for this router. This allows one to advertise addresses on such connected interfaces without having to originate AS-External/Type-5 LSAs (which have global flooding scope) - as would occur if connected addresses were redistributed into OSPF (Redistribution). This is the only way to advertise non-OSPF links into stub areas.
timers throttle spf DELAY INITIAL-HOLDTIME MAX-HOLDTIME¶
no timers throttle spf¶
This command sets the initial delay, the initial-holdtime and the maximum-holdtime between when SPF is calculated and the event which triggered the calculation. The times are specified in milliseconds and must be in the range of 0 to 600000 milliseconds.
The delay specifies the minimum amount of time to delay SPF calculation (hence it affects how long SPF calculation is delayed after an event which occurs outside of the holdtime of any previous SPF calculation, and also serves as a minimum holdtime).
Consecutive SPF calculations will always be separated by at least ‘hold-time’ milliseconds. The hold-time is adaptive and initially is set to the initial-holdtime configured with the above command. Events which occur within the holdtime of the previous SPF calculation will cause the holdtime to be increased by initial-holdtime, bounded by the maximum-holdtime configured with this command. If the adaptive hold-time elapses without any SPF-triggering event occurring then the current holdtime is reset to the initial-holdtime. The current holdtime can be viewed with
show ip ospf, where it is expressed as a multiplier of the initial-holdtime.
router ospf timers throttle spf 200 400 10000
In this example, the delay is set to 200ms, the initial holdtime is set to 400ms and the maximum holdtime to 10s. Hence there will always be at least 200ms between an event which requires SPF calculation and the actual SPF calculation. Further consecutive SPF calculations will always be separated by between 400ms to 10s, the hold-time increasing by 400ms each time an SPF-triggering event occurs within the hold-time of the previous SPF calculation.
This command supersedes the timers spf command in previous FRR releases.
max-metric router-lsa [on-startup|on-shutdown] (5-86400)¶
max-metric router-lsa administrative¶
no max-metric router-lsa [on-startup|on-shutdown|administrative]¶
This enables RFC 3137 support, where the OSPF process describes its transit links in its router-LSA as having infinite distance so that other routers will avoid calculating transit paths through the router while still being able to reach networks through the router.
This support may be enabled administratively (and indefinitely) or conditionally. Conditional enabling of max-metric router-lsas can be for a period of seconds after startup and/or for a period of seconds prior to shutdown.
Enabling this for a period after startup allows OSPF to converge fully first without affecting any existing routes used by other routers, while still allowing any connected stub links and/or redistributed routes to be reachable. Enabling this for a period of time in advance of shutdown allows the router to gracefully excuse itself from the OSPF domain.
Enabling this feature administratively allows for administrative intervention for whatever reason, for an indefinite period of time. Note that if the configuration is written to file, this administrative form of the stub-router command will also be written to file. If ospfd is restarted later, the command will then take effect until manually deconfigured.
Configured state of this feature as well as current status, such as the number of second remaining till on-startup or on-shutdown ends, can be viewed with the
show ip ospfcommand.
auto-cost reference-bandwidth (1-4294967)¶
no auto-cost reference-bandwidth¶
This sets the reference bandwidth for cost calculations, where this bandwidth is considered equivalent to an OSPF cost of 1, specified in Mbits/s. The default is 100Mbit/s (i.e. a link of bandwidth 100Mbit/s or higher will have a cost of 1. Cost of lower bandwidth links will be scaled with reference to this cost).
This configuration setting MUST be consistent across all routers within the OSPF domain.
network A.B.C.D/M area A.B.C.D¶
network A.B.C.D/M area (0-4294967295)¶
no network A.B.C.D/M area A.B.C.D¶
no network A.B.C.D/M area (0-4294967295)¶
This command specifies the OSPF enabled interface(s). If the interface has an address from range 192.168.1.0/24 then the command below enables ospf on this interface so router can provide network information to the other ospf routers via this interface.
router ospf network 192.168.1.0/24 area 0.0.0.0
Prefix length in interface must be equal or bigger (i.e. smaller network) than prefix length in network statement. For example statement above doesn’t enable ospf on interface with address 192.168.1.1/23, but it does on interface with address 192.168.1.129/25.
Note that the behavior when there is a peer address defined on an interface changed after release 0.99.7. Currently, if a peer prefix has been configured, then we test whether the prefix in the network command contains the destination prefix. Otherwise, we test whether the network command prefix contains the local address prefix of the interface.
In some cases it may be more convenient to enable OSPF on a per interface/subnet basis (
ip ospf area AREA [ADDR]).
area A.B.C.D range A.B.C.D/M¶
area (0-4294967295) range A.B.C.D/M¶
no area A.B.C.D range A.B.C.D/M¶
no area (0-4294967295) range A.B.C.D/M¶
Summarize intra area paths from specified area into one Type-3 summary-LSA announced to other areas. This command can be used only in ABR and ONLY router-LSAs (Type-1) and network-LSAs (Type-2) (i.e. LSAs with scope area) can be summarized. Type-5 AS-external-LSAs can’t be summarized - their scope is AS. Summarizing Type-7 AS-external-LSAs isn’t supported yet by FRR.
router ospf network 192.168.1.0/24 area 0.0.0.0 network 10.0.0.0/8 area 0.0.0.10 area 0.0.0.10 range 10.0.0.0/8
With configuration above one Type-3 Summary-LSA with routing info 10.0.0.0/8 is announced into backbone area if area 0.0.0.10 contains at least one intra-area network (i.e. described with router or network LSA) from this range.
area A.B.C.D range IPV4_PREFIX not-advertise¶
no area A.B.C.D range IPV4_PREFIX not-advertise¶
Instead of summarizing intra area paths filter them - i.e. intra area paths from this range are not advertised into other areas. This command makes sense in ABR only.
area A.B.C.D range IPV4_PREFIX substitute IPV4_PREFIX¶
no area A.B.C.D range IPV4_PREFIX substitute IPV4_PREFIX¶
Substitute summarized prefix with another prefix.
router ospf network 192.168.1.0/24 area 0.0.0.0 network 10.0.0.0/8 area 0.0.0.10 area 0.0.0.10 range 10.0.0.0/8 substitute 22.214.171.124/8
One Type-3 summary-LSA with routing info 126.96.36.199/8 is announced into backbone area if area 0.0.0.10 contains at least one intra-area network (i.e. described with router-LSA or network-LSA) from range 10.0.0.0/8. This command makes sense in ABR only.
area A.B.C.D virtual-link A.B.C.D¶
area (0-4294967295) virtual-link A.B.C.D¶
no area A.B.C.D virtual-link A.B.C.D¶
no area (0-4294967295) virtual-link A.B.C.D¶
area A.B.C.D shortcut¶
area (0-4294967295) shortcut¶
no area A.B.C.D shortcut¶
no area (0-4294967295) shortcut¶
Configure the area as Shortcut capable. See RFC 3509. This requires that the ‘abr-type’ be set to ‘shortcut’.
area A.B.C.D stub¶
area (0-4294967295) stub¶
no area A.B.C.D stub¶
no area (0-4294967295) stub¶
Configure the area to be a stub area. That is, an area where no router originates routes external to OSPF and hence an area where all external routes are via the ABR(s). Hence, ABRs for such an area do not need to pass AS-External LSAs (type-5s) or ASBR-Summary LSAs (type-4) into the area. They need only pass Network-Summary (type-3) LSAs into such an area, along with a default-route summary.
area A.B.C.D stub no-summary¶
area (0-4294967295) stub no-summary¶
no area A.B.C.D stub no-summary¶
no area (0-4294967295) stub no-summary¶
Prevents an ospfd ABR from injecting inter-area summaries into the specified stub area.
area A.B.C.D default-cost (0-16777215)¶
no area A.B.C.D default-cost (0-16777215)¶
Set the cost of default-summary LSAs announced to stubby areas.
area A.B.C.D export-list NAME¶
area (0-4294967295) export-list NAME¶
no area A.B.C.D export-list NAME¶
no area (0-4294967295) export-list NAME¶
Filter Type-3 summary-LSAs announced to other areas originated from intra- area paths from specified area.
router ospf network 192.168.1.0/24 area 0.0.0.0 network 10.0.0.0/8 area 0.0.0.10 area 0.0.0.10 export-list foo ! access-list foo permit 10.10.0.0/16 access-list foo deny any
With example above any intra-area paths from area 0.0.0.10 and from range 10.10.0.0/16 (for example 10.10.1.0/24 and 10.10.2.128/30) are announced into other areas as Type-3 summary-LSA’s, but any others (for example 10.11.0.0/16 or 10.128.30.16/30) aren’t.
This command is only relevant if the router is an ABR for the specified area.
area A.B.C.D import-list NAME¶
area (0-4294967295) import-list NAME¶
no area A.B.C.D import-list NAME¶
no area (0-4294967295) import-list NAME¶
Same as export-list, but it applies to paths announced into specified area as Type-3 summary-LSAs.
area A.B.C.D filter-list prefix NAME in¶
area A.B.C.D filter-list prefix NAME out¶
area (0-4294967295) filter-list prefix NAME in¶
area (0-4294967295) filter-list prefix NAME out¶
no area A.B.C.D filter-list prefix NAME in¶
no area A.B.C.D filter-list prefix NAME out¶
no area (0-4294967295) filter-list prefix NAME in¶
no area (0-4294967295) filter-list prefix NAME out¶
Filtering Type-3 summary-LSAs to/from area using prefix lists. This command makes sense in ABR only.
area A.B.C.D authentication¶
area (0-4294967295) authentication¶
no area A.B.C.D authentication¶
no area (0-4294967295) authentication¶
Specify that simple password authentication should be used for the given area.
area A.B.C.D authentication message-digest¶
area (0-4294967295) authentication message-digest¶
Specify that OSPF packets must be authenticated with MD5 HMACs within the given area. Keying material must also be configured on a per-interface basis (
ip ospf message-digest-key).
MD5 authentication may also be configured on a per-interface basis (
ip ospf authentication message-digest). Such per-interface settings will override any per-area authentication setting.
ip ospf area AREA [ADDR]¶
no ip ospf area [ADDR]¶
Enable OSPF on the interface, optionally restricted to just the IP address given by ADDR, putting it in the AREA area. Per interface area settings take precedence to network commands (
network A.B.C.D/M area A.B.C.D).
If you have a lot of interfaces, and/or a lot of subnets, then enabling OSPF via this command may result in a slight performance improvement.
ip ospf authentication-key AUTH_KEY¶
no ip ospf authentication-key¶
Set OSPF authentication key to a simple password. After setting AUTH_KEY, all OSPF packets are authenticated. AUTH_KEY has length up to 8 chars.
Simple text password authentication is insecure and deprecated in favour of MD5 HMAC authentication.
ip ospf authentication message-digest¶
Specify that MD5 HMAC authentication must be used on this interface. MD5 keying material must also be configured. Overrides any authentication enabled on a per-area basis (
area A.B.C.D authentication message-digest)
Note that OSPF MD5 authentication requires that time never go backwards (correct time is NOT important, only that it never goes backwards), even across resets, if ospfd is to be able to promptly reestablish adjacencies with its neighbours after restarts/reboots. The host should have system time be set at boot from an external or non-volatile source (e.g. battery backed clock, NTP, etc.) or else the system clock should be periodically saved to non-volatile storage and restored at boot if MD5 authentication is to be expected to work reliably.
ip ospf message-digest-key KEYID md5 KEY¶
no ip ospf message-digest-key¶
Set OSPF authentication key to a cryptographic password. The cryptographic algorithm is MD5.
KEYID identifies secret key used to create the message digest. This ID is part of the protocol and must be consistent across routers on a link.
KEY is the actual message digest key, of up to 16 chars (larger strings will be truncated), and is associated with the given KEYID.
ip ospf cost (1-65535)¶
no ip ospf cost¶
Set link cost for the specified interface. The cost value is set to router-LSA’s metric field and used for SPF calculation.
ip ospf dead-interval (1-65535)¶
ip ospf dead-interval minimal hello-multiplier (2-20)¶
no ip ospf dead-interval¶
Set number of seconds for RouterDeadInterval timer value used for Wait Timer and Inactivity Timer. This value must be the same for all routers attached to a common network. The default value is 40 seconds.
If ‘minimal’ is specified instead, then the dead-interval is set to 1 second and one must specify a hello-multiplier. The hello-multiplier specifies how many Hellos to send per second, from 2 (every 500ms) to 20 (every 50ms). Thus one can have 1s convergence time for OSPF. If this form is specified, then the hello-interval advertised in Hello packets is set to 0 and the hello-interval on received Hello packets is not checked, thus the hello-multiplier need NOT be the same across multiple routers on a common link.
ip ospf hello-interval (1-65535)¶
no ip ospf hello-interval¶
Set number of seconds for HelloInterval timer value. Setting this value, Hello packet will be sent every timer value seconds on the specified interface. This value must be the same for all routers attached to a common network. The default value is 10 seconds.
This command has no effect if
ip ospf dead-interval minimal hello-multiplier (2-20)is also specified for the interface.
ip ospf network (broadcast|non-broadcast|point-to-multipoint|point-to-point)¶
When configuring a point-to-point network on an interface and the interface has a /32 address associated with then OSPF will treat the interface as being unnumbered. If you are doing this you must set the net.ipv4.conf.<interface name>.rp_filter value to 0. In order for the ospf multicast packets to be delivered by the kernel.
no ip ospf network¶
Set explicitly network type for specified interface.
ip ospf priority (0-255)¶
no ip ospf priority¶
Set RouterPriority integer value. The router with the highest priority will be more eligible to become Designated Router. Setting the value to 0, makes the router ineligible to become Designated Router. The default value is 1.
ip ospf retransmit-interval (1-65535)¶
no ip ospf retransmit interval¶
Set number of seconds for RxmtInterval timer value. This value is used when retransmitting Database Description and Link State Request packets. The default value is 5 seconds.
ip ospf transmit-delay¶
no ip ospf transmit-delay¶
Set number of seconds for InfTransDelay value. LSAs’ age should be incremented by this value when transmitting. The default value is 1 second.
ip ospf area (A.B.C.D|(0-4294967295))¶
no ip ospf area¶
Enable ospf on an interface and set associated area.
Usage of ospfd’s route-map support.
set metric [+|-](0-4294967295)¶
Set a metric for matched route when sending announcement. Use plus (+) sign to add a metric value to an existing metric. Use minus (-) sign to substract a metric value from an existing metric.
redistribute (kernel|connected|static|rip|bgp) ROUTE-MAP¶
redistribute (kernel|connected|static|rip|bgp) metric-type (1|2)¶
redistribute (kernel|connected|static|rip|bgp) metric-type (1|2) route-map WORD¶
redistribute (kernel|connected|static|rip|bgp) metric (0-16777214)¶
redistribute (kernel|connected|static|rip|bgp) metric (0-16777214) route-map WORD¶
redistribute (kernel|connected|static|rip|bgp) metric-type (1|2) metric (0-16777214)¶
redistribute (kernel|connected|static|rip|bgp) metric-type (1|2) metric (0-16777214) route-map WORD¶
no redistribute (kernel|connected|static|rip|bgp)¶
Redistribute routes of the specified protocol or kind into OSPF, with the metric type and metric set if specified, filtering the routes using the given route-map if specified. Redistributed routes may also be filtered with distribute-lists, see ospf distribute-list configuration.
Redistributed routes are distributed as into OSPF as Type-5 External LSAs into links to areas that accept external routes, Type-7 External LSAs for NSSA areas and are not redistributed at all into Stub areas, where external routes are not permitted.
Note that for connected routes, one may instead use the passive-interface configuration.
default-information originate metric (0-16777214)¶
default-information originate metric (0-16777214) metric-type (1|2)¶
default-information originate metric (0-16777214) metric-type (1|2) route-map WORD¶
default-information originate always¶
default-information originate always metric (0-16777214)¶
default-information originate always metric (0-16777214) metric-type (1|2)¶
default-information originate always metric (0-16777214) metric-type (1|2) route-map WORD¶
no default-information originate¶
Originate an AS-External (type-5) LSA describing a default route into all external-routing capable areas, of the specified metric and metric type. If the ‘always’ keyword is given then the default is always advertised, even when there is no default present in the routing table.
distribute-list NAME out (kernel|connected|static|rip|ospf¶
no distribute-list NAME out (kernel|connected|static|rip|ospf¶
Apply the access-list filter, NAME, to redistributed routes of the given type before allowing the routes to redistributed into OSPF (ospf redistribution).
no distance (1-255)¶
distance ospf (intra-area|inter-area|external) (1-255)¶
no distance ospf¶
no router zebra¶
show ip ospf¶
Show information on a variety of general OSPF and area state and configuration information.
show ip ospf interface [INTERFACE]¶
Show state and configuration of OSPF the specified interface, or all interfaces if no interface is given.
show ip ospf neighbor¶
show ip ospf neighbor INTERFACE¶
show ip ospf neighbor detail¶
show ip ospf neighbor INTERFACE detail¶
show ip ospf database¶
show ip ospf database (asbr-summary|external|network|router|summary)¶
show ip ospf database (asbr-summary|external|network|router|summary) LINK-STATE-ID¶
show ip ospf database (asbr-summary|external|network|router|summary) LINK-STATE-ID adv-router ADV-ROUTER¶
show ip ospf database (asbr-summary|external|network|router|summary) adv-router ADV-ROUTER¶
show ip ospf database (asbr-summary|external|network|router|summary) LINK-STATE-ID self-originate¶
show ip ospf database (asbr-summary|external|network|router|summary) self-originate¶
show ip ospf database max-age¶
show ip ospf database self-originate¶
show ip ospf route¶
Show the OSPF routing table, as determined by the most recent SPF calculation.
no ospf opaque-lsa¶
no capability opaque¶
ospfd supports Opaque LSA (RFC 2370) as partial support for MPLS Traffic Engineering LSAs. The opaque-lsa capability must be enabled in the configuration. An alternate command could be “mpls-te on” (Traffic Engineering). Note that FRR offers only partial support for some of the routing protocol extensions that are used with MPLS-TE; it does not support a complete RSVP-TE solution.
show ip ospf database (opaque-link|opaque-area|opaque-external)¶
show ip ospf database (opaque-link|opaque-area|opaque-external) LINK-STATE-ID¶
show ip ospf database (opaque-link|opaque-area|opaque-external) LINK-STATE-ID adv-router ADV-ROUTER¶
show ip ospf database (opaque-link|opaque-area|opaque-external) adv-router ADV-ROUTER¶
show ip ospf database (opaque-link|opaque-area|opaque-external) LINK-STATE-ID self-originate¶
show ip ospf database (opaque-link|opaque-area|opaque-external) self-originate¶
Show Opaque LSA from the database.
At this time, FRR offers partial support for some of the routing protocol extensions that can be used with MPLS-TE. FRR does not support a complete RSVP-TE solution currently.
Enable Traffic Engineering LSA flooding.
mpls-te router-address <A.B.C.D>¶
Configure stable IP address for MPLS-TE. This IP address is then advertise in Opaque LSA Type-10 TLV=1 (TE) option 1 (Router-Address).
mpls-te inter-as area <area-id>|as¶
no mpls-te inter-as¶
Enable RFC 5392 support - Inter-AS TE v2 - to flood Traffic Engineering parameters of Inter-AS link. 2 modes are supported: AREA and AS; LSA are flood in AREA <area-id> with Opaque Type-10, respectively in AS with Opaque Type-11. In all case, Opaque-LSA TLV=6.
show ip ospf mpls-te interface¶
show ip ospf mpls-te interface INTERFACE¶
Show MPLS Traffic Engineering parameters for all or specified interface.
show ip ospf mpls-te router¶
Show Traffic Engineering router parameters.
router-info [as | area]¶
Enable Router Information (RFC 4970) LSA advertisement with AS scope (default) or Area scope flooding when area is specified. Old syntax router-info area <A.B.C.D> is always supported but mark as deprecated as the area ID is no more necessary. Indeed, router information support multi-area and detect automatically the areas.
pce address <A.B.C.D>¶
no pce address¶
pce domain as (0-65535)¶
no pce domain as (0-65535)¶
pce neighbor as (0-65535)¶
no pce neighbor as (0-65535)¶
pce flag BITPATTERN¶
no pce flag¶
pce scope BITPATTERN¶
no pce scope¶
The commands are conform to RFC 5088 and allow OSPF router announce Path Computation Element (PCE) capabilities through the Router Information (RI) LSA. Router Information must be enable prior to this. The command set/unset respectively the PCE IP address, Autonomous System (AS) numbers of controlled domains, neighbor ASs, flag and scope. For flag and scope, please refer to :rfc`5088` for the BITPATTERN recognition. Multiple ‘pce neighbor’ command could be specified in order to specify all PCE neighbours.
show ip ospf router-info¶
Show Router Capabilities flag.
show ip ospf router-info pce¶
Show Router Capabilities PCE parameters.
This is an EXPERIMENTAL support of Segment Routing as per draft draft-ietf-ospf-segment-routing-extensions-24.txt for MPLS dataplane.
[no] segment-routing on¶
Enable Segment Routing. Even if this also activate routing information support, it is preferable to also activate routing information, and set accordingly the Area or AS flooding.
[no] segment-routing global-block (0-1048575) (0-1048575)¶
Fix the Segment Routing Global Block i.e. the label range used by MPLS to store label in the MPLS FIB.
[no] segment-routing node-msd (1-16)¶
Fix the Maximum Stack Depth supported by the router. The value depend of the MPLS dataplane. E.g. for Linux kernel, since version 4.13 it is 32.
[no] segment-routing prefix A.B.C.D/M index (0-65535) [no-php-flag]¶
Set the Segment Routing index for the specified prefix. Note that, only prefix with /32 corresponding to a loopback interface are currently supported. The ‘no-php-flag’ means NO Penultimate Hop Popping that allows SR node to request to its neighbor to not pop the label.
show ip ospf database segment-routing <adv-router ADVROUTER|self-originate> [json]¶
Show Segment Routing Data Base, all SR nodes, specific advertised router or self router. Optional JSON output can be obtained by appending ‘json’ to the end of the command.
debug ospf packet (hello|dd|ls-request|ls-update|ls-ack|all) (send|recv) [detail]¶
no debug ospf packet (hello|dd|ls-request|ls-update|ls-ack|all) (send|recv) [detail]¶
Dump Packet for debugging
debug ospf ism¶
debug ospf ism (status|events|timers)¶
no debug ospf ism¶
no debug ospf ism (status|events|timers)¶
Show debug information of Interface State Machine
debug ospf nsm¶
debug ospf nsm (status|events|timers)¶
no debug ospf nsm¶
no debug ospf nsm (status|events|timers)¶
Show debug information of Network State Machine
debug ospf event¶
no debug ospf event¶
Show debug information of OSPF event
debug ospf nssa¶
no debug ospf nssa¶
Show debug information about Not So Stub Area
debug ospf lsa¶
debug ospf lsa (generate|flooding|refresh)¶
no debug ospf lsa¶
no debug ospf lsa (generate|flooding|refresh)¶
Show debug detail of Link State messages
debug ospf te¶
no debug ospf te¶
Show debug information about Traffic Engineering LSA
debug ospf zebra¶
debug ospf zebra (interface|redistribute)¶
no debug ospf zebra¶
no debug ospf zebra (interface|redistribute)¶
Show debug information of ZEBRA API
show debugging ospf¶
OSPF Configuration Examples¶
A simple example, with MD5 authentication enabled:
! interface bge0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 ABCDEFGHIJK ! router ospf network 192.168.0.0/16 area 0.0.0.1 area 0.0.0.1 authentication message-digest
An ABR router, with MD5 authentication and performing summarisation of networks between the areas:
! password ABCDEF log file /var/log/frr/ospfd.log service advanced-vty ! interface eth0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 ABCDEFGHIJK ! interface ppp0 ! interface br0 ip ospf authentication message-digest ip ospf message-digest-key 2 md5 XYZ12345 ! router ospf ospf router-id 192.168.0.1 redistribute connected passive interface ppp0 network 192.168.0.0/24 area 0.0.0.0 network 10.0.0.0/16 area 0.0.0.0 network 192.168.1.0/24 area 0.0.0.1 area 0.0.0.0 authentication message-digest area 0.0.0.0 range 10.0.0.0/16 area 0.0.0.0 range 192.168.0.0/24 area 0.0.0.1 authentication message-digest area 0.0.0.1 range 10.2.0.0/16 !
A Traffic Engineering configuration, with Inter-ASv2 support.
interface eth0 ip address 188.8.131.52/24 link-params enable admin-grp 0xa1 metric 100 max-bw 1.25e+07 max-rsv-bw 1.25e+06 unrsv-bw 0 1.25e+06 unrsv-bw 1 1.25e+06 unrsv-bw 2 1.25e+06 unrsv-bw 3 1.25e+06 unrsv-bw 4 1.25e+06 unrsv-bw 5 1.25e+06 unrsv-bw 6 1.25e+06 unrsv-bw 7 1.25e+06 ! interface eth1 ip address 192.168.2.1/24 link-params enable metric 10 max-bw 1.25e+07 max-rsv-bw 1.25e+06 unrsv-bw 0 1.25e+06 unrsv-bw 1 1.25e+06 unrsv-bw 2 1.25e+06 unrsv-bw 3 1.25e+06 unrsv-bw 4 1.25e+06 unrsv-bw 5 1.25e+06 unrsv-bw 6 1.25e+06 unrsv-bw 7 1.25e+06 neighbor 192.168.2.2 as 65000 hostname HOSTNAME password PASSWORD log file /var/log/zebra.log ! interface eth0 ip address 184.108.40.206/24 link-params enable admin-grp 0xa1 metric 100 max-bw 1.25e+07 max-rsv-bw 1.25e+06 unrsv-bw 0 1.25e+06 unrsv-bw 1 1.25e+06 unrsv-bw 2 1.25e+06 unrsv-bw 3 1.25e+06 unrsv-bw 4 1.25e+06 unrsv-bw 5 1.25e+06 unrsv-bw 6 1.25e+06 unrsv-bw 7 1.25e+06 ! interface eth1 ip address 192.168.2.1/24 link-params enable metric 10 max-bw 1.25e+07 max-rsv-bw 1.25e+06 unrsv-bw 0 1.25e+06 unrsv-bw 1 1.25e+06 unrsv-bw 2 1.25e+06 unrsv-bw 3 1.25e+06 unrsv-bw 4 1.25e+06 unrsv-bw 5 1.25e+06 unrsv-bw 6 1.25e+06 unrsv-bw 7 1.25e+06 neighbor 192.168.2.2 as 65000
hostname HOSTNAME password PASSWORD log file /var/log/ospfd.log ! ! interface eth0 ip ospf hello-interval 60 ip ospf dead-interval 240 ! interface eth1 ip ospf hello-interval 60 ip ospf dead-interval 240 ! ! router ospf ospf router-id 192.168.1.1 network 192.168.0.0/16 area 1 ospf opaque-lsa mpls-te mpls-te router-address 192.168.1.1 mpls-te inter-as area 1 ! line vty
A router information example with PCE advertisement:
! router ospf ospf router-id 192.168.1.1 network 192.168.0.0/16 area 1 capability opaque mpls-te mpls-te router-address 192.168.1.1 router-info area 0.0.0.1 pce address 192.168.1.1 pce flag 0x80 pce domain as 65400 pce neighbor as 65500 pce neighbor as 65200 pce scope 0x80 !