NetNotes

TCP congestion control и queueing

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. › Continue reading

Tags: congestion avoidance, congestion control, QoS, queueing, slow-start, TCP

Port-channel

Имаме следната настройка на port-channel между два Catalyst 3750 - SW1 Gig1/0/1 и Gig1/0/2, комбинирани в port-channel1 са свързани към Gig1/0/1 и Gig1/0/2 на SW2:

SW1:

interface GigabitEthernet1/0/1
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface GigabitEthernet1/0/2
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface Port-channel1
description to SW2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate

SW2:

interface GigabitEthernet1/0/1
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface GigabitEthernet1/0/2
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface Port-channel1
description to SW1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate

За да се формира успешно portchannel интерфейса, всички членове на portchannel-а трябва да имат еднакви: › Continue reading

Tags: port-channel, Switching

Планиране на капацитет за VoIP

Няколко са основните неща при планиране на необходим капацитет на свързаност при внедряване на VoIP:

• Период на пакетизация (packetization period, a.k.a. PP);
• Пакети в секунда (a.k.a. PPS, обратно пропорционална на периода на пакетизация);
• Капацитет на кодека (codec bandwidth, a.k.a. CBW);
• Допълнителни байтове от Data Link/IP/UDP/RTP/tunneling хедъри (overhead, a.k.a. TOH);

Съществуват някои механизми за спестяване на капацитет като например VAD (Voice Activity Detection), известно при някои вендори като Silence Suppression, но тяхната полза е условна и зависи от средната зашуменост на средата при провеждане на VoIP разговори. В идеални условия и отчитане на културните особености на разговор при различни националности се счита, че VAD може да спести до 35% от необходимия капацитет, но е прието тези спестявания да не се отчитат при първоначално планиране на капацитет за пренос на глас по IP. › Continue reading

Tags: bandwidth, network design, planning, VoIP

Джеф Дойл за избора на IGP

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

 

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

Tags: IGPs, Jeff Doyle, Routing

OSPF Adjacency building. ExStart. Exchange.

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

› Continue reading

Tags: adjacency, cisco, exstart, IGP, networking, OSPF, Routing