Искусственная задержка

[Dushes]

Здравствуйте, уважаемы CCNA Cisco спецы подскажите пожалуйста, как на IOS определенному трафику (ACL) задать искусственно задержку в 300мс, в частности очень хочется заставить TCP протокол определённых пользователей не так активно пакеты генерировать, в сторону пользователей.... а то ужо не какой QOS не спасает (исходящий то всегда пустует), канал ну очень узкий :(

[config]

Здравствуйте, уважаемы CCNA Cisco спецы подскажите пожалуйста, как на IOS определенному трафику (ACL) задать искусственно задержку в 300мс, в частности очень хочется заставить TCP протокол определённых пользователей не так активно пакеты генерировать, в сторону пользователей.... а то ужо не какой QOS не спасает (исходящий то всегда пустует), канал ну очень узкий :(

а кто сказал что в протоколе ТСP можно задать задержку - ? , и где вы собираетесь задерживать всё это 300 mc,

для таких задач есть полисеры и шейперы.

[Dyr]

Чётко задача для FreeBSD'шного dummynet ;)

 

Чётко задача для FreeBSD'шного dummynet ;)

[Dushes]

config

 

Есть определенная группа людей, которым нужно искусственно замедлять отправку исходящих пакетов, в теории это должно будет вызывать замедление отправляющей стороны .. (вроде подобным методом работает TCP протокол -> если пакеты приходят медленнее чем обычно от хоста, то и отправлять начинает менее интенсивно)

 

Dyr

ipfw pipe 3 config bw 128Kbit/s queue 10 delay 1000ms да да именно оно, есть подобное под Cisco ?

Edited December 16, 2010 by Dushes

[Dyr]

Не знаю. По-моему, нет.

[config]

думаю надо заюзать вот эту ветку в Cisco IOS

и почитать об этих командах на Cisco Com

это все команды с работой TCP. там же есть размер TCP окна и многое другое.

(conf t)ip tcp ?

async-mobility Configure async-mobility

chunk-size TCP chunk size

ecn Enable Explicit Congestion Notification

mss TCP initial maximum segment size

path-mtu-discovery Enable path-MTU discovery on new TCP connections

queuemax Maximum queue of outgoing TCP packets

selective-ack Enable TCP selective-ACK

synwait-time Set time to wait on new TCP connections

timestamp Enable TCP timestamp option

window-size TCP window size

 

[Dyr]

Ничего из этого не создаст необходимую и регламентированную задержку.

[config]

(TCP протокол -> если пакеты приходят медленнее чем обычно от хоста, то и отправлять начинает менее интенсивно)

а откуда вот такое берётся в TCP - ? не помню про такое.

[Dyr]

Правильно, только к задержке это не будет иметь никакого отношения.

Представьте себе водопроводную трубу, по которой течёт вода. Независимо от того, какого диаметра вы её сделаете, запущенная с одной стороны вода достигнет другого конца за одно и то же время. Количество воды разное, да, а задержка - одинаковая.

Про TCP

Edited December 16, 2010 by Dyr

[config]

да я просто к тому что нет средств таких в протоколе TCP что б сделать задержку , по-моему единственно чем регулируется параметры сессии TCP - это размер окна . только и всего .

[config]

Кроме всего думаю достаточно настроить какой нить полисер на определённый тип трафика (TCP для этих хостов) и всё.

[Дегтярев Илья]

6ka-10(config-if)#delay ?

<1-16777215> Throughput delay (tens of microseconds)

 

6ka-10(config-if)#do show ver

Cisco IOS Software, C3550 Software (C3550-IPSERVICES-M), Version 12.2(44)SE6, RELEASE SOFTWARE (fc1)

Copyright © 1986-2009 by Cisco Systems, Inc.

Compiled Mon 09-Mar-09 14:35 by gereddy

Image text-base: 0x00003000, data-base: 0x00FE0360

 

[orlik]

6ka-10(config-if)#delay ?

<1-16777215> Throughput delay (tens of microseconds)

 

6ka-10(config-if)#do show ver

Cisco IOS Software, C3550 Software (C3550-IPSERVICES-M), Version 12.2(44)SE6, RELEASE SOFTWARE (fc1)

Copyright © 1986-2009 by Cisco Systems, Inc.

Compiled Mon 09-Mar-09 14:35 by gereddy

Image text-base: 0x00003000, data-base: 0x00FE0360

данный параметр на трафик никак не влияет , используется только дя маршрутизации

[vIv]

Здравствуйте, уважаемы CCNA Cisco спецы подскажите пожалуйста, как на IOS определенному трафику (ACL) задать искусственно задержку в 300мс,

Это вопрос, скорее, к CCNP, а не к CCNA. CCNA - это куда какой провод воткнуть по схеме, которую бригадир дал. Помощник сисадмина - Network Associate. Взрослый сисадмин - это CCNP (Network Professional).

 

 

Правильно, только к задержке это не будет иметь никакого отношения.

Представьте себе водопроводную трубу, по которой течёт вода. Независимо от того, какого диаметра вы её сделаете, запущенная с одной стороны вода достигнет другого конца за одно и то же время. Количество воды разное, да, а задержка - одинаковая.

Про TCP

Бернулли поперхнулся :-)

Про трубу

 

[s.lobanov]

vIv

Если обсуждать классификацию специалистов по мнению cisco, то CCNP это админ предприятия(но не сервис-провайдера), поэтому надо было послать к специалисту CCIP.

[Dushes]

1) если это невозможно, как же это сделано в FreeBSD, и главное для чего ?

2) представим что пользователь это "A" сервер это "B". "A" начинает качать с сервера "B", как "B" понимает сколько пакетов в сек нужно отправлять клиенту "A" ?

3) я полагаю что задержка между узлами и возможность принимать столько то кол-ва байт в секунду, как то между собой связаны на уровне tcp/ip

, а именно, к примеру сервер "B" отослал 100 покетов в 1/сек, TCP тут же отреагировал, и послал в обратку пакет подтверждения что принял только 50 пакетов, ввиду чего "B" начинает слать уже в 1/сек чуть меньше пакетов, => я предположил если замедлять эти самые ответы "подтверждения принятой инфы", то TCP/IP будет стараться слать меньшее кол-во пакетов в сек, дабы избегать патери пакетов (по timeout)

 

 

 

 

 

 

 

[config]

по этому я и говорю вам что копать надо в сторону Window Size , протокола TCP, так при установлении сессии TCP конечные хосты ведут переговоры о этом размере window size, (это размер который может передать один хост другому хосту без подтверждения в байтах до 65535) - это единственный механизм в ТСP который позволяет правильно использовать полосу.

 

В вашем примере сервер B и хост А будт максимально использовать всю полосу какую имеют, в том случае если сервер отправил хосту 100 (без подтверждения) пакетов а хост принял меньше то в этом случае размер окна будет уменьшен .

 

всё это напрямую зависит от пропускной способности канала, сколько им дадите столько они и займут.

поэтому вам и говорю что полосу зарежите по TCP для этой группы хостов и всё . :-)

 

этот механизм называется (Congestion Window) и предотвращает перегрузку канала.

 

Есть ещё механизм (receive window) предотвращающий перегрузку получателя (flow-control).

 

 

 

и кто нить мне расскажет кто такие CCNA и CCIP ?

[photon]

и кто нить мне расскажет кто такие CCNA и CCIP ?

Это инженерные сертификации компании Cisco. http://ru.wikipedia.org/wiki/Сертификации_Cisco

"Внесение задержек" (шейпинг) возможно только для отправляемого трафика, который уже принят и записан в память маршрутизатора. У топикстартера проблема с переполнением приемного буфера маршрутизатора. Избавляться от таких перегрузок нужно с помощью алгоритмов семейства RED. Кроме этого, следует увеличить размеры приемных буферов на сетевухах, расширять внешний канал и урезать полосу наиболее заядлым качальщикам.

Edited December 18, 2010 by photon

[config]

думаю RED как таковой ему не поможет (в разгрузке канала), он поможет только как довесок к резанию полосы этим товарищам. ну и конечно разгрузит железяку его . из поста не удалось уследить что железяка у него не справляется :-) , просто канал забит. а полосу конечно надо расширять! раз такое дело.

[disappointed]

Насколько я знаю у него расширение невозможно, апстрим отказывает.

[Dushes]

config

http://cisco-conf.ru/qos/87-congestion-avoidance-.html

 

вот хорошая статья на эту тему кому интересно

[config]

Да статья хорошая, тока вот всё равно забит будет твой канал , если не зарезать скорость , так как RED работают с очередями , то есть очередь должна быть ! а канал забьётся быстрее чем будет отрезана задняя часть очереди RED-ом.

[Ivan_83]

1) если это невозможно, как же это сделано в FreeBSD, и главное для чего ?

Это ж фряха, кто что хочет тот то и делает :)

 

 

2) представим что пользователь это "A" сервер это "B". "A" начинает качать с сервера "B", как "B" понимает сколько пакетов в сек нужно отправлять клиенту "A" ?

флов контроль для этого есть: принимающая сторона изнемогая от полученных пакетов просит отправителя заткнутся не надолго. Он так и делает, если флов контроль не отключил.

Если отключил - пакеты дропаются, и приходится их перепосылать.

 

 

3) я полагаю что задержка между узлами и возможность принимать столько то кол-ва байт в секунду, как то между собой связаны на уровне tcp/ip

, а именно, к примеру сервер "B" отослал 100 покетов в 1/сек, TCP тут же отреагировал, и послал в обратку пакет подтверждения что принял только 50 пакетов, ввиду чего "B" начинает слать уже в 1/сек чуть меньше пакетов, => я предположил если замедлять эти самые ответы "подтверждения принятой инфы", то TCP/IP будет стараться слать меньшее кол-во пакетов в сек, дабы избегать патери пакетов (по timeout)

Ставьте фряху и пишите :)

 

[Dushes]

Ivan_83

 

 

по моему flowcontrol мне тут не помощник, как он понимает что канал захлёбывается ??? ведь он по сути захлёбывается на интерфейсе апстрима, там где он ограничивает (policing) , а между нами то 100Mb/s как бы для flowcontrol канала хоть отбавляй.

 

 

на cisco 3745:

 

FastEthernet0/0 is up, line protocol is up
  ................................
  ...............................
  Address determined by non-volatile memory
  MTU is 1500 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Outgoing access list is usi_out_allow
  Inbound  access list is usi_in_allow
  Proxy ARP is disabled
  Local Proxy ARP is disabled
  Security level is default
  Split horizon is enabled
  ICMP redirects are never sent
  ICMP unreachables are never sent
  ICMP mask replies are never sent
  IP fast switching is enabled
  IP fast switching on the same interface is disabled
  IP Flow switching is enabled
  IP CEF switching is enabled
  IP CEF Flow Fast switching turbo vector
  IP multicast fast switching is enabled
  IP multicast distributed fast switching is disabled
  IP route-cache flags are Fast, Flow cache, CEF, Subint Flow
  Router Discovery is disabled
  IP output packet accounting is disabled
  IP access violation accounting is disabled
  TCP/IP header compression is disabled
  RTP/IP header compression is disabled
  Policy routing is disabled
  Network address translation is disabled
  BGP Policy Mapping is disabled
  WCCP Redirect outbound is disabled
  WCCP Redirect inbound is disabled
  WCCP Redirect exclude is disabled

 

 

 

Edited December 20, 2010 by Dushes

[Dushes]

config

 

для того что бы такого не происходило bandwidth на канал используется (по совету disappointed ) на 10% меньше чем это позволяет uplink