this is my second post here trying to understand OSPF. Looks like every reading materials I tried is skeeping the answer to my confusion )-; therefor - here is my post and sorry that its a long one...
I'll try to describe a scenario and the stages which a new router is going when joining to BMA segment running OSPF. Please confirm or decline my understanding at every stages and help me understand where i was wrong.
Lets say that there are 5 routers connected to a segment and a DR/BDR are already elected. the 6'th router (Router F) will not cause a new election:
1. The first state of Router F is the DOWN state. as i understand this is when Router F set its hello packet with no neighbors, 0.0.0.0 as DR/BDR (and i'm ignoring the rest of the parts in the packet).
2. The second state is the INIT state. as I understand this is when Router F sends its Hello packet (184.108.40.206) and starting to listen to other Hello Packets (220.127.116.11) in the segment (for the defined period of time). Other routers learns the new router, adding him to the neighbors list and updating their Topologey table.
3. The third state is the 2-Way State. Any hello packet containing Router F in the neighbors list cause Router F to add the source to Router f's neighbor list and creates a 2-Way state with this particular source. if in my example there are 6 routers then Router F will have 5 2-Way states (one for each router, regardless the roll DR/BDR/DROTHER).
4. Router F starts dicovering routes. this tates is called Exstart state. As I understand, this state is only between Router F and the DR. they determaning master/slave reletionship (who is gonna speak first). Not sure thu by which multicast address (18.104.22.168 or 22.214.171.124; or is it unicast?)
5. Both routers exchanging DDPs, changing their states to Exchange state. still not sure by which address?
6. Router F sends LSR to its neighbor (The DR). This is the Loading state. they exchange LSAs and LSUs between each other. Is it true that this is when Router F is creating its DBs? again, which address is used at this stage to talk between the DR and Router F?
7. The Full state is when the DR and Router F has successfully exchanged all data and the DBs are fully synced. Router F and the DR are now Fully Adjacent. what i dont understand is if at that point I'll run the command "sh ip ospf neighbor" at Router F, I'll see that Router-F's state with the BDR is FULL as well (even thu no real info was exchanged between the two) does Router-F automaticaly define the state as FULL with its BDR when it is fully synced with the DR?
1. For starters, pls keep in in that the states you are describing for router F are per-neighbor. Therefore, it's more accurate to state that router F is a 'down' state with a specific neighbor instead of just saying that router F is in a down state. Therefore, in this step, router F will be in a down state for each neighbor from each it has not received a Hello.
2. Router F will enter the Init state for a neighbor only when it receives a Hello from that neighbor, not when it sends a Hello to that neighbor.
3. A non-DR (DROther) will only enter the Two-Way state with non-DR neighbors. For a neighbor relationship with a DR or BDR, the state will proceed straight to ExStart. In your example, at this point in the proceedings, you should have 3 Two-Way state and two in ExStart.
4. There is no 'discovery' of routes in this state. All that happens in ExStart is to determine the Master/Slave for Database Exchange. In ExStart, the packets exchanged are unicast.
5. The packet exchange is unicast in the Exchange state too.
6. The exchange of Link State Request and Link State Update packets is unicast in the Loading state. Router F will already have a database before this point (even if router F has no neighbors, it needs a database to store its own router-LSA).
7. Router F will run through the complete ExStart/Exchange/Loading/Full process with the BDR as well as the DR. That's why you see it as full.
On broadcast networks, the Link State Update packets are multicast. The destination IP address specified for the Link State Update Packet depends on the state of the interface. If the interface state is DR or Backup, the address AllSPFRouters should be used. Otherwise, the address AllDRouters should be used.
On non-broadcast networks, separate Link State Update packets must be sent, as unicasts, to each adjacent neighbor (i.e., those in state Exchange or greater). The destination IP addresses for these packets are the neighbors' IP addresses.
The IP destination address for the packet is selected as follows. On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters. On all other network types (including virtual links), the majority of OSPF packets are sent as unicasts, i.e., sent directly to the other end of the adjacency. In this case, the IP destination is just the Neighbor IP address associated with the other end of the adjacency (see Section 10). The only packets not sent as unicasts are on broadcast networks; on these networks Hello packets are sent to the multicast destination AllSPFRouters, the Designated Router and its Backup send both Link State Update Packets and Link State Acknowledgment Packets to the multicast address AllSPFRouters, while all other routers send both their Link State Update and Link State Acknowledgment Packets to the multicast address AllDRouters. Retransmissions of Link State Update packets are ALWAYS sent directly to the neighbor. On multi-access networks, this means that retransmissions should be sent to the neighbor's IP address. The IP source address should be set to the IP address of the sending interface. Interfaces to unnumbered point-to-point networks have no associated IP address. On these interfaces, the IP source should be set to any of the other IP addresses belonging to the router. For this reason, there must be at least one IP address assigned to the router. Note that, for most purposes, virtual links act precisely the same as unnumbered point-to-point networks. However, each virtual link does have an IP interface address (discovered during the routing table build process) which is used as the IP source when sending packets over the virtual link.
I'm afraid I will have to disagree with you here. Section 13.3 of RFC2328 describes the flooding process, whereas we are discussing Database Exchange here. Your second quote from the RFC is a bit more general and leaves this bit of the protocol unclear. I believe that LS Updates sent in response to LS Requests are unicast. However, to get a definitive answer, I just labbed this up on a Cisco router and my Ethereal captures back me up on this. The LS updates sent in response to LS requests *are* unicast. This does make sense: this is a private conversation between two neighbors, so why involve others in it.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...