Hello Pankaj,
The Master and Slave in OSPF are a slightly confusing concept but the idea behind it is quite simple.
When two routers decide to become fully adjacent, they must synchronize their LSDBs. OSPF tries to optimize this: the routers first exchange only the list of entries in their LSDBs. Each router compares the received list to the list of items in its own database, and if it finds that an LSA is missing or is older than one the neighbor knows about, it requests it from the neighbor afterwards. This way, both routers transmit only the missing or updated LSAs, not the entire LSDBs.
The list of LSDB entries is carried in Database Description (DBD) packets. Naturally, when routers exchange DBD packets, they must be sure all of them have been properly received by the neighbor, so some sort of acknowledgements must be used. There is a problem here, however: the only packets in OSPF used to carry acknowledgements are LSAck packets, but they can only be used to acknowledge LSU packets (more precisely, individual LSAs carried in LSU packets), not DBD packets. How shall the acknowledgements of DBD packets be accomplished, then?
OSPF uses a polling style of communication with the DBD packets. DBD packets themselves have sequence numbers used for sequencing and acknowledgement purposes. One of the two routers that are in the synchronization phase will be the one responsible for polling the other (i.e. calling it out it to send another piece of information if it has any), each time with an incremented sequence number. This is the Master role. The other router will only be allowed to respond to a DBD poll, never send any DBD packet without being polled immediately before, and the response DBD packet must carry the sequence number of the Master's DBD poll packet. This is the Slave role. The Slave must respond to each Master's DBD packet even if it has no more LSDB entries to advertise; in that case, the DBD response body will be empty.
So during the DBD exchange, the Master sends DBD packets to Slave, incrementing the sequence number by one in each round. The Slave waits for DBD packets from the Master and only responds to them, and each response carries the sequence number from the last received Master's DBD packet that was used to poll the Slave. Remember: a Slave must not send DBD packets on its own, only as responses to DBD packets received from the Master, and the sequence number of the Slave's response DBD packet must be set to the Master's poll DBD packet.
While I call the DBD packets as "polls" and "responses" here for the sake of clarity, the DBD packets do not have this distinction indicated explicitly. Any DBD packet sent from the Master, either with a body carrying a list of LSAs or an empty body, is a poll. Any DBD packet sent from the Slave, again either with a non-empty or empty body, is a response. A DBD packet can have an empty body if the router needs to send a DBD packet to the neighbor (either from Master to repeatedly poll the Slave, or from the Slave to confirm the arrival of the DBD packet from the Master) but has no more LSDB entries to advertise itself.
There are two issues with this simple procedure. First, there is the issue of who out of two synchronizing routers will be the Master and who will be the Slave. This is resolved during the ExStart phase: both routers initially treat themselves as Master routers, and send DBD packets with random initial sequence numbers to each other, indicating the MS flag (Master) in their header. As they do this, the router with the lower RouterID moves to the Slave role, while the router with the higher RouterID remains in the Master role. The ExStart phase is basically finished after establishing the router's role in the synchronizing pair; at most two DBD packets are needed for that, one from each router. The Exchange phase then lasts until routers have exchanged the entire list of their LSDB entries using DBD packets.
The second issue is more subtle: how should the Master know whether the Slave needs to be polled further? Clearly, a situation may arise when the Master's LSDB is empty or smaller than the Slave's, and the Master will need to send fewer DBDs than the Slave to list all its LSDB contents. As the Slave can not send a DBD packet on its own, it somehow needs to tell the Master to poll it again. This is accomplished by another flag in DBD packet header, the M (More) flag. If a Slave replies to the Master's DBD packet with its own DBD packet and the M flag set, the Master knows the Slave needs to be polled again. The Master will stop polling the Slave after the last DBD packet fom the Slave has the M flag cleared.
The RFC 2328 has a nice ASCIIart graph of the adjacency coming up:
+---+ +---+
|RT1| |RT2|
+---+ +---+
Down Down
Hello(DR=0,seen=0)
------------------------------>
Hello (DR=RT2,seen=RT1,...) Init
<------------------------------
ExStart D-D (Seq=x,I,M,Master)
------------------------------>
D-D (Seq=y,I,M,Master) ExStart
<------------------------------
Exchange D-D (Seq=y,M,Slave)
------------------------------>
D-D (Seq=y+1,M,Master) Exchange
<------------------------------
D-D (Seq=y+1,M,Slave)
------------------------------>
...
...
...
D-D (Seq=y+n, Master)
<------------------------------
D-D (Seq=y+n, Slave)
Loading ------------------------------>
LS Request Full
------------------------------>
LS Update
<------------------------------
LS Request
------------------------------>
LS Update
<------------------------------
Full
The I flag here is another flag in DBD headers called the Init flag, and is set only on initial DBD packets in the ExStart phase. If the router has established its Master or Slave role, it clears the I flag. This one is not really that important right now.
The Master/Slave relationship is built and relevant only during the initial LSDB synchronization when a new adjacency is being established. After the two routers go past the Exchange state, DBD packets are not used anymore, and the whole Master/Slave relationship is forgotten. Remember: Master/Slave is relevant only to DBD packets, and DBD packets are used only in ExStart/Exchange phases. Outside of these states, there are no DBD packets used, hence no Master/Slave relationships exist.
If there are, say, four routers, R1 till R4, connected to the same switch and run OSPF, during the OSPF bootup, there will be 5 temporary Master/Slave relationship built and torn down afterwards:
- between the DR and BDR as they synchronize (assume those routers are R1 and R2)
- between R3 and DR
- between R3 and BDR
- between R4 and DR
- between R4 and BDR
Notice the Master/Slave relationship existed between those routers that went through ExStart and Exchange into the Full state. Also keep in mind that in the Full state, there are no more Master/Slave relationship present - they were only needed because of the specific needs of the DBD packet exchange.
Does this make the issue a little more clear? Please feel welcome to ask further!
Best regards,
Peter
