Initial Database Exchange
For the SPF algorithm to work properly, all routers in the area should have the same database information on which the SPF algorithm works. The process of synchronization includes the “Initial Database Exchange” which is done when the adjacency is coming up and the asynchronous flooding when the Adjacencies are up.
– A master-slave relation is established to do the database exchange. Besides the MTU is exchanged in the database description packets before any database exchange starts.
– The database exchange begins once the adjacency state reaches Exstart. On a broadcast links, the DR and BDR form adjacencies with all other routers on the network.
– Only one DB Description packet can be unacknowledged at a time that is, the window size is 1. Each DB Description packet from the master is acknowledged by the slave. The slave sends its own DB Description packet with similar identifiers as the masters. This is important because if you miss even one DD packet, then the routers have to start all over again.
– DB description packets containing the summary of LSA’s at each end are exchanged. Only when the entire summary is received by the neighbour can it tell which instance of the LSA is not there in the senders database.
– An adjacency in OSPF is declared FULL/UP, when the entire database exchange is completed.
– OSPF does not allow routers to resynchronize their link state database in the steady state. It is only done during the initial database synchronization or when network topology changes. However, there are techniques to do that. One such way is described in “OSPF Out-of-band LSDB resynchronization”
– The MTU check is done at the hello exchange time itself.
– CSNP’s are sent by the DIS on a broadcast link. On a point-to-point link both the neighbours exchange CSNP’s with each other.
– On point-to-point link all the LSP’s SRM flag is also set for the circuit, to indicate the LSP’s have to be sent over the circuit.
– The CNSP’s are sent to reduce the actual flooding of all the LSP’s between the neighbours.
– Multiple CSNP’s can be sent together. CSNP’s unlike DB Descriptions in OSPF are not acknowledged.
– As the CSNP’s have a range of LSP-ID’s, and contain all the LSP’s in the database falling in that range. A neigbour on receiving a CSNP can know which LSP’s in the neighbour are newer, which older and which are absent. Based on this the neighbour can send newer LSP’s to the neighbour.
– Link state database is continuously refreshed and synchronized because of the periodic CSNPs that are announced.
Whenever any information in an the database changes, the information is to be exchanged with all other routers in the network. This is done by the flooding process:
– Uses reliable flooding mechanism for all link types.
– Changed LSA’s are packed in LS Update packets and send over adjacencies to the neighbour, which unpacks the LSA’s. LS Acknowledgement packets are sent by the receiver, which informs the sender that the receiver has received the LSA.
– The sender retransmits the LSA’s after the re-transmission interval if it does not get acknowledgements for them.
– On a broadcast link LSUpdate packets are sent only to all-DR routers multicast address. The DR floods the LSUpdate packets to All-SPF-Routers.
– Whenever a new DR/BDR is elected, it has to form adjacencies with all other routers in the network.
– There is no difference in the asynchronous flooding procedures between OSPFv2 and OSPFv3.
– LSP’s are flooded as is across the area. They are not packed inside any other packet.
– On broadcast links flooding is not done reliably. A changed LSP is flooded to all IS-IS routers, however no retransmissions occur.
– The reliability in database exchange on a broadcast link is achieved by periodic database exchange. This is done as CSNP’s are sent periodically by the DIS, which initiates the entire database exchange process all over again.
– As the DIS sends periodic CSNP, nothing different needs to be done when a new DIS is exchanged.
– On a point-to-point link flooding is done reliably. LSP’s are flooded to the neighbour and if CSNP entry for the LSP is not received in a particular time interval, the LSP is re-flooded to that neighbour.
5 thoughts on “Database Exchange and Flooding in OSPF and IS-IS ..”
>- On broadcast links flooding is not done reliably. A changed LSP is >flooded to all IS-IS routers, however no retransmissions occur.
Reliability is, of course, assured on broadcast links by IS-IS.
It is just accompished in a much leaner fashion by the DIS’s use of the broadcasting the CSNP.
Each IS, tracks its LSDB content vs. the DIS’s periodic CSNP.
If the IS has a newer LSP than that listed in the CSNP, the IS broadcasts the newer LSP to the DIS (and all the other ISs on the link).
The DIS, receives the newer LSP, processes it and updates the CSNP.
When the DIS next sends the CSNP, the original-updating-IS, checks the CSNP and if the LSP is still not newer — the IS broadcasts the LSP to the DIS and the link (again)…until a received CSNP shows the update.
Reliability achieved (without per-neighbor retransmission lists, etc.)!
Reblogged this on minghuasweblog and commented:
A good writing about OSPF exchange process.
hey there and thank you for your info – I have certainly
picked up anything new from right here. I did however expertise some technical issues using this site, since I experienced to reload the site a lot of times previous to I could get it to load correctly.
I had been wondering if your web host is OK? Not that I’m complaining, but slow loading
instances times will sometimes affect your placement in google
and could damage your high-quality score if advertising and
marketing with Adwords. Well I’m adding this RSS to my email and can look out for much more of your
respective exciting content. Ensure that you update this again soon.