So first what are the various types of packets:

• Hello Packets
• Database Description (DBD) Packets
• Link State Request (LSR) Packets
• Link State Update (LSU) Packets
• Link State Acknowledgement (LSAck) Packets

Each OSPF packets have a common OSPF Header. Other than Hello Packets, all other packets are LSA related. Each such LSA packet typehas a common LSA header. The DBD, LSR and LSA packets carry only this header, while the LSU packets carry the entire LSA. There are various types of LSAs which will be covered in a later post in detail.

OSPF Packet Header

The OSPF Packet Header is of 24 bytes length. Each OSPF packet carries this. The header gives all information necessary that enables routers to know whether the packet should be processed further or not.

Version No – This field specifies the version number of OSPF. Currently what we are discussing here and is used everywhere is OSPFv2. For IPv6, it is OSPFv3.

Type – This states the type of OSPF Packet. We have 1 (Hello), 2 (DBD), 3 (LSR), 4 (LSU) and 5 (LSAck).

Packet Length - This is the length of the complete OSPF Packet including the header.

Router ID - The Router ID of the source. Each router in an OSPF Domain must have a unique Router ID as described here. It is denoted as a 4 byte IP Address format.

Area ID - The area to which the packet belongs too. Each OSPF packet belongs to 1 area. This is denoted as a 4 byte IP Address format. For backbone area packet, the area ID is 0.0.0.0 For other areas like area 1 it contains the value as 0.0.0.1 etc.

Checksum - This is the standard IP checksum of the entire OSPF packet excluding the Authentication field. It is calculated as 16-bit one’s complement of one’s complement of all 16 bit words present. The packet needs to be padded with extra 0s at the end if the packet is not a multiple of 16 bit words.

Auth Type – The type of authentication done between the neighbors. Current values are 0 (null or no authentication), 1 (Plain text password) and 2 (cryptographic or MD5 hashing based password). All other values are reserved by IANA.

Authentication – This is a 64 bit (8 bytes) field. This contains the actual authentication information if enabled.

For all the OSPF Packets described below, the above OSPF Header is always present. Only the extra distinct fields of the specific packet types are being mentioned below.

Hello Packets

Hello Packets are notified in the header by type 1. They are sent at periodic intervals (default 30 secs) over all the OSPF enabled interfaces. The purpose of these packets are for dynamic discovery of neighbors, establishing and maintaining neighbor ship. Routers in a common network negotiate few common parameters. These parameter values are carried in the Hello Packets. The parameters are Network Mask, Hello interval and Dead Interval.

Network Mask - The network mask that is associated with the interface. This should match on both sides of a link in order for adjacency to come up.

Hello Interval – The time interval between successive hello packets sent by a router.

Options – The optional capabilities supported by the router. These are described at the end of this post.

Rtr Priority - This is the priority value of the router. This is used in case of DR-BDR election. If priority value is 0, then the router doesn’t take part in DR-BDR election.

Dead Interval - The number of seconds to wait before declaring a router as down. This starts when a router misses a Hello Message from its neighbor. By default it is 3 times the Hello Interval.

Designated Router - The router ID of the DR as seen by the router. Initially this is set to 0.0.0.0 and once it is elected it changes this value.

Backup Designated Router - Same as above, this field specifies the router ID of the BDR.

Neighbor (s) – The router IDs of all the neighbors from whom a Hello Message has been received within the last Dead Interval seconds. This is a variable field and initially it contains no router IDs.

Database Description (DBD) Packets

The DBD packets are exchanged during the initialization of the adjacency. They are OSPF Packet Type 2. The master/slave mechanism is used for exchanging the DBD Packets. During the Exstart state of OSPF, an empty DBD packet is exchanged where the Master/Slave is elected per link and the initial sequence number to be used by the master is decided. During the Exchange state, the DBD packets contain the LSA headers and using these the routers make a list of LSAs that they are going to request from their neighbors.

Interface MTU - The maximum size of IP packets that can be sent over the link. This value should match on both the routers in order for the adjacency to come up.

Options - The optional capabilities that are explained below.

I Bit – The init bit which states that this is the first of the DBD packets.

M Bit - The more bit which states that there are more DBD packets after the current packet.

MS Bit – The Master/Slave Bit. If it is set to 1, it implies that the router is a Master else the router is a slave.

DD Sequence Number - This is the sequence number for the DBD packets. This can only be incremented by the Master and the initial value is set when the I bit is set.

LSA Headers - The remaining field contains the list of LSA headers. This can be a partial list too and hence multiple DBD packets are needed.

Link State Request (LSR) Packets

The LSR Packets are of OSPF Packet Type 3. Once the DBD packets are exchanged, each router checks the LSA Headers against its own database and if it finds it doesn’t have up to date information for any LSA, it creates the LSR packets and sends it to its neighbor asking for the updated LSAs. The LSA instance is defined by the LS sequence number, Checksum and LS Age. But the response to the LSR can be a more updated instance of the LSA.

The LSR packets however do not contain the LSA instance related fields but the LSA identification fields.

LS Type - The type of Link State being asked for.

Link State ID - Each LSA has a ID. This is mentioned in this field.

Advertising Router - The router that has originated the LSA.

There can be 1 or more LSA request fields in each LSR packet.

Link State Update (LSU) Packets

Link State Update (LSU) packets contain the actual complete LSAs. The various types of LSAs and their formats will be described in a later post. Each LSU packet contains a field that mentions the total number of LSAs contained in that packet. The LSU packets are OSPF Packet Type 4.

Link State Acknowledgement (LSAck) Packets

The LSAck packets help in reliable transmission of the LSAs. Each LSAs are explicitly acknowledged. The LSAck packets are OSPF Type 5 and they can contain acknowledgements for multiple LSAs. The LSA header is contained in the LSAck packet and this suffices for the acknowledgement for the corresponding LSA.

The Options Field

The Options field is present in the Hello Packets, Database Description Packets and in each individual LSAs. Each router uses the options field to advertise the capabilities it supports to all its neighbors. The options field in Hello Packets enables each router to reject adjacency request due to the capabilities mismatch. When used in the DBD packets, the Options field lets a router decide whether it has to forward an LSA or not due to its reduced capability. In LSAs, the Options helps routers by enabling it to take proper forwarding decisions by bypassing the LSAs with reduced capabilities.

Out of the 8 bits in the options field, the first, second and eight bits are reserved and not used. The other bits from 3rd to 7th bit in sequence are:

1. DC Bit - This specifies the handling mechanisms for Demand Circuits.
2. EA Bit - This specifies that the routers can handle External Attributes LSAs.
3. N/P Bit - This is used for handling Type-7 LSAs which are used in case of NSSA areas.
4. MC Bit - This bit is used for handling Multicast Packets.
5. E Bit - This bit specifies how the AS External LSAs are flooded in the OSPF domain.

In later posts, we will see how some of the options are implemented and used. As I have mentioned before, a major part of the packet formats are the LSA types. I will discuss these in detail in a later post. Also the way these OSPF packets are used will also be discussed by me in a later post. Hope you had a nice refresh of the various packet types.

• When a link goes down, an update is triggered with a poisoned route.
• When the routing updates stops (like in case of “passive-interface default“)

In both the cases we will use the topology as used in RIP Timers article. The topology diagram is presented here again for your reference.

Triggered Update when a link goes down

To start with let us assume the timer values. Lets take the default values viz. Update Timer of 30secs, Invalid Timer of 180 secs, Hold Down Timer of 180secs and Flush Timer of 240secs. Let us also assume that all the 4 routers are synchronized meaning that their Update Timers have started at the same time (obviously this is an assumption :)). Now the subnet 172.1.4.0 has been advertised to R2 by R1 which has the minimum metric of 2 for R2. Now at time t, R1 sends an update for the subnet 172.1.4.0 to R2. Now let us shutdown the interface Fa1/0 on R1. This will make R1 send a triggered update to R2 for 172.1.4.0 as a poisoned route with metric 16 (unreachable). In response R2 will use poison reverse and send the same subnet with metric 16 back to R1. All these will take place within t+2 seconds. R2 now removes the subnet from its routing table.  Now note that this time the subnet 172.1.4.0 is reachable via R4. This is used by R3 but not R2. R2 will have to wait for R3 to send an update for the subnet. This will come only around t+30 seconds. Now R2 installs this route for subnet 172.1.4.0 via R3. Since we have assumed that the timers are synchronized in all the routers, it takes around 30 seconds for R2 to learn the new path to the subnet. In reality this is never the case so the convergence time will vary between 20 to 50 seconds.

Updates do not arrive anymore

Let us assume the same timer values in this case too. We are not assuming any synchronization timer here. Let us bring down the Fa0/0 interface on R1. Now in this case there is no triggered update from R1 towards R2 as it is not possible for R1 to send that to R2. After the interface is brought down on R1, R2 doesn’t receive any update for the subnet 172.1.4.0 from R1. So it waits till its Invalid Timer (180 secs) expires. After this the Hold Down Timer is set to 180 secs and the count down begins for it to become 0. Please note during this time an update for the subnet 172.1.4.0 might be sent by R3 towards R2. But this will only be of a higher metric than what R2 had, so during the hold down period R2 will not use this route. The new route can be used when either the Hold Down Timer or Flush Timer (240 seconds) expires whichever comes first. Now since flush timers start along with the Invalid Timer, it needs to run for 60 more seconds for the route to flush. When this happens even the Hold Down Timer is removed. This makes R2 wait for 120+60=240 secs for the route to flush. Now R2 needs to wait for the next update from R3. This can take from 1 to 30 seconds time. So during this scenario the convergence will take a total from 240 to 270 seconds which is a very high time period for routes to converge.

Summary - So from the above 2 scenarios we can see that the convergence time is quite high in case of RIP. Other IGP like OSPF and ISIS solves this issue quite well and hence they are mostly used nowadays for large network installations. We will discuss these protocols in detail during later posts.

We will use the following topology for the explanation.

We will be using 4 routers connected as above. The interfaces connected and the their IP addresses are mentioned in the figure. Configuring RIP is very simple. We will be using the sample configurations from a 7200 Router.

Below are the RIP configurations for R1.

The timers command is used to configure the timers. The update timer has been set to 30secs, the invalid timer is 40secs, the hold down timer is 90secs and the flush timer is 180 secs. Also the command “no auto-summary” is not compulsory. I configured it in order to check the actual prefixes that were updated instead of the summarized routes.

Now lets have a look at the current routing table on R2.

11.11.11.0 subnet is a redistributed route from R3. The Update Timer at this time is 2 seconds as can be seen from our configuration. Every 30 seconds a fresh update for this route will come from R2.

We have disabled the interface fa0/0 on R4 for the time being so that we do not get the 11.11.11.0 update from R4. Now we immediately disable updates from R3 using passive-interface default command. We keep observing R2. After the Invalid Timer expires in 40 seconds, R2 advertises 11.11.11.0 subnet to its neighbor with metric 16 (inaccessible). During this time R2’s routing table shows 11.11.11.0 as possibly down.

Once invalid timer expires, R2 enters Hold Down Timer which will expire in 90 seconds. During this time R2 will accept other routes for 11.11.11.0 only if its metric is 1 or less. We now add a static route on R4 with subnet 11.11.11.0 and redistribute it into RIP. This update now will reach R2 by traversing through R1. The metric will be 3 at R2 and since it is greater than 1 and R2 is still running the hold down timer, this route is not accepted. We will still see the 11.11.11.0 subnet as possibly down.

We immediately disable the 11.11.11.0 subnet at R4. Now when the Hold Down timer expires, R2 waits till the Flush Timer expires before it purges the subnet from its routing table.

So I think now we can clearly describe how the RIP Timers run. It is quite simple actually but it tends to get confusing.

Let me point out the steps into enabling and running OSPF in a network:

• Identify the OSPF routers by marking each of them with a unique router id.
• Establish adjacency and neighbor relations between the router in the network.
• Exchange the link state database so that each router can calculate the shortest path to each link using the SPF algorithm.
• Whenever a new link is added or there is a change in topology, then an update is triggered to the entire network. If no changes occur then the link information are refreshed after 30 mins to ensure that the database state is accurate and current.

Assigning the Router ID

Router ID is used to simply identify the router. It is of the 4 byte IP address format A.B.C.D. It is not an address that need to be reachable using the routing table. The ID can be explicitly mentioned or can be derived from the existing IP addresses on the router. The sequence to be used is –

1. If an explicit router id is mentioned, then this id is preferred. Usually the command is router-id <A.B.C.D>.
2. If no router id is mentioned explicitly, then use the highest IP address from the available up and running loopback interfaces.
3. If no loopback interfaces are present, then use the highest IP address from the available up and running physical interfaces.

A router ID once configured (or derived), doesnt change till the OSPF process is refreshed in the router. If a router ID changes, then all routers in the network need to rerun their SPF calculations.

Router IDs are used to identify the routers and they are also used in many other steps during the setting up of OSPF adjacency as will be described later.

OSPF Messages

OSPF is a pure Layer 3 routing protocol and the messages are encapsulated directly into IP packets. The IP protocol number for OSPF is 89.

Each and every step in OSPF be it the establishment of neighbor relationships, exchanging of the link state database and establishing the complete adjacency, is done with the help of OSPF messages (or packets). We will establish here a term that is used to describe all link state packets – Link State Advertisements (LSA). There are 5 different types of OSPF messages –

1. Hello Packets – This is used for finding neighbors, establishing neighbor relationships and checking the liveliness and availability of the neighbor.
2. Database Description (DBD) Packets – These are used to exchange the LSA headers, so that a router create a list of LSAs that it will need from a neighbor.
3. Link-State Request (LSR) Packets – These packets contains a list of one or more LSAs which the router wants its neighbor to send complete details about.
4. Link-State Update (LSU) – These packets the complete LSAs. These are sent usually in response to an LSR message.
5. Link-State Acknowledgement (LSAck) – These packets are sent to confirm receipt of an LSU message.

States of an OSPF Router

Lets briefly list here the various OSPF states. I will talk about them in greater detail in a future post.

1. Init – As soon as OSPF is enabled in a router, the Init state is achieved.
2. 2-Way – An OSPF router transitions to 2-Way state once bi-directional hello exchange has been done per router. As we will see later, DR and BDR election is done during this state if required.
3. ExStart – During this state, a Master-Slave relationship is achieved between each neighbor. This is based on the Router IDs of the neighbors.
4. Exchange – During this state, DBD packets are exchanged between the neighbors and the routers create LSRs.
5. Loading – The actual exchange of the LSAs occur during this state using LSRs, LSUs and LSAcks.
6. Full – Once all LSAs have been exchanged, the router transitions to Full State.

This was a brief introduction to OSPF. I will keep discussing all the above concepts and many more in detail in later posts.

Differences between RIPv1 and RIPv2

RIP Timers

RIP uses 4 different timers which help in maintaining the routing table and helps in avoiding loops. All these timers are per route. These are:

1. Update timer (30 secs) – This is the interval which states how often the update for a specific route must be sent.
2. Invalid timer (180 secs) – This is the interval which states that once an update is received for a route how long to wait till the route is considered invalid or non-reachable.
3. Hold down timer (180 secs) – If a route gets a worse metric and is updated, the hold down timer is started. During this time no other metric for the route is accepted which is equal or worse than the current metric.
4. Flush or Garbage timer (240 secs) – This is the interval which states how long to wait since the last valid update before removing the route from the routing table.

Whenever a valid update is received from a neighbor, the update, invalid and flush timer resets to 0. The hold down timer resets to 0 whenever a metric gets worse.

RIP uses hop count as the metric. So in case a prefix is received from multiple path, the prefix with a smaller no of hops will be preferred. RIP allows up to 15 hops. 16 hops and above are considered to be infinite and those routes are deemed to be unreachable. This limit in the number of hops prevents loops. Unlike other protocols like OSPF and ISIS, which are link state protocols and whose implementation itself ensures loop free network, RIP uses some specific concepts which help in loop prevention. This makes RIP a great protocol in terms of implementation but this also introduces a larger convergence time.

Loop Prevention Concepts in RIP

1. Split Horizon – Even though in RIP the entire routing table is sent to the neighbors, RIP omits the routes which has been advertised by the neighbor to whom the update is being sent. In other words, if the outgoing interface of a route matches the interface out of which the new update is to be sent, then that route is omitted.
2. Route Poisoning – When a route’s reachability fails, the update is sent with the metric of that route as 16 (infinite) thereby specifying to the neighbors that the route is unreachable.
3. Poison Reverse – In this case, the route with an infinite metric is advertised out the same interface through which it is received with the same infinite metric. Split Horizon with Poison Reverse is used together in most of the cases.

These are mostly the basics of RIP. I will discuss few convergence examples in a later post.

 
I usually use a mixture of various steps. It all depends on the comfort factor. One way of learning is reading up on the topic quite extensively and then trying to implement it practically. I followed this path while learning about BGP. The first ever I had to work on for BGP was when the protocol stack was upgrading the BGP RFC implementation along with the introduction of 4 byte AS numbers. Till that time I absolutely had no clue about BGP. So it was a golden opportunity for me to learn it. Because its rare nowadays to get an opportunity to test protocols like BGP and OSPF from the scratch. How I approached here was I read through some online PDFs about BGP. Once I got comfortable with the basic terms in BGP, I directly jumped on the RFC. I always find reading a RFC very difficult. The main reason for this is I feel them quite dry. You just read and read and go on But in this case I was quite pumped up about learning BGP. So I actually went through each and every section 2 to 3 times. After all the extensive reading, I tried my hand on configuring it on my box and then went from there.

 
However for me the first way doesnt work always. The first protocol I ever learnt was RIP Now I was quite naive at that time, so reading docs and RFCs at that time was just plain not possible for me. I wouldnt have understood anything at that point. So I used the reverse way here. I directly used the configuration guides and jumped on the routers and configured RIP. Now I tried to make sense of what was going on. I got very excited when I was able to redistribute static routes and it appeared in the other router Following the implementation and config guides once I ran through the entire protocol I then went back to the books to learn in detail. And guess what I was able to understand everything now.

 
The third way, which I think I am most comfortable in, is a combination of the above. Start with the reading, get little knowledge, jump to configuring the protocol, come back to reading and go back to configuration. Or it can be the reverse, start with configs, then read then again configure. I use this method the maximum amount of time. I have been able to learn most of the switching protocols, BGP route reflectors and various other concepts using this step.
There can be various other ways for learning too. All articles, concepts and learnings I will jot down in this blog, I have learnt using one of the above ways. Hope you find them useful.