Малък пример за OSPF adjacency building и по-специално за Database Description процеса.
Имаме серийна PPP връзка м/у два рутера - R5 и R1. Току-що сме задали hello интервал на PPP интерфейс(serial 0/1) м/у R1(Router ID: 1.1.1.254) и R5(Router ID: 1.1.1.5) на 5 секунди, което е различно от стойността по подразбиране от 10 секунди, която е настроена на R5. След изтичането на dead-интервала (4х hello, автоматично изчислен) на R1, за което време той не е получил съответстващ hello пакет от R5, R1 дропва neighbor-отношението. Използваната команда за показване на тези отношения е:
R1#debug ip ospf adj
Ето и дропването на neighbor-a, с log съобщение за dead timer expired на 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#
Преглед на съседите за ospf process id 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#
Което потвърждава, че 1.1.1.5 е flush-нат от neighbor-таблицата, за интерфейс Serial0/1 и вече не се разпознава като ospf neighbor за този интерфейс.. (Заб: в използваната топология, имаме още един директен L3 линк към 1.1.1.5 през S0/0, който е свързан през Frame Relay облак към 1.1.1.5 с ip address 192.168.123.5) В такава ситуация, автомата на съседските отношения не може да премине в състояние Two-Way, единственото което се случва с него са преходи от Down->Init при всеки получен hello пакет от 1.1.1.5 през интерфейс S0/1.
След като сме установили пропадането на neighbor отношението, можем да вдигнем отново hello-интервала на стойността по подразбиране, за да оставим neighbor-отношението да се формира отново.
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#
При следващият hellо, neighbor-отношението се инициализира така:
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#
Кратко пояснение на формата на Database Description (DBD) пакетите:
|
8 бита
|
8 бита
|
16 бита
|
|
Version
|
Type
|
Packet Length
|
|
Router ID
|
|
Area ID
|
|
Checksum
|
AuthType
|
|
AuthInform
|
|
AuthInform
|
|
IntfcMTU
|
Options
|
0 |
0 |
0 |
0 |
0 |
I |
M |
MS |
|
SequenceNm
|
|
LSAHeaders
|
Полетата в заглавната част се използват както следва:
- Version - Версия на OSPF протокола, която е формирала този DBD пакет.
- Type - тип на OSPF пакета. За DBD пакет това е type=2, или 0×02 в hex-запис.
- Packet Length - Обща дължина на пакета, в брой 32-битови думи.
- RouterID - ID номера на ospf процеса на изпращащия рутер.
- Area ID - номера на area-та, в която се намира ospf интерфейса на изпращащия рутер.
- Checksum - стандартна IP контролна сума (в самият LSA Header за контролна сума се използва контролна сума на Флечър, RFC1146, RFC905), изчислена върху целия пакет, вкл. заглавната част.
- AuthType - вид на автентикацията за областта, в която се намира изпращащият интерфейс на изпращащият рутер.
Възможните видове автентикация са:
- 0×0000 - Липса на автентикация, => полето AuthInform не се чете и може да съдържа каквото и да било;
- 0×0001 - Cleartext автентикация => полето AuthInform съдържа парола в некриптиран текст, до 64 бита големина;
- 0×0002 - MD5 Автентикация => полето AuthInform има вида (всеки ред е една 32-битова дума):
|
0×0000
|
KeyID
|
AuthDataLength
|
|
CryptographicSequenceNumber
|
където полетата са следните:
· 0×0000 - padding zeros 
· KeyId - конфигурираният key-id на изпращащия интерфейс на изпращащият рутер. Трябва да е същия на получаващият рутер за да работи механизма на автентикация успешно. AuthDataLength - дължина на Authentication Data информацията, т.е. на самият message-digest хеш.
· CryptographicSequenceNumber - ненамаляващ Sequence Number. Големината на полето е 32 бита => максималната му стойност е 0xFFFFFFFF или 2^32=4294967296
Заб: самият message-digest хеш се добавя след края на OSPF пакета, и не е част от хедъра.
· IntfcMTU - Maximum Transmission Unit на изпращащия рутер.
Полето Options съдържа флагове, показващи опционални възможности на изпращащия рутер и има следния вид:
като всеки от флаговете е по 1 бит, и има следната функционалност:
· * - неспецифициран бит. В нашият случай, единия neighbor задава тези два бита като 01, а в отговора си другият рутер връща 01;
· DC - Demand Circuit - показва дали изпращащият рутер поддържа OSPF over Demand Circuits;
· EA - Показва дали изпращащият рутер поддържа External Attributes LSA;
· N/P - този флаг указва поддръжката на NSSA области:
· N - задава се в hello пакети, когато изпращащият рутер поддържа NSSA External LSA (type 7). Ako флага N е вдигнат, E трябва да е свален, защото може един рутер, който е част от NSSA да поддържа и AS External LSA(type 5) пакети.
· P - задава се в NSSA External LSA (type 7) пакети, които трябва да бъдат изпратени като AS External LSA(type 5) към останалите области от NSSA ABR рутерите. Двата флага заемат едно и също място в Options полето, защото единия (N) се използва в hello, а другият (P) се използва в LSA пакети (и де факто заема мястото на N).
· MC - показва дали изпращащият рутер поддържа multicasts (Multicast OSPF)
· E - в hello пакетите показва дали изпращащият рутер поддържа AS External LSA (type5), също така е вдигнат и във всички LSA, които произлизат от non-stub области. Флагът е свален в hello пакетите на stub, totally stubbby, и NSSA рутери, осве това директно свързани рутери с различни E-флагове не могат да станат adjacent, => можем да заключим че всички рутери в една област трябва да поддържат еднакво AS External LSA, за да станат adjacent помежду си. Същото важи и за Stub, Totally stubby и NSSA областите.
T - Показва дали изпращащият рутер поддържа Type Of Service.
Следващото поле е изписано като “flags” в debug-output-а по-горе. То е характерно за DBD пакетите и има такъв формат:
- 0000 - padding zeros след котйто следват флаговете:
- I - Initial - показва дали този DBD пакет е е първият за изпращащия рутер в текущия DBD обмен.
- M - More - показва дали този DBD пакет е последният за изпращащия рутер в текущия обмен. Ако флага е вдигнат, това показва че този DBD пакет не е последен.
- MS - Master/Slave - показва дали изпращащият рутер е master в текущия обмен. Както се вижда от debug output-а по-горе, този флаг винаги е вдигнат в първите DBD пакети, които се обменят (ExStart състояние на автомата на neighbor отношението).
Да вземем първия получен DBD пакет от 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
Попълнен с OSPF информацията от конкретната ситуация, използвайки първия debug-нат пакет от 1.1.1.5, пакета би изглеждал така:
|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|
С човешки думи , пакетът казва, че рутер 1.1.1.5 поддържа External Attriibutes LSA, поддържа AS External LSA, това е първият (Initial) DBD който изпраща, последван от други (More) и текущият рутер се смята за Master в текущия DBD обмен. Заб: вижда се, че neighbor-автомата на 1.1.1.5 е състояние INIT, а след изпращането на този пакет е влязъл в състояние ExSTART, за договаряне на Master-Slave отношенията за DBD обмена. На този DBD пакет, R1 отговаря със следния DBD пакет (който освен всичко друго ще покаже на link neighbor-a, че R1 същто вече е в EXSTART):
|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 изпраща собствен DBD пакет, като включва собственото си Router ID 1.1.1.254, или 0×010101FE. Интересното в случая са опциите:
първите два (unused по спецификация) бита, са инвертираната стойност (10) на съответните битове от опциите на R1 (01). В RFC 2328 е указано, че устройство което получава пакети със сетнати unused-битове, трябва да ги резетва на нули, но тук явно не е така, което не съм убеден дали не е начин за означаване посоката на даден пакет към определен рутер в процеса на DBD обмен, иlи пък нещо друго . Освен това виждаме, че R1 не е означил поддържка за External Attributes LSA, което обаче не е причина за разпадане на adjacency-то. R1, също както и R5 (и двата са в една област - backbone 0) показва поддръжка за AS External LSA (type 5), което е нормално. R1 от своя страна също вдига и трите флага (I-Initial, M-More, MS-Master), заа да покаже че това също е неговият начален DBD пакет, след него има още, и той трябва да стане master за DBD сесията на този линк. R1 всъщност има пълното право да се обозначи като Master, защото неговото Router ID (1.1.1.254) е по-голямо от RouterID-то на линк-съседа(1.1.1.5). Оттук нататък, R5 трябва да приеме R1 за Master, от което следват две неща:
1. R5 няма да праща повече DBD пакети с вдигнат MS флаг;
2. R5 ще използва контекста за номериране на R1, т.е. DBD пакетите, които той праща ще бъдат номерирани с номерата на R1.
Debug съобщението “OSPF: First DBD and we are not SLAVE” на R1 показва това още един път.
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
Можем да видим отговора на R5 в следващия получен DBD пакет (R5 е в състояние 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|
DBD пакета е много подобен на предишния изпратен от R5, със следните разлики:
- дължина на пакета е различна(0×00C0), заради съдържаните LSA хедъри;
- Флаговете Init(това вече е втори DBD пакет от R5, не е Initial) и MS(1.1.1.5 не е Master в текущия DBD обмен) вече са свалени, и флаговетв са 010, или 0×02.
- Очевидно R5 евче е разбрал от DBD пакета на R1, че той(R5) не е Master в текущия DBD обмен,затова е свалил MS флага в собствените си DBD пакети. Освен това, както се вижда от полето SequenceNm (0×1793, или същото като SequenceNm на R1), R5 номерира своите DBD пакети в контекста на R1, като дори използва същия номер, като изпратения от R1, с което де факто прави и DBD Acknowledgement, потвърждавайки успешното получаване на DBD пакета на R1.
След получаването на такъв DBD пакет линк-съседа, R1 вече е сигурен, че е приет за master от отсрещната страна на линка, което се потвърждава от съобщението:
1d16h: OSPF: NBR Negotiation Done. We are the MASTER
Оттук нататък, R1 може да продължи с описанието на собствената си Link-State база данни, и да получава обратно потвържденията на R5, съдържащи собствената му LSDB.
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 от 0×1794 показва, че това е следващият DBD пакет от номерацията на Master-рутера, Initial флага е свален, вдигнат е флага More, и флага MS, за Master. Следва потвърждение R5, което показва, че от предишния пакет и той вече е в съсояние Exchange:
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|
Флаговете са вече 000, което значи, че този DBD пакет е последният от R5. R1 праща обратно следният DBD пакет:
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|
От който се вижда, че това е последният пакет и от неговият Database Description процес. Следва потвърждение от 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|
С това процеса на DBD обмен трябва да приключи, всеки от рутерите да влезе в състояние на LOADING или FULL:
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
Следва нормалното Syslog съобщение за вдигнат съсед:
1d16h: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.5 on Serial0/1 from LOADING to FULL, Loading Done
Както и изпращане на Router LSA за област area 0:
1d16h: OSPF: Build router LSA for area 0, router ID 1.1.1.254, seq 0×80000052
R1#
С което процесът приключва.
