There are five packet types that OSPF uses to communicate between neighbours. Each packet type privdes a specific function in terms of how the protocol establishes adjacencies, communicates routing information, and synchronises the Link-State Database (LSDB).
Type 1 – Hello
Hello packets are used to form and maintain adjacencies, and are bidirectionally communicated when a router interface is added to the OSPF configuration.
Bidirectional communication allows each neighbour to identify itself in neighbour hello packets, and validate state between itself and an adjacent router.
The hello packet consists of the following fields:
- Network Mask – Mask associated with the interface
- Hello interval – The interval in which hellos are sent (broadcast networks must use the same interval, point to point does not)
- Options – Optional capabilities
- Router priority – The router’s priority in a DR election
- Dead interval – A period of time before the router declares a neighbour to be dead (broadcast networks must use the same interval)
- Designated router – IP address of the DR
- Backup designated router – IP address of the BDR
- Neighbour – IP addresses of routers that hello packets have been received within the dead interval
In Junos hello packets are sent by default across point to point networks every 10 seconds, and are expired after the hello timer has passed four intervals. The hello and dead timers on point to point networks do not necessarily need to match, however on broadcast networks they must always be the same on all routers.
Type 2 – Database Description
The link-state routing algorithm requires all routers to have their link-state databases synchronised. OSPF implements this between adjacent routers, ensuring each neighbour has the same version of each LSA being exchanged.
The Database Description packets are used to describe the LSAs that belong to a router’s database. The sending and receiving of these packets is called the “Database Exchange Process”.
The Database Description packet provides a summary of all LSAs within a router’s database, by sending the header of each LSA across neighbour interfaces.
Type 3 – Link-State Request
If a router detects that parts of its database are out of date, the router will send a link-state request packet to a neighbour requesting the specific LSAs within its database that require updating.
Type 4 – Link-State Update
Link-state update packets are used to carry the actual LSAs between neighbour routers. Link-state update packets are sent in response to a router requesting specific LSAs in a link-state request packet.
Link-state updates are sent using the OSPF multicast address and are acknowledged with a link-state acknowledgement packet; in a scenario where an acknowledgement is not received, a router will resend the link-state update as a unicast packet.
The link-state update packet consists of the following fields:
- Number of advertisements (4 Bytes) – Number of LSAs included in the packet
- Link-state advertisements (Variable) – The LSAs being transmitted
Type 5 – Link State Acknowledgement
Link-state acknowledgement packets are used to acknowledge successful receipt of a link-state update packet. Each link-state acknowledgement packet can be used to respond to many link-state update packets.
Link-State Advertisements (LSAs)
LSAs are the fundamental building blocks of the OSPF LSDB and are flooded between routers within the OSPF domain, providing a synchronised topological database.
There are seven different LSAs that are used in Junos. Each LSA carries information about the links that make up the network topology, and there are five different LSA types that are used to describe different components of the OSPF domain.
LSAs contain a header field that’s pushed onto every packet. Within each LSA a number of different fields are used to carry information relating to the links within the domain – each parameter in the different fields is used to describe different physical and logical link types, along with their metrics and other specifics about the link and the network topology.
By understanding how OSPF LSAs are built, and analysing the data in each LSA, the topology of the OSPF domain can be reversed engineered.
Each router maintains a copy of each LSA for 60 minutes, and the Junos implementation of OSPF refreshes each LSA every 50 minutes.
The LSA header is pushed onto every LSA packet and is used to identify and summarise the contents of each LSA.
The header is 20 bytes in size and consists of eight fields, which are explained below.
LSA Header Fields
- LSA Age
This field identifies the time since the LSA was originated. As each router in the domain flows the LSA this value is incremented.
This field is used to set two specific options relating to the identification of external LSAs. The E bit is set in type 5 external LSAs (position 7), and the P bit (position 5) is set in type 7 external NSSA LSAs.
- LS Type
This field is used to identify the LSA type being advertised. Values of 1-5 represent each type of LSA.
- Link-state ID
This field works in conjunction with the LSA type field, to describe a specific aspect of the advertisement. The data contained in this field will be used for different reasons, depending on the type of LSA being advertised.
Below is a list of each LSA type and the associated data contained within this field:
- Type 1 LSA – The originating router’s router ID
- Type 2 LSA – The IP address of the network’s DR
- Type 3 LSA – The destination network’s IP address
- Type 4 LSA – The Router ID of the described ASBR
- Type 5 LSA – The destination network’s IP address
- Advertising Router
This field contains the router ID of the router that originated the LSA in the first instance.
- LS Sequence Number
This field contains a number that’s incremented each time a new version of an LSA is generated. This allows routers to ensure they have the most recent version of an LSA.
- LS Checksum
Used to provide a checksum of the entire contents of the LSA, with the exception of the LS age field.
- The full length of the LSA, including the header
Type 1: Router LSA
The router LSA is generated by all OSPF speaking routers (within a given area), and is used to advertise all point to point interfaces and routes exported into OSPF, along with the associated cost of each route.
The router LSA is defined as having “area scope”, which means it isn’t transmitted between different areas.
When a router LSA crosses an area boundary it’s translated into a type 3 summary LSA by an Area Border Router (ABR) – more on this later.
Router LSA Link Types
The router LSAs contains four important link-types which describe different link information using two fields of data.
The link ID field is used to describe information about the advertising node, and link data is used to describe the actual advertised link data itself.
- Type 1: Point-to-point
Point-to-point is used to describe a standard point to point interface. The link ID carries the neighbour router ID. The link data field carries the IP address of the local interface being advertised.
- Type 2: Transit
Transit link-types are used to describe interfaces that exist within a broadcast segment, which by default would be any Ethernet interface that has not explicitly been configured with a link type of point-to-point.
The link ID field contains the the local interface address of the DR, and the link data field carries the interface IP address of the originating router.
- Type 3: Stub
A stub link-type is used to describe an interface that doesn’t connect to an OSPF neighbour, such as loopback interfaces, or interfaces that have been configured as passive.
The stub is also used to describe interfaces that have been explicitly configured as point to point.
The link-ID field describes the IP address of the interface being advertised, and the data link field contains the subnet mask.
- Type 4: Virtual Link
A virtual link is connection between an ABR in area 0 and another ABR outside of area 0. The virtual link connects each device together and is advertised with a standard type 1 LSA using the virtual link-type. The link ID field carries the neighbour’s router ID, and the link data field carries the interface IP address of the originating router.
Type 2: Network LSA
The Network LSA is more straightforward to understand. It’s used by designated routers on a broadcast segment to advertise all routers and interfaces connected to the broadcast segment – including the DR itself.
Network LSA Fields
There are two fields contained in the LSA that define routers and links within the broadcast segment.
- Network Mask
The network mask field specifies the network mask that’s used for the attached segment.
- Attached Router
The attached router field contains the router IDs of each router that’s connected to the broadcast segment.
Type 3: Summary LSA
The summary LSA is generated by an ABR and is used to transmit routing information from one area to another. This LSA type has area scope, so is used to carry information between all areas within the OSPF domain, and is regenerated each time it crosses an ABR.
Summary LSA Fields
There are two relevant fields in Junos that are contained within the summary LSA.
- Network Mask
This field is used to describe the subnet mask of the network being advertised
This field specifies the cost of the route across the OSPF domain. When the area-range command is used the aggregated route has its metric set to the largest current metric of the contributing routes.
Type 4: ASBR Summary LSA
The ASBR Summary LSA is generated by an ABR. It’s purpose is to transmit information about an ASBR in an attached area.
The LSA is generated from a router LSA that has originated from a ASBR. The ABR recognises that the LSA belongs to an ASBR from the E bit, which is always set by an ASBR (when advertising itself). When this specific LSA is received at a local ABR, the ABR knows the route belongs to an ASBR and thus regenerates the type 4 LSA.
The advertising router field contains the ABR generating the new LSA, and the router ID of the ASBR is held in the link ID field.
In the same manner as a standard summary LSA this LSA has area scope, which results in a regeneration from a router LSA into a ASBR Summary LSA by each ABR.
Link-State ID Field
The ASBR Summary LSA contains the router ID of the the ASBR being advertised in the link-state ID field.
ASBR Summary LSA Fields
- Network Mask
Because the router ID is a 32 bit value this field has no relevance and is thus set to 0.0.0.0.
The cost of the route to the ASBR is contained within this field.
Type 5: AS External LSA
The Type 5 LSA is used to describe external routing information that has been exported from other routing protocols into OSPF. This LSA is domain wide, and is therefore flooded in its native format to every non-stub router in the OSPF domain.
When a route is exported into OSPF an external LSA is generated by an ASBR.
Link-State ID Field
The link-state ID field contains the actual IP address of the external network being advertised.
AS External LSA Fields
- Network Mask
This field contains the subnet mask of the network being advertised.
- E bit
This field identifies the type of metric associated with the external route, to which there are two options; the default is known as a type 2 external metric, which informs all routers in the domain that the cost to the ASBR advertising the route should not increased – therefore domain wide the route itself only carries the original cost, when it was exported into OSPF by the ASBR.
The type 1 external LSA informs routers in the OSPF domain to add to the cost to reach the ASBR, in addition to the original cost of the exported route.
This field contains the cost of the route in relation to the LSA being either an external type 1, or external type 2 – see above.
- Forwarding Address
This field contains the address of the router to use to sent packets to reach the externally advertised network. If the value is 0.0.0.0, this is the actual ASBR that has forwarded the route, which is identified from the advertising router field.
- External Route Tag
The value in this field can be applied to the external route, although OSPF does not use this value, it can be used by other protocols.
Type 7: NSSA External LSA
The type 7 LSA is used by ASBRs in a NSSA (not so stubby area) to advertise OSPF routes that have been imported from other protocols.
The LSA is specific to this type of area and therefore only has area scope; when the type 7 LSA reaches an ABR connected to the NSSA it’s translated to a standard type 5 external LSA and sent across the rest of the OSPF domain.
When an ABR receives a type 7 LSA and also has other NSSAs connected the ABR will regenerate the type 7 LSAs and advertise them into the other attached NSSAs, by default. If there are multiple ABRs connected to the originating NSSA, the then ABR with the highest router ID performs the regeneration – this above behavior can be disabled using the no-nssa-abr command.
The structure of the type 7 LSA is fundamentally the same as a type 5 LSA, however the forwarding address field in a type 7 LSA will depend on whether the externally connected interface to the NSSA is known (to the NSSA) as an internal OSPF route. If the connected external network is known the next hop of the remote router is placed in the forwarding address field. If the external link to the remote network is not known, the router ID of the ASBR in the NSSA is used as the forwarding address.
Type 9/10: Opaque LSAs
OSPF uses opaque LSAs to extend the functionality of the protocol beyond its fundamental design as an IGP.
The type 9 LSA is used to support graceful restart (GRES) and the type 10 LSA is used to support MPLS traffic engineering.
Both LSAs use the standard OSPF header, however the fields within each of these two LSAs are specific to each function. The flooding scope is also different; type 9 LSAs only require link-local flooding, where as type 10 LSAs have area flooding scope.
The link-state ID field in an opaque LSA is broken into a 1-byte opaque type field and a 3-byte opaque ID field. The opaque type field has an assignment range from 0-127, which is allocated by the IANA, depending on the function of the opaque LSA.
Below are the opaque LSA types:
- Traffic Engineering LSA – used for MPLS-TE
- Sycamore Optical Topology Descriptions
- Grace LSA – used for OSPF graceful restart
- Router Information LSA – Intended to supplement the options field to allow for communication of optional capabilities between neighbors. Currently the options field is only 8 bits and there is only a single bit that can be used that just determines if a neighbor supports opaque LSA’s. This RI LSA would provide TLV values to signal support of up to 32 different capabilities between neighbors without needing to add more bits to the options field in the LSA.