Routing

TCP механизми за регулация на трафика и congestion-control

В стандартните TCP имплементации има няколко механизма за предотвратяване на congestion:

• TCP Slow-start - това е стандартният метод за увеличаване на количеството данни, което се изпраща - в началото експоненциално започвайки от един сегмент, а след определен момент - линейно(congestion-avoidance поведение), и регулация на това количество при наличие на задръстване (congestion) някъде по мрежата след източника на трафик;
• TCP congestion-avoidance - работи заедно с TCP Slow-start и дефинира начин за регулация на нарастването на обема данни за изпращане при TCP - де факто представлява flow control при източника;
• TCP Fast retransmit -дефинира ускорено препредаване на част от данни, при получаване на минимум 3 дубликатни квитанции (duplicate acknowledgements), без да се изчаква изтичането на TCP retransmission timeout-а.
• TCP Fast recovery - след изпращането на липсващият сегмент от fast retransmit механизма, TCP продължава с линейно нарастване на количеството изпращана информация (congestion avoidance), вместо със започване на slow-start от самото начало;

TCP Slow-start

При установяване на TCP сесия една от променливите, които се инициализират в крайните възли е cwnd - congestion window. Read the rest of this entry »

Подкаст на едно кратко интервю с Джеф Дойл, в което е говори за избор на подходящ IGP, OSPF и IS-IS, и др.

 

 Standard Podcast [15:14m]: Play Now | Play in Popup | Download

Малък пример за 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-отношението да се формира отново.

Read the rest of this entry »