Категория: networking

Преди няколко дни Cisco обяви, че купува компанията, продаваща устройства за e-mail и web security IronPort – компания, на която самите те са били „дългогодишен клиент“. IronPort, с обявени приходи от близо $25 млн. за 2005, ще бъде закупена за обща цена от близо $830 млн. като плащането ще включва прехвърляне на акции, а сделката по сливането се очаква да бъде приключена през третата четвърт на фискалната 2007г.

IronPort е основана през 2000г. от Scott Weis, който е бивш Microsoft executive. Компанията развива устройства за E-mail и Web Security, работещи с тяхната AsyncOS, базиранa на BSD ядро, което хората от IronPort са модифицирали, с пренаписан mail-transfer-agent, OEM-нат Sophos като антивирусен engine, и оптимизирана работа с паметта. В частност за работата с паметта AsyncOS разчита на т.нар. „Stackless Thread Model“, който позволява на устройствата да издържат до 10 000 едновременни конекции (по думи на IronPort 😉 ). Личният ми опит с IronPort e крайно ограничен Чети по-нататък ( 3 мин)

Малък пример за 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 0x11F6 opt 0x52 flag 0x7 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 0x1793 opt 0x42 flag 0x7 len 32
1d16h: OSPF: First DBD and we are not SLAVE
1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x1793 opt 0x52 flag 0x2 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 0x1794 opt 0x42 flag 0x3 len 192
1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x1794 opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0x1795 opt 0x42 flag 0x1 len 32
1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x1795 opt 0x52 flag 0x0 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 0x80000052
R1#

Кратко пояснение на формата на Database Description (DBD) пакетите:

Полетата в заглавната част се използват както следва:

• Version – Версия на OSPF протокола, която е формирала този DBD пакет.
• Type – тип на OSPF пакета. За DBD пакет това е type=2, или 0x02 в hex-запис.
• Packet Length – Обща дължина на пакета, в брой 32-битови думи.
• RouterID – ID номера на ospf процеса на изпращащия рутер.
• Area ID – номера на area-та, в която се намира ospf интерфейса на изпращащия рутер.
• Checksum – стандартна IP контролна сума (в самият LSA Header за контролна сума се използва контролна сума на Флечър, RFC1146, RFC905), изчислена върху целия пакет, вкл. заглавната част.
• AuthType – вид на автентикацията за областта, в която се намира изпращащият интерфейс на изпращащият рутер.

Възможните видове автентикация са:

• 0x0000 – Липса на автентикация, => полето AuthInform не се чете и може да съдържа каквото и да било;

• 0x0001 – Cleartext автентикация => полето AuthInform съдържа парола в некриптиран текст, до 64 бита големина;

• 0x0002 – MD5 Автентикация => полето AuthInform има вида (всеки ред е една 32-битова дума):
  
  

където полетата са следните:

· 0x0000 – 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 0x11F6 opt 0x52 flag 0x7 len 32 mtu 1500 state INIT

Попълнен с OSPF информацията от конкретната ситуация, използвайки първия debug-нат пакет от 1.1.1.5, пакета би изглеждал така:

|0x02|0x02|0x0020|
|0x01010105|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|01010010|0000|111|
|0x11F6|
|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):

|0x02|0x02|0x0020|
|0x010101FE|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|01000010|0000|111|
|0x1793|
|LSA Headers|

R1 изпраща собствен DBD пакет, като включва собственото си Router ID 1.1.1.254, или 0x010101FE. Интересното в случая са опциите:
първите два (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 0x1793 opt 0x42 flag 0x7 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 0x1793 opt 0x52 flag 0x2 len 192 mtu 1500 state EXSTART

|0x02|0x02|0x00C0|
|0x01010105|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|01010010|0000|010|
|0x1793|
|LSA Headers|

DBD пакета е много подобен на предишния изпратен от R5, със следните разлики:

• дължина на пакета е различна(0x00C0), заради съдържаните LSA хедъри;
• Флаговете Init(това вече е втори DBD пакет от R5, не е Initial) и MS(1.1.1.5 не е Master в текущия DBD обмен) вече са свалени, и флаговетв са 010, или 0x02.
• Очевидно R5 евче е разбрал от DBD пакета на R1, че той(R5) не е Master в текущия DBD обмен,затова е свалил MS флага в собствените си DBD пакети. Освен това, както се вижда от полето SequenceNm (0x1793, или същото като 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 0x1794 opt 0x42 flag 0x3 len 192

|0x02|0x02|0x00C0|
|0x010101FE|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|01000010|0000|011|
|0x1794|
|LSA Headers|

SequenceNm от 0x1794 показва, че това е следващият DBD пакет от номерацията на Master-рутера, Initial флага е свален, вдигнат е флага More, и флага MS, за Master. Следва потвърждение R5, което показва, че от предишния пакет и той вече е в съсояние Exchange:

1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x1794 opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE

|0x02|0x02|0x0020|
|0x01010105|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|01010010|0000|000|
|0x1794|
|LSA Headers|

Флаговете са вече 000, което значи, че този DBD пакет е последният от R5. R1 праща обратно следният DBD пакет:

1d16h: OSPF: Send DBD to 1.1.1.5 on Serial0/1 seq 0x1795 opt 0x42 flag 0x1 len 32

|0x02|0x02|0x0020|
|0x010101FE|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|01000010|0000|001|
|0x1795|
|LSA Headers|

От който се вижда, че това е последният пакет и от неговият Database Description процес. Следва потвърждение от R5:

1d16h: OSPF: Rcv DBD from 1.1.1.5 on Serial0/1 seq 0x1795 opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE

|0x02|0x02|0x0020|
|0x01010105|
|0x00000000|
|Chcksum|0x0000|
|0x00000000|
|0x00000000|
|0x05DC|0x0000|01010010|0000|000|
|0x1795|
|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 0x80000052
R1#

С което процесът приключва.