OSPF packets and adjacency review.
OSPF packets and neighbor relationship establishment.
The link-state IGP OSPF uses OSPF packets to build and maintain neighbor relationships and to reliably exchange LSAs to flood routing information across the AS. All OSPF routers create and maintain a link-state database (LSDB) which is built from LSAs. The SPF algorithm is run based on the contents of this LDSB. Having a solid foundation of these basics is an imperative not just for some certification track , but to anyone really working with OSPF.
So in order to reaffirm this foundation, I wanted to briefly review the OSPF packet types, the Link State Advertisement (LSA) packets and the OSPF neighbor relationship establishment in this article.
The following packets will be covered:
Type 1: Hello.
Type 2: Database Description (DD).
Type 3: Link-State Request (LSR).
Type 4: Link-State Update (LSU).
Type 5: Link-State Acknowledgement (LSAck).
Type 1: Hello.
Sent on a regular basis by all OSPF routers. The default interval for sending Hello’s is 10 seconds. Hello packets are sent to the all OSPF routers address 22.214.171.124 (or all DRs address 126.96.36.199).
The hello contains the following fields:
All fields with an asterisk must match. When they do not match, a neighbor relationship will not form. On point-to-point links, a matching network mask is not required.
Type 2: DD.
The only time when DD packets are used, is during the establishment of the neighbor relationship between two routers.
First, the DD packets are used to determine which router is the master (highest RID) and which router is the slave. After this, the router that is elected master will be in charge of the database synchronization process. Here, the DD packets are used to transmit LSA headers between OSPF routers.
Type 3: LSR.
After the exchange of DD packets, it may become apparent to a router that not all parts of its database are up-to-date. In order to fill in the missing pieces, the router sends an LSR.
The LSR that is send by the router will contain the request for the specific LSA’s that are either missing or not up-to-date. A router may have to send multiple LSRs to obtain the missing and more up-to-date information.
Type 4: LSU.
The LSU packets are responsible for the flooding of LSAs. There are 2 situations in which LSUs can be send. First, in response to LSRs during the neighbor establishment. Second, in response to a link state change.
Each LSU can contain 1 or more LSAs that will be sent to the local all routers (or all DRs) address.
Type 5: LSAck.
The LSAck packet is used to provide for a reliable flooding of LSAs within OSPF. Every flooded LSA has to be acknowledged by an LSAck. An LSAck packet can be used to acknowledge multiple LSAs at once.
LSA packet types.
All the routers in an Autonomous System convey routing information to each other. They do so by flooding LSAs. Depending on the type of routing information, a different LSA packet type can be used. The following is a list of the different LSA types;
Type 1: Router-LSAs.
Describes the state and costs of all the routers’ links to an area. The Router-LSAs are originated for each area a router belongs to. The Router-LSA is flooded throughout the area in which it is originated and no further.
The picture below displays a router with three links in a single area. All three links are put into a router LSA. This router LSA is then flooded throughout the connected area:
Type 2: Network-LSA.
The Network-LSA is always originated by a Designated Router and it describes a multiaccess Ethernet segment. It basically describes all the routers connected to the segment. The Network-LSA does not leave the area.
The picture below displays a DR describing the multiaccess segment and the routers connected to it in a Network-LSA. This Network-LSA will then be flooded throughout the connected area:
Type 3 + 4: Summary-LSAs.
Summary-LSAs are always originated by an ABR. They describe destinations outside of the area, but from within the AS. The type 3 summary LSAs are called Summary-LSA. The Summary-LSA describes a network or a network range. The type 4 summary LSAs are called AS boundary router (ASBR) Summary-LSA. The ASBR-Summary-LSA describes the location of the ASBR in other areas. The ASBR-Summary-LSA is generated by the ABR which is attached to the area in which the ASBR is located. The ABR will flood the ASBR-Summary-LSA to the other area’s to which it is attached.
In the picture below, two things happen. One, the ABR is sending Summary-LSAs for area X into area Y. Two, the ABR is sending an ASBR-Summary-LSA for area X's ASBR into area Y.
Type 5: AS-External-LSAs
The AS-external-LSAs describe prefixes to destinations which are external to the AS (or external to the OSPF process). This could include static routes, RIP-routes, OSPF routes from another OSPF process and more.
This also includes directly connected networks redistributed via a network policy. When a policy referring to direct routes is used, by default, the prefixes will be distributed by Junos as OSPF External LSAs with a type 2 metric. When the directly connected interface is placed under the OSPF configuration (as passive or active), the directly connected subnet will be send in a router LSA.
Type 7: NSSA External Links.
Similar to the Type 5 LSAs with the main difference being that they were originated by an ASBR in a NSSA. The type 7 LSAs are flooded throughout the NSSA. The ABR that is connected to the NSSA will distribute the routing information contained in these LSAs to the other connected areas. It will do so by translating the type 7 LSA to a type 5 LSA.
In the picture below, there is an NSSA ASBR flooding type 7 LSAs throughout the NSSA area. The type 7 LSAs are received by an ABR connected to the NSSA. The NSSA External LSAs are not flooded throughout the OSPF AS. Instead, they are translated to a type 5 External-LSA and then flooded throughout the OSPF AS:
The neighbor relationship establishment.
The description of the different neighbor states (or conversation state) is as follows;
Down: nothing happened. OSPF is awaiting a start event. When there is a start event, a Hello is sent towards the neighbor.
Init: Hello is seen. The Hello did not contain the router’s own router-id.
2Way: Bidirectional communication is established. Both routers have spotted their own router-id in the received hello packet’s neighbor field.
ExStart: the two routers determine who is slave and who is master during the following exchange state.
Exchange: the master and slave exchange LSA headers to describe their databases to each other. According to the RFC, LSR’s and LSU’s may also send during this state in case a router is missing some LSA’s.
Loading: in this state, link state information is exchanged in the form of LSR’s and LSU’s.
Full: when the LSR list is empty, the state is changed to Full.