NetNotes

OSPF Adjacency building. ExStart. Exchange.

The following is a short description of the OSPF adjacency building process and specifically of the Database Description part of it.

We have a serial PPP interconnection between two routers, named R5 and R1. We have just set a hello interval of 5 seconds on the PPP interface serial0/1 between R1(routerID: 1.1.1.254) and R5(routerID; 1.1.1.5), which is different than the default value of 10 seconds, set on the R5 side of the link. After the expiration of the dead-interval, defaulting to 4X hello interval (calculated automatically), during which period R1 has not received a matching hello packet from R5, we can see that R1 drops the neighbor relationship for R5. We can observe this happening with the following:

R1#debug ip ospf adj

Here’s the moment when the neighbor is dropped, with a dead timer expired message, on R1:

R1#
1d16h: OSPF: 1.1.1.5 address 192.168.15.2 on Serial0/1 is dead
1d16h: OSPF: 1.1.1.5 address 192.168.15.2 on Serial0/1 is dead, state DOWN
1d16h: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.5 on Serial0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#

Let’s have a look at the neighbors R1 has for ospf process 1:

R1#sh ip ospf neighb

Neighbor ID Pri State Dead Time Address Interface
1.1.1.3 1 FULL/BDR 00:00:31 192.168.101.254 FastEthernet0/0.101
1.1.1.3 1 FULL/BDR 00:00:31 192.168.102.254 FastEthernet0/0.102
1.1.1.3 1 FULL/ - 00:01:50 192.168.123.3 Serial0/0
1.1.1.5 1 FULL/ - 00:01:55 192.168.123.5 Serial0/0
1.1.1.4 1 FULL/ - 00:01:49 192.168.123.4 Serial0/0
R1#

This confirms 1.1.1.5 has been flushed from the neighbor-table for interface serial0/1, and is no longer recognised as a valid ospf neighbor on this interface. (Note: in the topology used, we have an extra L3 link to 1.1.1.5 through serial0/0 and a frame-relay cloud, connecting to 1.1.1.5 with a specific IP address of 192.168.123.5). In such a situation, the neighbor relationship finite-state-machine cannot move into the Two-Way neighbor state, and the only thing happening are transitions between Down->Init upon receipt of each hello packet from 1.1.1.5 over the serial0/1 interface.

After we have confirmed the neighbor relationship is dropped, we can set the hello-interval back to the default value, in order to let the neighbor relationship to form again and observe the process.

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/1
R1(config-if)#ip ospf hello-interval 10
R1(config-if)#^Z
R1#

Upon receipt of the next hello packet, the neighbor relationship is formed like this:

R1#
1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0×11F6 opt 0×52 flag 0×7 len 32 mtu 1500 state INIT
1d16h: OSPF: 2 Way Communication to 1.1.1.5 on Serial0/1, state 2WAY
1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0×1793 opt 0×42 flag 0×7 len 32
1d16h: OSPF: First DBD and we are not SLAVE
1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0×1793 opt 0×52 flag 0×2 len 192 mtu 1500 state EXSTART
1d16h: OSPF: NBR Negotiation Done. We are the MASTER
1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0×1794 opt 0×42 flag 0×3 len 192
1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0×1794 opt 0×52 flag 0×0 len 32 mtu 1500 state EXCHANGE
1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0×1795 opt 0×42 flag 0×1 len 32
1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0×1795 opt 0×52 flag 0×0 len 32 mtu 1500 state EXCHANGE
1d16h: OSPF: Exchange Done with 1.1.1.5 on Serial0/1
1d16h: OSPF: Synchronized with 1.1.1.5 on Serial0/1, state FULL
1d16h: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.5 on Serial0/1 from LOADING to FULL, Loading Done
1d16h: OSPF: Build router LSA for area 0, router ID 1.1.1.254, seq 0×80000052
R1#

Here’s a short description of the format of the Database description packets:

8 bits	8 bits	16 bits
Version	Type	Packet Length
Router ID
Area ID
Checksum		AuthType
AuthInform
AuthInform
IntfcMTU		Options	0	0	0	0	0	I	M	MS
SequenceNm
LSAHeaders

The header fields are interpreted as follows:

• Version - Version of the OPSF protocol that constructed the DBD packet.
• Type - Type of the OSPF packet. For a DBD packet, this is set to type=2, or 0×02 in hex.
• Packet Length - Total packet length, measured in number of 32-bit words.
• RouterID - Router ID of the sending router.
• Area ID - Area ID of the area, the sending interface of the sedning router is in.
• Checksum - standard IP checksum (a Fletcher control sum, RFC1146, RFC905 is used inside the LSA header), calculated on all the packet content, including the packet header.
• AuthType - Type of authentication for the area the sending interface on the sending router is in.

The possible types of authentication are as follows:

• 0×0000 - No authentication => the AuthInform field is not being read and can contain whatever;

• 0×0001 - Cleartext authentication => the AuthInform field contains a clear-text password up to 64 bits in length;

• 0×0002 - MD5 authentication => the AuthInform field has the following format (every row is a single 32-bit quantity):
  
  

0×0000	KeyID	AuthDataLength
CryptographicSequenceNumber

Where the fields are as follows:

· 0×0000 - padding zeros

· KeyId - the configured key-id on the sending interface on the sending router. This has to match on the receiving router for the mechanism of authentication to work.

· AuthDataLength - Lenght of the Authentication Data information, i.e. on the actual message-digest  hash.

· CryptographicSequenceNumber - a non-decreasing Sequence Number. The lenght of this field is 32 bits => the max value for it is 0xFFFFFFFF or 2^32=4294967296
Note: the actual message-digest is appended at the end of the OSPF packet is not part of the header.

· IntfcMTU - Maximum Transmission Unit of the sending router.

The Options fielf contains flags, indicaing optional capabilities of the sending router and has the following format:

*

*

DC

EA

N/P

MC

E

T

where each of the flags is a single bit, and have the following functionality:

· * - unspecified bit. In our case, one router sets this as 01 and the other router responds with 10;

· DC - Demand Circuit - whether the sending router supports OSPF over Demand Circuits;

· EA - whether the sending router supports External Attributes LSA;

· N/P - whether the sening router supports NSSA(Not-So-Stubby-Area) areas:

· N - This is set in hello packets, where the sending router supports NSSA External LSA (type 7). If the N flag is set, the E flag has to be unset, we cannot have a router part of an NSSA to rupposrt AS External LSA(type 5) packets at the same time.

· P - this is set in NSSA External LSA (type 7) packets, that have to be sent as AS External LSA(type 5) toward the remaining areas by the NSSA ABR routers. The N and P flas have a common placeholder in the Options field because the N flag is used in hello packets, and the P flag is used in LSA packets de facto taking N’s place.

· MC - indicates whether the sending router supports multicasts (Multicast OSPF)

· E - in hello packets this shows whether the sending router supports AS External LSA (type5), this is also set in all LSA packets that come from non-stub areas. The flag is unset in hello packets of stub, totally stubbby, and NSSA routers, and also two directly connected routers with different E flags cannot form an adjacency => we can draw a conclusion that all routers within an area have to have the same support for AS External LSA, in order to form adjacencies between themselves. The same goes for Stub, Totally stubby and NSSA areas.
T - Indicates whether the sending router supports Type Of Service.

The next field is indicated as “flags” in the debug-output seen before. It is characteristic of DBD packets and has the following format:

• 0000 - padding zeros followed by the flags themselves:
• I - Initial - indicates whether this DBD packet is the first from the sending router in the current DBD exchange.
• M - More - indicates whether this DBD packet is the last one from the sending router in the current DBD exchange. If the flag is set, this is to indicate that there are more packets to follow, i.e. this is not the last DBD packet in the exchange.
• MS - Master/Slave - shows whether the sending router is the master for the current exchange. As is seen in the debu output above, this flag is always set in the initial DBD packets (ExStart state of the neigbor relationship finite-state-machine).

Let’s analyze the first DBD packet from R5:

1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0×11F6 opt 0×52 flag 0×7 len 32 mtu 1500 state INIT

If we fill in the afore-mentioned header with the information from this first packet of 1.1.1.5, the packet would be looking like this:

|0×02|0×02|0×0020|
|0×01010105|
|0×00000000|
|Chcksum|0×0000|
|0×00000000|
|0×00000000|
|0×05DC|0×0000|01010010|0000|111|
|0×11F6|
|LSA Headers|

In human language ;), the packet shows that the router with routerID 1.1.1.5 supports External Attriibutes LSA, AS External LSA, this is the first (Initial) DBD it is sending, there are more DBD packets to follow (More) and the router considers itself as the Master in this current DBD exchange.  Note: we can see that the neighbor FSM on 1.1.1.5 is in  INIT state, and after the sending of this DBD packet, it has gone into ExSTART state, in order to negotiate the Master-Slave relationship for the DBD exchange. R1 responds to this DBD packet with the following DBD packet (that besides all else will show the link-neighbor that R1 is also in EXSTART state now):

|0×02|0×02|0×0020|
|0×010101FE|
|0×00000000|
|Chcksum|0×0000|
|0×00000000|
|0×00000000|
|0×05DC|0×0000|01000010|0000|111|
|0×1793|
|LSA Headers|

R1 sends its own DBD packet, including its own Router ID of 1.1.1.254, or 0×010101FE. The interesting thing in this case are the options:
the first two (unused by specification) bits, are the inverted value (10) of the corresponding bits from the options field in R1’s DBD packet (01). RFC 2328 states that a device receiving packets with the unused bits set, has to reset them to zeros, but obviously this is not the case here. I am not sure if this is a way to designate the direction of the current packet to a specific neighbor in the DBD exchange process, or something else ;). We are also seeing that R1 hsa not indicated support for External Attributes LSA, which however is not a cause for dropping the adjacency. R1, just as R5 (they are both in the same area - backbone 0) indicates support for AS External LSA (type 5), which is normal. R1 in its turn is also setting the three flags I-Initial, M-More, and MS-Master, to show that this is also his initial DBD packet, there are more to follow, and that it considers itself to be the master for the DBD exchange session over this link. R1 has all the right to indicate itself as the Master, because its Router ID (1.1.1.254) is bigger than thе RouterID-то of the link-neighbor(1.1.1.5). From this moment on, R5 has to accept R1 as Master, with the following consequences:
1. R5 will never send any more DBD packets with the MS flag set;
2. R5 will use the numbering context of R1, i.e. the DBD packets that it sends will be numbered related to the numbers of R1.
The debug message “OSPF: First DBD and we are not SLAVE” on R1 shows this same thing.

1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0×1793 opt 0×42 flag 0×7 len 32
1d16h: OSPF: First DBD and we are not SLAVE

We can see R5’s reply in the next DBD packet received (R5 is in EXSTART):

1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0×1793 opt 0×52 flag 0×2 len 192 mtu 1500 state EXSTART

|0×02|0×02|0×00C0|
|0×01010105|
|0×00000000|
|Chcksum|0×0000|
|0×00000000|
|0×00000000|
|0×05DC|0×0000|01010010|0000|010|
|0×1793|
|LSA Headers|

This DBD pcaket is very similar to the previous one sent by R5, with the following differences:

• the packet length is different(0×00C0), because of the LSA headers it contains;
• The Init flag(this is now the second DBD packet from R5, not Initial) and the MS flag(1.1.1.5 is not the Master for this DBD exchange) are now unset, and the flags are 010, or 0×02 in hex.
• Obviously R5 already knows from R1’s DBD packet that it(R5) should not be the Master in the current DBD exchange, so it has unset the MS flag in its own DBD packets. Also, as we can see from the SequenceNm field (0×1793, or the same as the SequenceNm of R1), R5 is now numbering its DBD packets in the context of the numbers at R1, and it even uses the same number as the one sent by R1, by which it actually does a DBD Acknowledgement, acknowledging the successful receipt of the DBD packet of R1.

After the receipt of this DBD packet, the link neighbor - R1, is now certain that it has been confirmed as a master by the other side on the link which is confirmed by the following debug message:

1d16h: OSPF: NBR Negotiation Done. We are the MASTER

From now on, R1 can continue with the description of its own Link-State database and to receive R5’s acknowledgements that also contain R5’s own Link-State Database.

1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0×1794 opt 0×42 flag 0×3 len 192

|0×02|0×02|0×00C0|
|0×010101FE|
|0×00000000|
|Chcksum|0×0000|
|0×00000000|
|0×00000000|
|0×05DC|0×0000|01000010|0000|011|
|0×1794|
|LSA Headers|

SequenceNm of 0×1794 goes to show that this is the next DBD packet in the numbering scheme of the Master-router, the Initial flag is now unset, the More flag is set, and so is the MS flag, indicating Master status. Following is an ackowledgement from R5 that shows it is now in Exchange state:

1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0×1794 opt 0×52 flag 0×0 len 32 mtu 1500 state EXCHANGE

|0×02|0×02|0×0020|
|0×01010105|
|0×00000000|
|Chcksum|0×0000|
|0×00000000|
|0×00000000|
|0×05DC|0×0000|01010010|0000|000|
|0×1794|
|LSA Headers|

The flags are now 000 meaning that this DBD packet is the last one from R5. R1 sends back the following DBD packet:

1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0×1795 opt 0×42 flag 0×1 len 32

|0×02|0×02|0×0020|
|0×010101FE|
|0×00000000|
|Chcksum|0×0000|
|0×00000000|
|0×00000000|
|0×05DC|0×0000|01000010|0000|001|
|0×1795|
|LSA Headers|

This shows that this is the last packet from R1’s Database Description process, and what follows is an acknowledgement from R5:

1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0×1795 opt 0×52 flag 0×0 len 32 mtu 1500 state EXCHANGE

|0×02|0×02|0×0020|
|0×01010105|
|0×00000000|
|Chcksum|0×0000|
|0×00000000|
|0×00000000|
|0×05DC|0×0000|01010010|0000|000|
|0×1795|
|LSA Headers|

With this, the DBD exchange process is supposed to finish, and each of the routers should go into a LOADING or FULL state:

1d16h: OSPF: Exchange Done with 1.1.1.5 on Serial0/1
1d16h: OSPF: Synchronized with 1.1.1.5 on Serial0/1, state FULL

And this is when we see the normal syslog message for a neighbor coming up:

1d16h: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.5 on Serial0/1 from LOADING to FULL, Loading Done

as well as a Router LSA being sent for area 0:

1d16h: OSPF: Build router LSA for area 0, router ID 1.1.1.254, seq 0×80000052
R1#

Which completes the process.

No comments yet.

Leave a comment