top of page

OSPF (Open Shortest Path First)

  • Aug 18, 2016
  • 3 min read

OSPF is an interior gateway protocol (IGP) for routing Internet Protocol (IP) packets solely within a single routing domain, such as an autonomous system. It gathers link state information from available routers and constructs a topology map of the network. The topology is presented as a routing table to the Internet layer which routes packets based solely on their destination IP address. OSPF supports Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) networks and supports the Classless Inter-Domain Routing (CIDR) addressing model.

OSPF detects changes in the topology, such as link failures, and converges on a new loop-free routing structure within seconds.[3] It computes the shortest-path tree for each route using a method based on Dijkstra's algorithm. The OSPF routing policies for constructing a route table are governed by link metrics associated with each routing interface. Cost factors may be the distance of a router (round-trip time), data throughput of a link, or link availability and reliability, expressed as simple unitless numbers. This provides a dynamic process of traffic load balancing between routes of equal cost.

An OSPF network may be structured, or subdivided, into routing areas to simplify administration and optimize traffic and resource utilization. Areas are identified by 32-bit numbers, expressed either simply in decimal, or often in the same octet-based dot-decimal notation used for IPv4 addresses. By convention, area 0 (zero), or 0.0.0.0, represents the core or backbone area of an OSPF network. The identifications of other areas may be chosen at will.[a] Each additional area must have a connection to the OSPF backbone area. Such connections are maintained by an interconnecting router, known as an area border router (ABR). An ABR maintains separate link-state databases for each area it serves and maintains summarized routes for all areas in the network.

OSPF does not use a transport protocol, such as UDP or TCP, but encapsulates its data directly in IP packets with protocol number 89. This is in contrast to other routing protocols, such as the Routing Information Protocol (RIP) and the Border Gateway Protocol (BGP). OSPF implements its own transport layer error detection and correction functions. OSPF uses multicast addressing for distributing route information within a broadcast domain.[b] For non-broadcast networks, special provisions for configuration facilitate neighbor discovery.[1] OSPF multicast IP packets never traverse IP routers, they never travel more than one hop.[c] The OSPF protocols gathers information regarding all link states in the domain in its link state database, and is thus not a link layerprotocol itself, but is - based on the purpose of the protocol; to exchange and calculate optimal paths through the network for IP destination addresses - most correctly classified as an Internet layer protocol. The OSPF protocol, when running on IPv4, can operate securely between routers, optionally using a variety of authentication methods to allow only trusted routers to participate in routing. OSPFv3, running on IPv6, does not support protocol-internal authentication. Instead, it relies on IPv6 protocol security (IPsec).

For routing IP multicast traffic, OSPF supports the Multicast Open Shortest Path First (MOSPF) protocol.[6] Cisco does not include MOSPF in their OSPF implementations.[7] Protocol Independent Multicast (PIM) in conjunction with OSPF or other IGPs, is widely deployed.

OSPF version 3 introduces modifications to the IPv4 implementation of the protocol.[2] Except for virtual links, all neighbor exchanges use IPv6 link-local addressing exclusively. The IPv6 protocol runs per link, rather than based on the subnet. All IP prefix information has been removed from the link-state advertisements and from the hello discovery packet making OSPFv3 essentially protocol-independent. Despite the expanded IP addressing to 128-bits in IPv6, area and router Identifications are still based on 32-bit numbers.


 
 
 

Comments


Contact

123, New Delhi

India -110058

​​

Email:- Dragoun@protonmail.com

  • Black Facebook Icon
  • Black Twitter Icon
  • Black Instagram Icon
  • Black YouTube Icon
  • Black Google+ Icon

Name *

Email *

Subject

Message

Success! Message received.

© 2023 by H&H Media

bottom of page