Showing posts with label OSPF. Show all posts
Showing posts with label OSPF. Show all posts

Tuesday, September 13, 2022

OSPF : "34 Things to remember"

Open Shortest Path First (OSPF) is a routing protocol for Internet Protocol (IP) networks. It uses a link state routing algorithm and falls into the group of interior routing protocols, operating within a single autonomous system (AS). It is defined as OSPF Version 2 in RFC 2328 (1998) for IPv4.[1] The updates for IPv6 are specified as OSPF Version 3 in RFC 5340 (2008).

OSPF is perhaps the most widely used interior gateway protocol (IGP) in large enterprise networks. IS-IS, another link-state dynamic routing protocol, is more common in large service provider networks. The most widely used exterior gateway protocol is the Border Gateway Protocol (BGP), the principal routing protocol between autonomous systems on the Internet.

OSPF is an internal entranceway protocol (IGP) for routing web Protocol (IP) packets alone among one routing domain, like associate autonomous system. It gathers link state info from on the market routers and constructs a topology map of the network. The topology is bestowed as a routing table to the net Layer that routes datagrams based mostly alone on the destination information science address found in information science packets. OSPF supports web Protocol Version four (IPv4) and web Protocol Version half-dozen (IPv6) networks and options variable-length subnet masking (VLSM) and egalitarian Inter-Domain Routing (CIDR) addressing models.

OSPF detects changes within the topology, like link failures, and converges on a brand new loop-free routing structure among seconds. It computes the shortest path tree for every route employing a methodology supported Dijkstra's formula, a shortest path initial formula.

The OSPF routing policies for constructing a route table square measure ruled by link value factors (external metrics) related to every routing interface. value factors is also the gap of a router (round-trip time), knowledge outturn of a link, or link convenience and dependableness, expressed as easy unit less numbers. This provides a dynamic method of traffic load equalization between routes of equal value.

An OSPF network is also structured, or divided, into routing areas to change administration and optimize traffic and resource utilization. Areas square measure known by 32-bit numbers, expressed either merely in decimal, or usually in octet-based dot-decimal notation, acquainted from IPv4 address notation.

The 34 Things which you should remember are as follows:-

1. The IP header of an OSPF packet specifies protocol number 89.

2. To establish OSPF neighbor adjacency, hello/dead timers, MTU (otherwise have to use "ip ospf mtu-ignore") must match. Unique router-id is also required.

3. Routers in stub area can only be adjacent with the routers in stubs or totally stubby area. Routers in NSSA can only be adjacent with the routers in NSSA or totally NSSA.

4. OSPF sees secondary networks as stub networks and cannot make adjacencies over secondary addresses. OSPF will advertise a secondary network or subnet only if it is also running on the primary network or subnet and OSPF routes of secondary addresses must be in same area as the primary address to be advertised. To learn routes from a neighbor connected to the secondary network, another routing protocol such as RIP should be running and redistributed into OSPF. Another solution to this kind of problem is to create dot1q sub interfaces.

5. The only time that OSPF will form adjacencies between neighbors that are not on the same subnet is when the neighbors are connected through point-to-point links using "ip unnumbered".

6. The primary interface and IP unnumbered interface will have OSPF enabled if a network statement matches the IP address of the primary interface.

7. An OSPF external route cannot use another OSPF external route as its next hop.

8. Inside an area, OSPF uses Link State logic, but between areas OSPF acts much like a Distance Vector (DV) protocol in some regard. For example, the advertisement of a Type 3 LSA from one area to another hides the topology in the original area from the second area, just listing a destination subnet, metric (cost), and the ABR through which the subnet can be reached—all DV concepts.

9. Only broadcast and non-broadcast network elect DR/BDR based on priority or router-id (in case of a tie in the priority).

10. In non-broadcast network, DR/BDR must have layer 2 connectivity to all other routers in the same area.

11. With OSPF network types broadcast and non-broadcast, next hop values are not modified when updates are transmitted across an NBMA media. Both point-to-multipoint and point-to-multipoint non-broadcast network type update the next-hop value of routes learned on partially meshed networks to the directly connected neighbor, and advertise the network as a set of endpoints instead of a transit network.

12. OSPF network point-to-point is the default option for point-to-point interfaces such as HDLC, PPP, or point-to-point NBMA subinterfaces.

13. As only broadcast and non-broadcast network type elects DR/BDR, they are compatible with each other, but they are not compatible with any other network types.

14. OSPF cost can be modified using (i) interface "bandwidth ..." command, (ii) interface "ip ospf cost ..." command, (iii) process "auto-cost reference-bandwidth ..." command, or (iv) "neighbor ... cost ..." command on point-to-multipoint non-broadcast network.

15. Only OSPF point-to-multipoint and point-to-multipoint non-broadcast network types support OSPF cost value on a per neighbor basis. On point-to-multipoint broadcast networks, if the "neighbor..." command is used, a cost to that neighbor must be specified.  But on point-to-multipoint non-broadcast networks, the "neighbor ..." command must be used to identify neighbors, assigning a cost to a neighbor is optional.

16. The internal OSPF routes can only be summarized on ABRs whereas the external (redistributed) routes can only be summarized on ASBRs.

17. "area default-cost ..." command is used to specify a cost for the default summary route (default cost 1) that is sent into a stub area or NSSA.

18. In NSSA, ABR with the highest router-id does the LSA 7 to 5 conversion.

19. In NSSA, “default-information originate” command cannot be used, since it generates Type-5 LSA, which is prohibited in NSSA area.

20. NSSA ASBR can generate a default only when it has a default route in its routing table whereas NSSA ABR can generate a default route with or without a default route in its own routing table.

21. Virtual links are not allowed in the stubby area or NSSA. In this case OSPF can be tunneled over a stub area using GRE tunnel (tunnel must be connected to area 0).

22. If the authentication is wrong on the virtual-link, the virtual-link interface will not go down immediately. As the virtual-link does not support periodic hellos, “clear ip ospf process” command should be issued if the authentication is enabled on the virtual link.

23. The virtual link will not come up if the only interface to reach the other end of the virtual link has a cost that is maximized (65535).

24. For BGP to redistribute routes into OSPF, the router-id must be identical, in OSPF and in BGP.

25. OSPF filtering using "distribute-list ...", "route-map ..." (match route-type, match ip route-source, match ip next-hop), and "distance ..." commands can only block route from entering into local RIB, but cannot stop LSAs propagation into the OSPF database.

26. OSPF filtering using "area ... filter-list prefix ...", "area ... range ... not-adv", “summary-address … not-adv”, “ip ospf database-filter all out”, or “neighbor … database-filter all out”  commands can filter LSAs from OSPF database.

27. If the “area … range …” and "area ... filter-list prefix ... out" both commands are configured for an area, then type 3 LSAs that correspond to the area range are sent to all other areas, only if at least one prefix in the area range matches an entry in the prefix list.

28. OSPF defaults to cost 20 when redistributing from an IGP, and 1 when redistributing from BGP.

29. “neighbor … database-filter all out” only works on point-to-multipoint network types.

30. If “distribute-list out” command is configured on an ASBR, then the ASBR generates Type 5 external LSAs only for those networks that are explicitly permitted in the distribute list.

31. OSPF demand circuit sets “do not age” flag on all LSAs learned and will only send updates when there is a change in the OSPF topology. The command must be configured in a point-to-point link and is needed only on one side. If the router is part of a point-to-multipoint topology, only the multipoint end must be configured with this command.

32. The main difference between flooding reduction ("ip ospf flood-reduction") and demand circuits ("ip ospf demand-circuit") is that former suppresses only periodic LSA refreshes; it does not suppress periodic hello packets. Thus, the flooding reduction feature does not impair the detection of a neighbor router going down.

33. OSPF stub router (“max-metric router-lsa”) advertises all non self-originated routes/LSAs with maximum metric.

34. When "redistribute maximum-prefix ..." command is configured, the redistribution limit does not apply to default routes or prefixes that are generated as a result of Type-7 to Type-5 translation.



OSPF Neighbor States

When OSPF adjacency is formed, a router goes through several state changes before it becomes fully adjacent with its neighbor. Those states are defined in the OSPF RFC 2328 leavingcisco.com, section 10.1. The states are Down > Attempt > Init > 2-Way > Exstart > Exchange > Loading > Full.

 

Down

This is the first OSPF neighbor state. It means that no information (hellos) has been received from this neighbor, but hello packets can still be sent to the neighbor in this state.
During the fully adjacent neighbor state, if a router doesn't receive hello packet from a neighbor within the RouterDeadInterval time (RouterDeadInterval = 4*HelloInterval by default) or if the manually configured neighbor is being removed from the configuration, then the neighbor state changes from Full to Down.

 

Attempt

This state is only valid for manually configured neighbors in an NBMA environment. In Attempt state, the router sends unicast hello packets every poll interval to the neighbor, from which hellos have not been received within the dead interval.

 

Init

This state specifies that the router has received a hello packet from its neighbor, but the receiving router's ID was not included in the hello packet. When a router receives a hello packet from a neighbor, it should list the sender's router ID in its hello packet as an acknowledgment that it received a valid hello packet.

 

2-Way

This state designates that bi-directional communication has been established between two routers. Bi-directional means that each router has seen the other's hello packet. This state is attained when the router receiving the hello packet sees its own Router ID within the received hello packet's neighbor field. At this state, a router decides whether to become adjacent with this neighbor. On broadcast media and non-broadcast multiaccess networks, a router becomes full only with the designated router (DR) and the backup designated router (BDR); it stays in the 2-way state with all other neighbors. On Point-to-point and Point-to-multipoint networks, a router becomes full with all connected routers.
At the end of this stage, the DR and BDR for broadcast and non-broadcast multiacess networks are elected. For more information on the DR election process, refer to DR Election.
Note: Receiving a Database Descriptor (DBD) packet from a neighbor in the init state will also a cause a transition to 2-way state.

 

Exstart

Once the DR and BDR are elected, the actual process of exchanging link state information can start between the routers and their DR and BDR.
In this state, the routers and their DR and BDR establish a master-slave relationship and choose the initial sequence number for adjacency formation. The router with the higher router ID becomes the master and starts the exchange, and as such, is the only router that can increment the sequence number. Note that one would logically conclude that the DR/BDR with the highest router ID will become the master during this process of master-slave relation. Remember that the DR/BDR election might be purely by virtue of a higher priority configured on the router instead of highest router ID. Thus, it is possible that a DR plays the role of slave. And also note that master/slave election is on a per-neighbor basis.

 

Exchange

In the exchange state, OSPF routers exchange database descriptor (DBD) packets. Database descriptors contain link-state advertisement (LSA) headers only and describe the contents of the entire link-state database. Each DBD packet has a sequence number which can be incremented only by master which is explicitly acknowledged by slave. Routers also send link-state request packets and link-state update packets (which contain the entire LSA) in this state. The contents of the DBD received are compared to the information contained in the routers link-state database to check if new or more current link-state information is available with the neighbor.

 

Loading

In this state, the actual exchange of link state information occurs. Based on the information provided by the DBDs, routers send link-state request packets. The neighbor then provides the requested link-state information in link-state update packets. During the adjacency, if a router receives an outdated or missing LSA, it requests that LSA by sending a link-state request packet. All link-state update packets are acknowledged.

 

Full

In this state, routers are fully adjacent with each other. All the router and network LSAs are exchanged and the routers' databases are fully synchronized.
Full is the normal state for an OSPF router. If a router is stuck in another state, it is an indication that there are problems in forming adjacencies. The only exception to this is the 2-way state, which is normal in a broadcast network. Routers achieve the FULL state with their DR and BDR in NBMA/broadcast media and FULL state with every neighbor in the remaining media such as point-to-point and point-to-multipoint.
Note: The DR and BDR that achieve FULL state with every router on the segment will display FULL/DROTHER when you enter the show ip ospf neighbor command on either a DR or BDR. This simply means that the neighbor is not a DR or BDR, but since the router on which the command was entered is either a DR or BDR, this shows the neighbor as FULL/DROTHER.

OSPF Area and LSAs Propagation

The link-state advertisement (LSA) is a basic communication means of the OSPF routing protocol for the Internet Protocol (IP). It communicates the router's local routing topology to all other local routers in the same OSPF area. OSPF is designed for scalability, so some LSAs are not flooded out on all interfaces, but only on those that belong to the appropriate area. In this way detailed information can be kept localized, while summary information is flooded to the rest of the network. The original IPv4-only OSPFv2 and the newer IPv6-compatible OSPFv3 have broadly similar LSA types.




The LSA types defined in OSPF are as follows:
  • Type 1 - Router LSA - the router announces its presence and lists the links to other routers or networks in the same area, together with the metrics to them. Type 1 LSAs are flooded across their own area only. The link-state ID of the type 1 LSA is the originating router ID.
  • Type 2 - Network LSA - the designated router (DR) on a broadcast segment (e.g. Ethernet) lists which routers are joined together by the segment. Type 2 LSAs are flooded across their own area only. The link-state ID of the type 2 LSA is the IP interface address of the DR.
  • Type 3 - Summary LSA - an Area Border Router (ABR) takes information it has learned on one of its attached areas and summarizes it before sending it out on other areas it is connected to. This summarization helps provide scalability by removing detailed topology information for other areas, because their routing information is summarized into just an address prefix and metric. The summarization process can also be configured to remove a lot of detailed address prefixes and replace them with a single summary prefix, helping scalability. The link-state ID is the destination network number for type 3 LSAs.
  • Type 4 - ASBR-Summary LSA - this is needed because Type 5 External LSAs are flooded to all areas and the detailed next-hop information may not be available in those other areas because it may be using a different routing protocol. This is solved by an Area Border Router flooding the information for the router (i.e. the Autonomous System Boundary Router) where the type 5 originated. The link-state ID is the router ID of the described ASBR for type 4 LSAs.
  • Type 5 - External LSA - these LSAs contain information imported into OSPF from other routing processes. They are flooded to all areas unchanged (except stub and NSSA areas). For "External Metric Type 1" LSAs routing decisions are made using the Type 1 metric cost sent, as the total cost to get to the external destination and includes the cost to the ASBR; while for "External Type 2" LSAs the metric sent is the cost from the ASBR to the External destination network and must be added to the OSPF cost to the ASBR advertising the Type 5. The link-state ID of the type 5 LSA is the external network number.
  • Type 6 - Group Membership LSA (Only supported on a few routers) - this was defined for Multicast extensions to OSPF (MOSPF), a multicast OSPF routing protocol which was not in general use. MOSPF has been deprecated since OSPFv3 and is not currently used. It may be reassigned in the future.
  • Type 7 - Routers in a Not-so-stubby-area (NSSA) do not receive external LSAs from Area Border Routers, but are allowed to send external routing information for redistribution. They use type 7 LSAs to tell the ABRs about these external routes, which the Area Border Router then translates to type 5 external LSAs and floods as normal to the rest of the OSPF network.
  • Type 8 - A link-local only LSA for OSPFv3. A Type 8 LSA is used to give information about link-local addresses and a list of IPv6 addresses on the link. In OSPFv2, however, the Type 8 was originally intended to be used as a so-called External-Attributes-LSA for transit autonomous systems where OSPFv2 could replace the internal Border Gateway Protocol (iBGP). In these networks, the BGP destinations would be carried in LSA Type 5 while their BGP attributes would be inserted into LSA Type 8. Most OSPFv2 implementations never supported this feature.
  • Type 9 - a link-local "opaque" LSA (defined by RFC2370) in OSPFv2 and the Intra-Area-Prefix LSA in OSPFv3. It is the OSPFv3 LSA that contains prefixes for stub and transit networks in the link-state ID.
  • Type 10 - an area-local "opaque" LSA as defined by RFC2370. Opaque LSAs contain information which should be flooded by other routers even if the router is not able to understand the extended information itself. Typically type 10 LSAs are used for traffic engineering extensions to OSPF, flooding extra information about links beyond just their metric, such as link bandwidth and color.
  • Type 11 - an AS "opaque" LSA defined by RFC 5250, which is flooded everywhere except stub areas. This is the opaque equivalent of the type 5 external LSA

OSPF

 OSPF