OSPF is Interior Gateway Protocol (IGP) designed to distribute routing information between routers belonging to the same Autonomous System (AS).
The protocol is based on link-state technology that has several advantages over distance-vector protocols such as RIP:
However, there are a few disadvantages:
RouterOS implements the following standards:
Before we move on let's familiarise ourselves with terms important for understanding the operation of the OSPF. These terms will be used throughout the article.
To start OSPF v2 and v3 instances, the first thing to do is to add the instance and the backbone area:
At this point, we can add a template. The template is used to match interfaces on which OSPF should be running, it can be done either by specifying the network or interface directly.
Link state database describes the routers and links that interconnect them and are appropriate for forwarding. It also contains the cost (metric) of each link. This metric is used to calculate the shortest path to the destination network.
Each router can advertise a different cost for the router's own link direction, making it possible to have asymmetric links (packets to the destination travel over one path, but the response travels a different path). Asymmetric paths are not very popular, because it makes it harder to find routing problems.
The Cost in RouterOS is set to 10 on all interfaces by default. Value can be changed in the OSPF interface template configuration menu, for example, to add an ether2 interface with a cost of 100:
The cost of an interface on Cisco routers is inversely proportional to the bandwidth of that interface. A higher bandwidth indicates a lower cost. If similar costs are necessary on RouterOS, then use the following formula:
Cost = 100000000/bw in bps.
OSPF router is using Dijkstra's Shortest Path First (SPF) algorithm to calculate the shortest path. The algorithm places the router at the root of a tree and calculates the shortest path to each destination based on the cumulative cost required to reach the destination. Each router calculates its own tree even though all routers are using the same link-state database.
Assume we have the following network. The network consists of 4(four) routers. OSPF costs for outgoing interfaces are shown near the line that represents the link. In order to build the shortest-path tree for router R1, we need to make R1 the root and calculate the smallest cost for each destination.
As you can see from the image above multiple shortest paths have been found to the 172.16.1.0 network, allowing load balancing of the traffic to that destination called equal-cost multipath (ECMP). After the shortest-path tree is built, a router starts to build the routing table accordingly. Networks are reached consequently to the cost calculated in the tree.
Routing table calculation looks quite simple, however, when some of the OSPF extensions are used or OSPF areas are calculated, routing calculation gets more complicated.
OSPF is a link-state protocol that assumes that the interface of the router is considered an OSPF link. Whenever OSPF is started, it adds the state of all the links in the local link-state database.
There are several steps before the OSPF network becomes fully functional:
Link-state routing protocols are distributing and replicating database that describes the routing topology. The link-state protocol's flooding algorithm ensures that each router has an identical link-state database and the routing table is calculated based on this database.
After all the steps above are completed link-state database on each neighbor contains full routing domain topology (how many other routers are in the network, how many interfaces routers have, what networks link between router connects, cost of each link, and so on).
OSPF operates over the IP network layer using protocol number 89.
A destination IP address is set to the neighbor's IP address or to one of the OSPF multicast addresses AllSPFRouters (126.96.36.199) or AllDRRouters (188.8.131.52). The use of these addresses is described later in this article.
Every OSPF packet begins with a standard 24-byte header.
|Packet type||There are several types of OSPF packets: Hello packet, Database Description (DD) packet, Link state request packet, Link State Update packet, and Link State Acknowledgement packet. All of these packets except the Hello packet are used in link-state database synchronization.|
|Router ID||one of the router's IP addresses unless configured manually|
|Area ID||Allows OSPF router to associate the packet to the proper OSPF area.|
|Checksum||Allows receiving router to determine if a packet was damaged in transit.|
|Authentication fields||These fields allow the receiving router to verify that the packet's contents were not modified and that packet really came from the OSPF router whose Router ID appears in the packet.|
There are five different OSPF packet types used to ensure proper LSA flooding over the OSPF network.
OSPF discovers potential neighbors by periodically sending Hello packets out of configured interfaces. By default Hello packets are sent out at 10-second intervals which can be changed by setting hello-interval in OSPF interface settings. The router learns the existence of a neighboring router when it receives the neighbor's Hello in return with matching parameters.
The transmission and reception of Hello packets also allow a router to detect the failure of the neighbor. If Hello packets are not received within dead-interval (which by default is 40 seconds) router starts to route packets around the failure. "Hello" protocol ensures that the neighboring routers agree on the Hello interval and Dead interval parameters, preventing situations when not in time received Hello packets mistakenly bring the link down.
|network mask||The IP mask of the originating router's interface IP address.|
|hello interval||the period between Hello packets (default 10s)|
|options||OSPF options for neighbor information|
|router priority||an 8-bit value used to aid in the election of the DR and BDR. (Not set in p2p links)|
|router dead interval||time interval has to be received before considering the neighbor is down. ( By default four times bigger than Hello interval)|
|DR||the router-id of the current DR|
|BDR||the router-id of the current BDR|
|Neighbor router IDs||a list of router ids for all the originating router's neighbors|
On each type of network segment Hello protocol works a little differently. It is clear that on point-to-point segments only one neighbor is possible and no additional actions are required. However, if more than one neighbor can be on the segment additional actions are taken to make OSPF functionality even more efficient.
Two routers do not become neighbors unless the following conditions are met.
Network mask, Priority, DR, and BDR fields are used only when the neighbors are connected by a broadcast or NBMA network segment.
The attached node to the broadcast subnet can send a single packet and that packet is received by all other attached nodes. This is very useful for auto-configuration and information replication. Another useful capability in broadcast subnets is multicast. This capability allows sending a single packet which will be received by nodes configured to receive multicast packets. OSPF is using this capability to find OSPF neighbors and detect bidirectional connectivity.
Consider the Ethernet network illustrated in the image below.
!!!!!!bilde!!!!!! OSPF Broadcast network
Each OSPF router joins the IP multicast group AllSPFRouters (184.108.40.206), then the router periodically multicasts its Hello packets to the IP address 220.127.116.11. All other routers that joined the same group will receive a multicasted Hello packet. In that way, OSPF routers maintain relationships with all other OSPF routers by sending a single packet instead of sending a separate packet to each neighbor on the segment.
This approach has several advantages:
Automatic neighbor discovery by multicasting or broadcasting Hello packets. Less bandwidth usage compared to other subnet types. On the broadcast segment, there are n*(n-1)/2 neighbor relations, but those relations are maintained by sending only n Hellos. If broadcast has the multicast capability, then OSPF operates without disturbing non-OSPF nodes on the broadcast segment. If the multicast capability is not supported all routers will receive broadcasted Hello packet even if the node is not an OSPF router.
Non-broadcast multiaccess (NBMA) segments are similar to broadcast. Support more than two routers, the only difference is that NBMA does not support a data-link broadcast capability. Due to this limitation, OSPF neighbors must be discovered initially through configuration. On RouterOS static neighbor configuration is set in the
/routing ospf static-neighbor menu. To reduce the amount of Hello traffic, most routers attached to the NBMA subnet should be assigned Router Priority of 0 (set by default in RouterOS). Routers that are eligible to become Designated Routers should have priority values other than 0. It ensures that during the election of DR and BDR Hellos are sent only to eligible routers.
Point-to-MultiPoint treats the network as a collection of point-to-point links.
By design, PTMP networks should not have broadcast capabilities, which means that OSPF neighbors (the same way as for NBMA networks) must be discovered initially through configuration and all communication happens by sending unicast packets directly between neighbors. On RouterOS static neighbor configuration is set in the
/routing ospf static-neighbor menu. Designated Routers and Backup Designated Routers are not elected on Point-to-multipoint subnets.
For PTMP networks that do support broadcast, a hybrid type named "ptmp-broadcast" can be used. This network type uses multicast Hellos to discover neighbors automatically and detect bidirectional communication between neighbors. After neighbor detection "ptmp-broacast" sends unicast packets directly to the discovered neighbors. This mode is compatible with the RouterOS v6 "ptmp" type.
Before database synchronization can begin, a hierarchy order of exchanging information must be established, which determines which router sends Database Descriptor (DD) packets first (Master). The master router is elected based on the highest priority and if priority is not set then router ID will be used. Note that it is a router priority-based relation to arranging the exchanging data between neighbors which does not affect DR/BDR election (meaning that DR does not always have to be Master).
Link-state Database synchronization between OSPF routers is very important. Unsynchronized databases may lead to incorrectly calculated routing tables which could cause routing loops or black holes.
There are two types of database synchronizations:
When the connection between two neighbors first comes up, initial database synchronization will happen. OSPF is using explicit database download when neighbor connections first come up. This procedure is called Database exchange. Instead of sending the entire database, the OSPF router sends only its LSA headers in a sequence of OSPF Database Description (DD) packets. The router will send the next DD packet only when the previous packet is acknowledged. When an entire sequence of DD packets has been received, the router knows which LSAs it does not have and which LSAs are more recent. The router then sends Link-State Request (LSR) packets requesting desired LSAs, and the neighbor responds by flooding LSAs in Link-State Update (LSU) packets. After all the updates are received neighbors are said to be fully adjacent.
Reliable flooding is another database synchronization method. It is used when adjacencies are already established and the OSPF router wants to inform other routers about LSA changes. When the OSPF router receives such Link State Update, it installs a new LSA in the link-state database, sends an acknowledgment packet back to the sender, repackages LSA in new LSU, and sends it out to all interfaces except the one that received the LSA in the first place.
OSPF determines if LSAs are up to date by comparing sequence numbers. Sequence numbers start with 0×80000001, the larger the number, the more recent the LSA is. A sequence number is incremented each time the record is flooded and the neighbor receiving the update resets the Maximum age timer. LSAs are refreshed every 30 minutes, but without a refresh, LSA remains in the database for the maximum age of 60 minutes.
Databases are not always synchronized between all OSPF neighbors, OSPF decides whether databases need to be synchronized depending on the network segment, for example, on point-to-point links databases are always synchronized between routers, but on Ethernet networks databases are synchronized between certain neighbor pairs.
On the broadcast segment, there are n*(n-1)/2 neighbor relations, it will be a huge amount of Link State Updates and Acknowledgements sent over the subnet if the OSPF router will try to synchronize with each OSPF router on the subnet.
This problem is solved by electing one Designated Router and one Backup Designated Router for each broadcast subnet. All other routers are synchronizing and forming adjacencies only with those two elected routers. This approach reduces the number of adjacencies from n*(n-1)/2 to only 2n-3.
The image on the right illustrates adjacency formations on broadcast subnets. Routers R1 and R2 are Designated Routers and Backup Designated routers respectively. For example, if R3 wants to flood Link State Update (LSU) to both R1 and R2, a router sends LSU to IP multicast address AllDRouters (18.104.22.168) and only DR and BDR listen to this multicast address. Then Designated Router sends LSU addressed to AllSPFRouters, updating the rest of the routers.
DR and BDR routers are elected from data received in the Hello packet. The first OSPF router on a subnet is always elected as Designated Router, when a second router is added it becomes Backup Designated Router. When an existing DR or BDR fails new DR or BDR is elected to take into account configured router priority. The router with the highest priority becomes the new DR or BDR.
Being Designated Router or Backup Designated Router consumes additional resources. If Router Priority is set to 0, then the router is not participating in the election process. This is very useful if certain slower routers are not capable of being DR or BDR.
Database synchronization on NBMA networks is similar to on broadcast networks. DR and BDR are elected, databases initially are exchanged only with DR and BDR routers and flooding always goes through the DR. The only difference is that Link State Updates must be replicated and sent to each adjacent router separately.
On PTMP subnets OSPF router becomes adjacent to all other routes with which it can communicate directly.
A distinctive feature of OSPF is the possibility to divide AS into multiple routing Areas which contain their own set of neighbors.
Imagine a large network with 300+ routers and multiple links between them. Whenever link flaps or some other topology change happens in the network, this change will be flooded to all OSPF devices in the network resulting in a quite heavy load on the network and even downtime since network convergence may take some time for such a large network.
A large single area network can produce serious issues:
The introduction of areas allows for better resource management since topology change inside one area is not flooded to other areas in the network. The concept of areas enables simplicity in network administration as well as routing summarization between areas significantly reducing the database size that needs to be stored on each OSPF neighbor. This means that each area has its own link-state database and corresponding shortest-path tree.
The structure of an area is invisible to other areas. This isolation of knowledge makes the protocol more scalable if multiple areas are used; routing table calculation takes fewer CPU resources and routing traffic is reduced.
However, multi-area setups create additional complexity. It is not recommended to separate areas with fewer than 50 routers. The maximum number of routers in one area is mostly dependent on the CPU power you have for routing table calculation.
OSPF area has unique 32-bit identification (Area ID) and the area with an Area ID of 0.0.0.0 (called the Backbone area) is the main one where any other area should connect. Routers that connect to more than one area are called ABR (Area Border Routers), their main responsibility is summarization and update suppression between connected areas. The router connecting to another routing domain is called ASBR (Autonomous System Boundary Router).
Each area has its own link-state database, consisting of router-LSAs and network-LSAs describing how all routers within that area are interconnected. Detailed knowledge of the area's topology is hidden from all other areas; router-LSAs and network-LSAs are not flooded beyond the area's borders. Area Border Routers (ABRs) leak addressing information from one area into another in OSPF summary-LSAs. This allows to pick the best area border router when forwarding data to destinations from another area and is called intra-area routing.
Routing information exchange between areas is essentially a Distance Vector algorithm and to prevent algorithm convergence problems, such as counting to infinity, all areas are required to attach directly to the backbone area making a simple hub-and-spoke topology. Area-ID of the backbone area is always 0.0.0.0 and can not be changed.
RouterOS area configuration is done in the
/routing/ospf/area menu. For example, a configuration of an ABR router with multiple attached areas, one Stub area, and one default area:
OSPF can have 5 types of areas. Each area type defines what type of LSAs the area supports:
Before we continue a detailed look at each area type, let's get familiar with LSA types:
If we do not have any ASBR, there are no LSA Types 4 and 5 in the network.
This area supports 1, 2, 3, 4, and 5 LSAs.
Simple multi-area network using default area. In this example, all networks from area1 are flooded to the backbone and all networks from the backbone are flooded to area1.
The main purpose of stub areas is to keep such areas from carrying external routes. Routing from these areas to the outside world is based on a default route. Stub area reduces the database size inside an area and reduces the memory requirements of routers in the area.
The stub area has a few restrictions, ASBR routers cannot be internal to the area, stub area cannot be used as a transit area for virtual links. The restrictions are made because the stub area is mainly configured not to carry external routes.
This area supports 1, 2, and 3 LSAs.
Let's consider the example above. Area1 is configured as a stub area meaning that routers R2 and R3 will not receive any routing information from the backbone area except the default route.
Totally stubby area is an extension of the stub area. A totally stubby area blocks external routes and summarized (inter-area) routes from going into the area. Only intra-area routes are injected into the area. Totally stubby area is configured as a stub area with an additional
no-summaries flag. This area supports Type 1, Type 2 LSAs, and Type 3 LSAs with default routes.
Not-so-stubby area (NSSA) is useful when it is required to inject external routes, but injection of type 5 LSA routes is not required.
The illustration shows two areas (backbone and area1) and RIP connection to the router located in "area1". We need "area1" to be configured as a stub area, but it is also required to inject external RIP routes in the backbone. Area1 should be configured as NSSA in this case.
The configuration example does not cover RIP configuration.
Virtual links cannot be used over NSSA areas.
On the edge of an OSPF routing domain, you can find routers called AS boundary routers (ASBRs) that run one of the other routing protocols. The job of those routers is to import routing information learned from other routing protocols into the OSPF routing domain. External routes can be imported at two separate levels depending on the metric type.
External routes can be imported via the instance
redistribute parameter. The example below will pick and redistribute all static and RIP routes:
Redistribution of default route is a special case where the
originate-default the parameter should be used:
Since redistribution is controlled by "
originate-default" and "
redistribute" parameter, it introduces some corner-cases for default route filtering.
redistributeis enabled, then pick all routes matching redistribute parameters
originate-default=never, default route will be rejected
originate-defaultis set to
out-filter-chainwhere attributes can be applied, but action is ignored (always accept);
For a complete list of redistribution values, see the reference manual.
Route summarization is a consolidation of multiple routes into one single advertisement. It is normally done at the area boundaries (Area Border Routers).
It is better to summarise in the direction of the backbone. That way the backbone receives all the aggregated routes and injects them into other areas already summarised. There are two types of summarization: inter-area and external route summarization.
Inter-area route summarization works on area boundaries (ABRs), it does not apply to external routes injected into OSPF via redistribution. By default, ABR creates a summary LSA for each route in a specific area and advertises it in adjacent areas.
Using ranges allows for creating only one summary LSA for multiple routes and sending only a single advertisement into adjacent areas, or suppressing advertisements altogether.
If a range is configured with the '
advertise' parameter, a single summary LSA is advertised for each range if there are any routes under the range in the specific area. Otherwise (when '
advertise' parameter disabled) no summary LSAs are created and advertised outside area boundaries at all.
Inter-area route summarization can be configured from OSPF area range menu.
Let's consider that we have two areas backbone and area1, area1 has several /24 routes from the 10.0.0.0/16 range and there is no need to flood the backbone area with each /24 subnet if it can be summarised. On the router connecting area1 with the backbone we can set up area range:
For an active range (i.e. one that has at least one OSPF route from the specified area falling under it), a route with the type 'blackhole' is created and installed in the routing table.
External route summarization can be achieved using routing filters. Let's consider the same example as above except that area1 has redistributed /24 routes from other protocols. To send a single summarised LSA, a blackhole route must be added and an appropriate routing filter to accept only summarised route:
As it was mentioned previously all OSPF areas have to be attached to the backbone area, but sometimes the physical connection is not possible. To overcome this, areas can be attached logically by using virtual links.
There are two common scenarios when virtual links can be used:
OSPF allows to linking of discontinuous parts of the backbone area using virtual links. This might be required when two separate OSPF networks are merged into one large network. Virtual links can be configured between separate ABRs that touch the backbone area from each side and have a common area.
The additional area could be created to become a transit area when a common area does not exist, it is illustrated in the image above.
Virtual Links are not required for non-backbone areas when they get partitioned. OSPF does not actively attempt to repair area partitions, each component simply becomes a separate area, when an area becomes partitioned. The backbone performs routing between the new areas. Some destinations are reachable via intra-area routing, the area partition requires inter-area routing.
However, to maintain full routing after the partition, an address range has not to be split across multiple components of the area partition.
The area may not have a physical connection to the backbone, a virtual link is used to provide a logical path to the backbone of the disconnected area. A link has to be established between two ABRs that have a common area with one ABR connected to the backbone.
We can see that both R1 and R2 routers are ABRs and R1 is connected to the backbone area. Area2 will be used as a transit area and R1 is the entry point into the backbone area. A virtual link has to be configured on both routers.
Virtual link configuration is added in OSPF interface templates. If we take the example setup from the "no physical connection" illustration, then the virtual link configuration would look like this:
|domain-id (Hex | Address)||MPLS-related parameter. Identifies the OSPF domain of the instance. This value is attached to OSPF routes redistributed in BGP as VPNv4 routes as BGP extended community attribute and used when BGP VPNv4 routes are redistributed back to OSPF to determine whether to generate inter-area or AS-external LSA for that route. By default Null domain-id is used, as described in RFC 4577.|
|domain-tag (integer [0..4294967295])||if set, then used in route redistribution (as route-tag in all external LSAs generated by this router), and in route calculation (all external LSAs having this route tag are ignored). Needed for interoperability with older Cisco systems. By default not set.|
|in-filter (string)||name of the routing filter chain used for incoming prefixes|
|mpls-te-address (string)||the area used for MPLS traffic engineering. TE Opaque LSAs are generated in this area. No more than one OSPF instance can have mpls-te-area configured.|
|mpls-te-area (string)||the area used for MPLS traffic engineering. TE Opaque LSAs are generated in this area. No more than one OSPF instance can have mpls-te-area configured.|
|originate-default (always | if-installed | never; Default: never)||Specifies default route (0.0.0.0/0) distribution method.|
|out-filter-chain (name)||name of the routing filter chain used for outgoing prefixes filtering|
|out-filter-select (name)||name of the routing filter select chain, used for output selection|
|redistribute (bgp,connected,copy,dhcp,fantasy,modem,ospf,rip,static,vpn; )||Enable redistribution of specific route types.|
|router-id (IP | name; Default: main)||OSPF Router ID. Can be set explicitly as an IP address, or as the name of the router-id instance.|
|version (2 | 3; Default: 2)||OSPF version this instance will be running (v2 for IPv4, v3 for IPv6).|
|vrf (name of a routing table; Default: main)||the VRF table this OSPF instance operates on|
|use-dn (yes | no)||Forces to use or ignore DN bit. Useful in some CE PE scenarios to inject intra-area routes into VRF. If a parameter is unset then the DN bit is used according to RFC. Available since v6rc12.|
OSPF protocol supports two types of metrics:
|area-id (IP address; Default: 0.0.0.0)||OSPF area identifier. If the router has networks in more than one area, then an area with area-id=0.0.0.0 (the backbone) must always be present. The backbone always contains all area border routers. The backbone is responsible for distributing routing information between non-backbone areas. The backbone must be contiguous, i.e. there must be no disconnected segments. However, area border routers do not need to be physically connected to the backbone - connection to it may be simulated using a virtual link.|
|default-cost (integer; unset)||Default cost of injected LSAs into the area. If the value is not set, then stub area type-3 default LSA will not be originated.|
|instance (name; mandatory)||Name of the OSPF instance this area belongs to.|
|no-summaries ()||Flag parameter, if set then area will not flood summary LSAs in the stub area.|
|name (string)||the name of the area|
|nssa-translate (yes | no | candidate)||The parameter indicates which ABR will be used as a translator from type7 to type5 LSA. Applicable only if area type is NSSA|
|type (default | nssa | stub; Default: default)||The area type. Read more on the area types in the OSPF case studies.|
|advertise (yes | no; Default: yes)||Whether to create a summary LSA and advertise it to the adjacent areas.|
|area (name; mandatory)||the OSPF area associated with this range|
|cost (integer [0..4294967295])||the cost of the summary LSA this range will create|
default - use the largest cost of all routes used (i.e. routes that fall within this range)
|prefix (IP prefix; mandatory)||the network prefix of this range|
Read-only matched interface menu
The interface template defines common network and interface matches and what parameters to assign to a matched interface.
Interfaces to match. Accepts specific interface name or the name of the interface list.
|network (IP prefix)||the network prefix associated with the area. OSPF will be enabled on all interfaces that have at least one address falling within this range. Note that the network prefix of the address is used for this check (i.e. not the local address). For point-to-point interfaces, this means the address of the remote endpoint.|
|area (name; mandatory)||The OSPF area to which the matching interface will be associated.|
|auth (simple | md5)||Specifies authentication method for OSPF protocol messages.|
If the parameter is unset, then authentication is not used.
|auth-id (integer)||The key id is used to calculate message digest (used only when MD5 authentication is enabled). The value should match all OSPF routers from the same region.|
|authentication-key (string)||The authentication key is to be used for simple or MD5 authentication methods.|
|cost(integer [0..65535])||Interface cost expressed as link state metric.|
|dead-interval (time; Default: 40s)||Specifies the interval after which a neighbor is declared dead. This interval is advertised in hello packets. This value must be the same for all routers on a specific network, otherwise, adjacency between them will not form|
|disabled(yes | no)|
|hello-interval (time; Default: 10s)||The interval between HELLO packets that the router sends out this interface. The smaller this interval is, the faster topological changes will be detected, the tradeoff is more OSPF protocol traffic. This value must be the same for all the routers on a specific network, otherwise, adjacency between them will not form.|
|instance-id (integer [0..255]; Default: 0)|
|passive ()||If enabled, then do not send or receive OSPF traffic on the matching interfaces|
|prefix-list (name)||Name of the address list containing networks that should be advertised to the v3 interface.|
|priority (integer: 0..255; Default: 128)|
Router's priority. Used to determine the designated router in a broadcast network. The router with the highest priority value takes precedence. Priority value 0 means the router is not eligible to become a designated or backup designated router at all.
ROS v7 default value is 128 (defined in RFC), and the default value in ROS v6 was 1, keep this in mind when if you had strict priorities set for DR/BDR election.
|retransmit-interval (time; Default: 5s)||Time interval the lost link state advertisement will be resent. When a router sends a link state advertisement (LSA) to its neighbor, the LSA is kept until the acknowledgment is received. If the acknowledgment was not received in time (see transmit-delay), the router will try to retransmit the LSA.|
|transmit-delay (time; Default: 1s)||Link state transmit delay is the estimated time it takes to transmit a link-state update packet on the interface.|
|type (broadcast | nbma | ptp | ptmp | ptp-unnumbered | virtual-link; Default: broadcast)||the OSPF network type on this interface. Note that if interface configuration does not exist, the default network type is 'point-to-point' on PtP interfaces and 'broadcast' on all other interfaces.|
|vlink-neighbor-id (IP)||Specifies the router-id of the neighbor which should be connected over the virtual link.|
|vlink-transit-area (name)||A non-backbone area the two routers have in common over which the virtual link will be established. Virtual links can not be established through stub areas.|
Read-only list of all the LSAs currently in the LSA database.
|age (integer)||How long ago (in seconds) the last update occurred|
|area (string)||The area this LSA belongs to.|
|checksum (string)||LSA checksum|
|dynamic (yes | no)|
|flushing (yes | no)|
|id (IP)||LSA record ID|
|instance (string)||The instance name this LSA belongs to.|
|originator (IP)||An originator of the LSA record.|
|self-originated (yes | no)||Whether LSA originated from the router itself.|
|sequence (string)||A number of times the LSA for a link has been updated.|
Read-only list of currently active OSPF neighbors.
|address (IP)||An IP address of the OSPF neighbor router|
|adjacency (time)||Elapsed time since adjacency was formed|
|bdr (string)||An IP address of the Backup Designated Router|
|dr (IP)||An IP address of the Designated Router|
|dynamic (yes | no)|
|inactive (yes | no)|
|priority (integer)||Priority configured on the neighbor|
|router-id (IP)||neighbor router's RouterID|
|state (down | attempt | init | 2-way | ExStart | Exchange | Loading | full)|
|state-changes (integer)||Total count of OSPF state changes since neighbor identification|
Static configuration of the OSPF neighbors. Required for non-broadcast multi-access networks.
|address (IP%iface; mandatory )||The unicast IP address and an interface that can be used to reach the IP of the neighbor. For example, |
|area (name; mandatory )||Name of the area the neighbor belongs to.|
|disabled (yes | no)|
|instance-id (integer [0..255]; Default: 0)|
|poll-interval (time; Default: 2m)||How often to send hello messages to the neighbors which are in a "down" state (i.e. there is no traffic from them)|