Dushes Опубликовано 14 декабря, 2010 · Жалоба Здравствуйте, уважаемы CCNA Cisco спецы подскажите пожалуйста, как на IOS определенному трафику (ACL) задать искусственно задержку в 300мс, в частности очень хочется заставить TCP протокол определённых пользователей не так активно пакеты генерировать, в сторону пользователей.... а то ужо не какой QOS не спасает (исходящий то всегда пустует), канал ну очень узкий :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 15 декабря, 2010 · Жалоба Здравствуйте, уважаемы CCNA Cisco спецы подскажите пожалуйста, как на IOS определенному трафику (ACL) задать искусственно задержку в 300мс, в частности очень хочется заставить TCP протокол определённых пользователей не так активно пакеты генерировать, в сторону пользователей.... а то ужо не какой QOS не спасает (исходящий то всегда пустует), канал ну очень узкий :(а кто сказал что в протоколе ТСP можно задать задержку - ? , и где вы собираетесь задерживать всё это 300 mc, для таких задач есть полисеры и шейперы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 15 декабря, 2010 · Жалоба Чётко задача для FreeBSD'шного dummynet ;) Чётко задача для FreeBSD'шного dummynet ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dushes Опубликовано 16 декабря, 2010 (изменено) · Жалоба config Есть определенная группа людей, которым нужно искусственно замедлять отправку исходящих пакетов, в теории это должно будет вызывать замедление отправляющей стороны .. (вроде подобным методом работает TCP протокол -> если пакеты приходят медленнее чем обычно от хоста, то и отправлять начинает менее интенсивно) Dyr ipfw pipe 3 config bw 128Kbit/s queue 10 delay 1000ms да да именно оно, есть подобное под Cisco ? Изменено 16 декабря, 2010 пользователем Dushes Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 16 декабря, 2010 · Жалоба Не знаю. По-моему, нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 16 декабря, 2010 · Жалоба думаю надо заюзать вот эту ветку в 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 16 декабря, 2010 · Жалоба Ничего из этого не создаст необходимую и регламентированную задержку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 16 декабря, 2010 · Жалоба (TCP протокол -> если пакеты приходят медленнее чем обычно от хоста, то и отправлять начинает менее интенсивно) а откуда вот такое берётся в TCP - ? не помню про такое. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 16 декабря, 2010 (изменено) · Жалоба Правильно, только к задержке это не будет иметь никакого отношения. Представьте себе водопроводную трубу, по которой течёт вода. Независимо от того, какого диаметра вы её сделаете, запущенная с одной стороны вода достигнет другого конца за одно и то же время. Количество воды разное, да, а задержка - одинаковая. Про TCP Изменено 16 декабря, 2010 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 16 декабря, 2010 · Жалоба да я просто к тому что нет средств таких в протоколе TCP что б сделать задержку , по-моему единственно чем регулируется параметры сессии TCP - это размер окна . только и всего . Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 16 декабря, 2010 · Жалоба Кроме всего думаю достаточно настроить какой нить полисер на определённый тип трафика (TCP для этих хостов) и всё. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 18 декабря, 2010 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 18 декабря, 2010 · Жалоба 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 данный параметр на трафик никак не влияет , используется только дя маршрутизации Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 18 декабря, 2010 · Жалоба Здравствуйте, уважаемы CCNA Cisco спецы подскажите пожалуйста, как на IOS определенному трафику (ACL) задать искусственно задержку в 300мс,Это вопрос, скорее, к CCNP, а не к CCNA. CCNA - это куда какой провод воткнуть по схеме, которую бригадир дал. Помощник сисадмина - Network Associate. Взрослый сисадмин - это CCNP (Network Professional). Правильно, только к задержке это не будет иметь никакого отношения.Представьте себе водопроводную трубу, по которой течёт вода. Независимо от того, какого диаметра вы её сделаете, запущенная с одной стороны вода достигнет другого конца за одно и то же время. Количество воды разное, да, а задержка - одинаковая. Про TCP Бернулли поперхнулся :-)Про трубу Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 18 декабря, 2010 · Жалоба vIv Если обсуждать классификацию специалистов по мнению cisco, то CCNP это админ предприятия(но не сервис-провайдера), поэтому надо было послать к специалисту CCIP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dushes Опубликовано 18 декабря, 2010 · Жалоба 1) если это невозможно, как же это сделано в FreeBSD, и главное для чего ? 2) представим что пользователь это "A" сервер это "B". "A" начинает качать с сервера "B", как "B" понимает сколько пакетов в сек нужно отправлять клиенту "A" ? 3) я полагаю что задержка между узлами и возможность принимать столько то кол-ва байт в секунду, как то между собой связаны на уровне tcp/ip , а именно, к примеру сервер "B" отослал 100 покетов в 1/сек, TCP тут же отреагировал, и послал в обратку пакет подтверждения что принял только 50 пакетов, ввиду чего "B" начинает слать уже в 1/сек чуть меньше пакетов, => я предположил если замедлять эти самые ответы "подтверждения принятой инфы", то TCP/IP будет стараться слать меньшее кол-во пакетов в сек, дабы избегать патери пакетов (по timeout) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 18 декабря, 2010 · Жалоба по этому я и говорю вам что копать надо в сторону Window Size , протокола TCP, так при установлении сессии TCP конечные хосты ведут переговоры о этом размере window size, (это размер который может передать один хост другому хосту без подтверждения в байтах до 65535) - это единственный механизм в ТСP который позволяет правильно использовать полосу. В вашем примере сервер B и хост А будт максимально использовать всю полосу какую имеют, в том случае если сервер отправил хосту 100 (без подтверждения) пакетов а хост принял меньше то в этом случае размер окна будет уменьшен . всё это напрямую зависит от пропускной способности канала, сколько им дадите столько они и займут. поэтому вам и говорю что полосу зарежите по TCP для этой группы хостов и всё . :-) этот механизм называется (Congestion Window) и предотвращает перегрузку канала. Есть ещё механизм (receive window) предотвращающий перегрузку получателя (flow-control). и кто нить мне расскажет кто такие CCNA и CCIP ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 18 декабря, 2010 (изменено) · Жалоба и кто нить мне расскажет кто такие CCNA и CCIP ?Это инженерные сертификации компании Cisco. http://ru.wikipedia.org/wiki/Сертификации_Cisco"Внесение задержек" (шейпинг) возможно только для отправляемого трафика, который уже принят и записан в память маршрутизатора. У топикстартера проблема с переполнением приемного буфера маршрутизатора. Избавляться от таких перегрузок нужно с помощью алгоритмов семейства RED. Кроме этого, следует увеличить размеры приемных буферов на сетевухах, расширять внешний канал и урезать полосу наиболее заядлым качальщикам. Изменено 18 декабря, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 19 декабря, 2010 · Жалоба думаю RED как таковой ему не поможет (в разгрузке канала), он поможет только как довесок к резанию полосы этим товарищам. ну и конечно разгрузит железяку его . из поста не удалось уследить что железяка у него не справляется :-) , просто канал забит. а полосу конечно надо расширять! раз такое дело. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 19 декабря, 2010 · Жалоба Насколько я знаю у него расширение невозможно, апстрим отказывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dushes Опубликовано 20 декабря, 2010 · Жалоба config http://cisco-conf.ru/qos/87-congestion-avoidance-.html вот хорошая статья на эту тему кому интересно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 20 декабря, 2010 · Жалоба Да статья хорошая, тока вот всё равно забит будет твой канал , если не зарезать скорость , так как RED работают с очередями , то есть очередь должна быть ! а канал забьётся быстрее чем будет отрезана задняя часть очереди RED-ом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 20 декабря, 2010 · Жалоба 1) если это невозможно, как же это сделано в FreeBSD, и главное для чего ?Это ж фряха, кто что хочет тот то и делает :) 2) представим что пользователь это "A" сервер это "B". "A" начинает качать с сервера "B", как "B" понимает сколько пакетов в сек нужно отправлять клиенту "A" ?флов контроль для этого есть: принимающая сторона изнемогая от полученных пакетов просит отправителя заткнутся не надолго. Он так и делает, если флов контроль не отключил.Если отключил - пакеты дропаются, и приходится их перепосылать. 3) я полагаю что задержка между узлами и возможность принимать столько то кол-ва байт в секунду, как то между собой связаны на уровне tcp/ip, а именно, к примеру сервер "B" отослал 100 покетов в 1/сек, TCP тут же отреагировал, и послал в обратку пакет подтверждения что принял только 50 пакетов, ввиду чего "B" начинает слать уже в 1/сек чуть меньше пакетов, => я предположил если замедлять эти самые ответы "подтверждения принятой инфы", то TCP/IP будет стараться слать меньшее кол-во пакетов в сек, дабы избегать патери пакетов (по timeout) Ставьте фряху и пишите :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dushes Опубликовано 20 декабря, 2010 (изменено) · Жалоба 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 Изменено 20 декабря, 2010 пользователем Dushes Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dushes Опубликовано 20 декабря, 2010 · Жалоба config для того что бы такого не происходило bandwidth на канал используется (по совету disappointed ) на 10% меньше чем это позволяет uplink Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...