QoS http://cisco-conf.ru/qos.feed 2013-12-21T05:19:18Z Joomla! 1.5 - Open Source Content Management QoS на Catalyst 3750 подробно 2010-04-15T05:28:30Z 2010-04-15T05:28:30Z http://cisco-conf.ru/qos/90-qos-catalyst-3750-.html barabu errorlog@mail.ru <p><strong>3750 QOS: Общие принципы:</strong><br /><br /> Свич в целом имеет две входящие очереди и каждый порт имеет четыре исходящих. Обращаю внимание, что у  портов нет своих отдельных входящих очередей, две входящие очереди – это на весь свич. Когда пакет входит в порт, то выполняются следующие шаги:<br /><br /> <strong>Classification</strong> – для каждого пакета свичу нужно сгенерить <strong>QoS</strong> Label, который будет сопровождать пакет внутри свича и определять всю его последующую QoS-обработку. Для этого свич «мапирует» CoS или <strong>DSCP</strong> входящего пакета на <strong>QoS</strong> Label.<br /><strong>Policing</strong> – определяет попадает ли пакет в профайл или он out profile. Результат отражается в QoS Label и передается Маркеру.<br /><strong>Marking</strong> – оценивает результат полисера и проверяет настройки: что сделать с пакетом, если он out profile. Возможные действия: пропустить без изменений; пропустить, но сделать mark down the QoS label; дропнуть.<br /><strong>Queueing</strong> – поместить пакет в одну из двух ingress очередей свича. Для этого просматривается QoS Label. Сначала по <strong>DSCP\CoS</strong> пакета выбирается нужная очередь, затем механизм WTD проверяет не превышен ли в этой очереди трешолд для данного DSCP\CoS. Если трешолд превышен, то пакет дропится иначе ставится в очередь.<br /><strong>Scheduling</strong> – механизм SRR (исключительно Shared Round Robin)<br /><br /> На выходе выполняются следующие шаги:<br /><br /></p> <p><strong>3750 QOS: Общие принципы:</strong><br /><br /> Свич в целом имеет две входящие очереди и каждый порт имеет четыре исходящих. Обращаю внимание, что у  портов нет своих отдельных входящих очередей, две входящие очереди – это на весь свич. Когда пакет входит в порт, то выполняются следующие шаги:<br /><br /> <strong>Classification</strong> – для каждого пакета свичу нужно сгенерить <strong>QoS</strong> Label, который будет сопровождать пакет внутри свича и определять всю его последующую QoS-обработку. Для этого свич «мапирует» CoS или <strong>DSCP</strong> входящего пакета на <strong>QoS</strong> Label.<br /><strong>Policing</strong> – определяет попадает ли пакет в профайл или он out profile. Результат отражается в QoS Label и передается Маркеру.<br /><strong>Marking</strong> – оценивает результат полисера и проверяет настройки: что сделать с пакетом, если он out profile. Возможные действия: пропустить без изменений; пропустить, но сделать mark down the QoS label; дропнуть.<br /><strong>Queueing</strong> – поместить пакет в одну из двух ingress очередей свича. Для этого просматривается QoS Label. Сначала по <strong>DSCP\CoS</strong> пакета выбирается нужная очередь, затем механизм WTD проверяет не превышен ли в этой очереди трешолд для данного DSCP\CoS. Если трешолд превышен, то пакет дропится иначе ставится в очередь.<br /><strong>Scheduling</strong> – механизм SRR (исключительно Shared Round Robin)<br /><br /> На выходе выполняются следующие шаги:<br /><br /></p> Payload and Header Compression 2010-04-14T13:43:32Z 2010-04-14T13:43:32Z http://cisco-conf.ru/qos/88-payload-and-header-compression.html barabu errorlog@mail.ru <p>Compression Ratio = (original num of bytes / compressed num of bytes)<br /><br />В Cisco IOS существует два вида сжатия - <strong>payload compression</strong> and <strong>header compression</strong>.<br /><br /><strong>Payload Compression</strong> – сжимает все за исключением L2 header.<br /><strong>Header Compression</strong> – сжимает все заголовки за исключением L2 header.</p> <p><br /><strong>Header Compression</strong><br />В Циске есть два вида сжатия заголовков:<br /><strong><br />TCP header compression</strong> – сжимает IP и TCP заголовки (40 байтов до 3 - 5)<br /><strong>RTP header compression</strong> – сжимает IP, UDP и RTP заголовки (40 байтов до 2 -4)<br /><br />Механизмы сжатия заголовков эффективны только для маленьких пакетов. IOS позволяет выполнять <strong>header compression</strong> через MQC: создаем <strong>класс</strong>, помещаем его в <strong>policy</strong>, и включаем для класса <strong>compression</strong>:</p> <p>Compression Ratio = (original num of bytes / compressed num of bytes)<br /><br />В Cisco IOS существует два вида сжатия - <strong>payload compression</strong> and <strong>header compression</strong>.<br /><br /><strong>Payload Compression</strong> – сжимает все за исключением L2 header.<br /><strong>Header Compression</strong> – сжимает все заголовки за исключением L2 header.</p> <p><br /><strong>Header Compression</strong><br />В Циске есть два вида сжатия заголовков:<br /><strong><br />TCP header compression</strong> – сжимает IP и TCP заголовки (40 байтов до 3 - 5)<br /><strong>RTP header compression</strong> – сжимает IP, UDP и RTP заголовки (40 байтов до 2 -4)<br /><br />Механизмы сжатия заголовков эффективны только для маленьких пакетов. IOS позволяет выполнять <strong>header compression</strong> через MQC: создаем <strong>класс</strong>, помещаем его в <strong>policy</strong>, и включаем для класса <strong>compression</strong>:</p> Congestion avoidance механизмы 2010-04-14T13:07:33Z 2010-04-14T13:07:33Z http://cisco-conf.ru/qos/87-congestion-avoidance-.html barabu errorlog@mail.ru <!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } A:link { so-language: zxx } --> <p style="margin-bottom: 0in;" align="justify"><span style="font-size: small;"><span style="font-family: arial,helvetica,sans-serif;"><span lang="en-US">Queuing tools help us manage the queues, Congestion Avoidance Tools help us reduce the level of congestion in the queues by </span><span lang="en-US"><em><strong>selectively dropping packets</strong></em></span><span lang="en-US">. Cisco Congestion Avoidance Tools relies on </span><span lang="en-US"><em><strong>the behavior of TCP</strong></em></span><span lang="en-US">.</span></span></span></p> <p style="margin-bottom: 0in;" align="justify"><span style="font-size: small;"><span style="font-family: arial,helvetica,sans-serif;">Для начала рассмотрим поведение ТСР в условиях возникновения переполнения в сети.</span></span></p> <p style="margin-bottom: 0in;" align="center"><span style="font-size: small;"><span style="font-family: arial,helvetica,sans-serif;"><span lang="en-US"><em><strong>TCP</strong></em></span><em><strong> </strong></em><span lang="en-US"><em><strong>Reaction</strong></em></span><em><strong> </strong></em><span lang="en-US"><em><strong>to</strong></em></span><em><strong> </strong></em><span lang="en-US"><em><strong>packet</strong></em></span><em><strong> </strong></em><span lang="en-US"><em><strong>loss</strong></em></span></span></span></p> <p style="margin-bottom: 0in;" align="justify"><span style="font-size: small;"><span style="font-family: arial,helvetica,sans-serif;">Когда два пира устанавливают tcp-конект, то они обговаривают размер сегмента. Выбирается <em><strong>наименьший</strong></em> из предложенных. Кроме этого каждый пир сообщает другому размер окна, т.е. к, размер окна. з предложенных. Кроме этого каждый пир сообщаетгмента. оличество байтов, которое он может <em><strong>принять</strong></em> без отправки ACK. Поясню: пир 1 сообщает пиру 2, что размер его, пира 1, окна равен 65536 байт. Это значит, что пир 2 может отправить данное количество байт, не ожидая ACK от пира 1. Такое окно называется <em>advertised window </em>(<span lang="en-US">AWND</span>) </span></span></p> <!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } A:link { so-language: zxx } --> <p style="margin-bottom: 0in;" align="justify"><span style="font-size: small;"><span style="font-family: arial,helvetica,sans-serif;"><span lang="en-US">Queuing tools help us manage the queues, Congestion Avoidance Tools help us reduce the level of congestion in the queues by </span><span lang="en-US"><em><strong>selectively dropping packets</strong></em></span><span lang="en-US">. Cisco Congestion Avoidance Tools relies on </span><span lang="en-US"><em><strong>the behavior of TCP</strong></em></span><span lang="en-US">.</span></span></span></p> <p style="margin-bottom: 0in;" align="justify"><span style="font-size: small;"><span style="font-family: arial,helvetica,sans-serif;">Для начала рассмотрим поведение ТСР в условиях возникновения переполнения в сети.</span></span></p> <p style="margin-bottom: 0in;" align="center"><span style="font-size: small;"><span style="font-family: arial,helvetica,sans-serif;"><span lang="en-US"><em><strong>TCP</strong></em></span><em><strong> </strong></em><span lang="en-US"><em><strong>Reaction</strong></em></span><em><strong> </strong></em><span lang="en-US"><em><strong>to</strong></em></span><em><strong> </strong></em><span lang="en-US"><em><strong>packet</strong></em></span><em><strong> </strong></em><span lang="en-US"><em><strong>loss</strong></em></span></span></span></p> <p style="margin-bottom: 0in;" align="justify"><span style="font-size: small;"><span style="font-family: arial,helvetica,sans-serif;">Когда два пира устанавливают tcp-конект, то они обговаривают размер сегмента. Выбирается <em><strong>наименьший</strong></em> из предложенных. Кроме этого каждый пир сообщает другому размер окна, т.е. к, размер окна. з предложенных. Кроме этого каждый пир сообщаетгмента. оличество байтов, которое он может <em><strong>принять</strong></em> без отправки ACK. Поясню: пир 1 сообщает пиру 2, что размер его, пира 1, окна равен 65536 байт. Это значит, что пир 2 может отправить данное количество байт, не ожидая ACK от пира 1. Такое окно называется <em>advertised window </em>(<span lang="en-US">AWND</span>) </span></span></p> Shaping и Policing 2010-04-14T12:09:36Z 2010-04-14T12:09:36Z http://cisco-conf.ru/qos/86-shaping-policing.html barabu errorlog@mail.ru <p><strong>Policier</strong> – обычно устанавливается на входе в облако ISP, чтобы дропить лишний траф клиента. Кроме дропа <strong>policier</strong> может <strong>mark</strong> <strong>down</strong> лишний траф, т.е. давать ему худшую <strong>precedence</strong>, чтобы затем в случае перегрузки в сети самого провайдера этот траф был задроплен, например механизмом <strong>WRED</strong>.<br /><br /><strong>Shaper</strong> – как правило применяется в 2-х случаях.<br />На выходе от клиента, если провайдер использует <strong>Policier</strong>. Тогда траф клиента не пропадет, просто будет больше задержка.<br />Для избежания эффекта <strong>Egress</strong> <strong>Blocking</strong> (это когда споки одновременно отправляют трафа больше, чем hub может принять, или если hub будет слать отдельному споку больше чем тот может принять)</p> <p><strong>Policier</strong> – обычно устанавливается на входе в облако ISP, чтобы дропить лишний траф клиента. Кроме дропа <strong>policier</strong> может <strong>mark</strong> <strong>down</strong> лишний траф, т.е. давать ему худшую <strong>precedence</strong>, чтобы затем в случае перегрузки в сети самого провайдера этот траф был задроплен, например механизмом <strong>WRED</strong>.<br /><br /><strong>Shaper</strong> – как правило применяется в 2-х случаях.<br />На выходе от клиента, если провайдер использует <strong>Policier</strong>. Тогда траф клиента не пропадет, просто будет больше задержка.<br />Для избежания эффекта <strong>Egress</strong> <strong>Blocking</strong> (это когда споки одновременно отправляют трафа больше, чем hub может принять, или если hub будет слать отдельному споку больше чем тот может принять)</p> Congestion Management очереди LLQ CBWFQ 2010-04-14T11:35:28Z 2010-04-14T11:35:28Z http://cisco-conf.ru/qos/85-congestion-management-llq-cbwfq.html barabu errorlog@mail.ru <p>У каждого физического интерфейса существуют программная и аппаратная очереди: <strong>Software Queue</strong> и <strong>Hardware</strong> <strong>Queue</strong> (или <strong>TxRing</strong>). <strong>Hardware</strong> <strong>Queue</strong> всегда <strong>FIFO</strong> и хранит указатели на пакеты, ожидающие отправки в линию. Шедулер <strong>Software</strong> <strong>Queue</strong> помещает в <strong>Hardware</strong> <strong>Queue</strong> указатель на очередной пакет. Микруха порта (<strong>ASIC</strong>) самостоятельно проверяет область памяти <strong>TxRing</strong> и если там не NULL-указатель, то сама, без помощи CPU, отправляет пакет в линию. Т.е. <strong>ASIC</strong> позволяет порту сразу же заняться отправкой пакета, ожидающего в <strong>Hardware</strong> <strong>Queue</strong>.<br /><br />Допустим у нас в качестве <strong>Software</strong> <strong>Queue</strong> используется <strong>CBWFQ</strong> with <strong>LLQ</strong>. Все её буферы свободны и одновременно на интерфейс маршрутизируются 6 пакетов: 4 с data и 2 с голосом. На первый взгляд может показаться, что сначала они рассортируются по своим буферам в CBWFQ, а потом <strong>Software</strong> <strong>Queue</strong>-шедулер отправит два пакета голоса на <strong>Hardware</strong> <strong>Queue</strong>. Однако это не так. После того как пакет смаршрутизирован роутер в первую очередь проверяет наличие свободного места в <strong>TxRing</strong>. Если оно есть, то пакет сразу отправляется туда, минуя <strong>Software</strong> <strong>Queue</strong>. Поэтому, если у нас <strong>TxRing</strong> размером в два указателя, и 2 data пакета маршрутизятся раньше, чем 2 голосовых пакета, то data пакеты сразу «полетят» в <strong>TxRing</strong>, а голосовые попадут в <strong>LLQ</strong>. Так происходит всегда – каков бы ни был пакет, если в <strong>TxRing</strong> есть место, то он сразу летит туда. Запомни, <strong>Software</strong> <strong>Queue</strong> начинает заполняться, только если в <strong>Hardware</strong> <strong>Queue</strong> нет места.</p> <p>У каждого физического интерфейса существуют программная и аппаратная очереди: <strong>Software Queue</strong> и <strong>Hardware</strong> <strong>Queue</strong> (или <strong>TxRing</strong>). <strong>Hardware</strong> <strong>Queue</strong> всегда <strong>FIFO</strong> и хранит указатели на пакеты, ожидающие отправки в линию. Шедулер <strong>Software</strong> <strong>Queue</strong> помещает в <strong>Hardware</strong> <strong>Queue</strong> указатель на очередной пакет. Микруха порта (<strong>ASIC</strong>) самостоятельно проверяет область памяти <strong>TxRing</strong> и если там не NULL-указатель, то сама, без помощи CPU, отправляет пакет в линию. Т.е. <strong>ASIC</strong> позволяет порту сразу же заняться отправкой пакета, ожидающего в <strong>Hardware</strong> <strong>Queue</strong>.<br /><br />Допустим у нас в качестве <strong>Software</strong> <strong>Queue</strong> используется <strong>CBWFQ</strong> with <strong>LLQ</strong>. Все её буферы свободны и одновременно на интерфейс маршрутизируются 6 пакетов: 4 с data и 2 с голосом. На первый взгляд может показаться, что сначала они рассортируются по своим буферам в CBWFQ, а потом <strong>Software</strong> <strong>Queue</strong>-шедулер отправит два пакета голоса на <strong>Hardware</strong> <strong>Queue</strong>. Однако это не так. После того как пакет смаршрутизирован роутер в первую очередь проверяет наличие свободного места в <strong>TxRing</strong>. Если оно есть, то пакет сразу отправляется туда, минуя <strong>Software</strong> <strong>Queue</strong>. Поэтому, если у нас <strong>TxRing</strong> размером в два указателя, и 2 data пакета маршрутизятся раньше, чем 2 голосовых пакета, то data пакеты сразу «полетят» в <strong>TxRing</strong>, а голосовые попадут в <strong>LLQ</strong>. Так происходит всегда – каков бы ни был пакет, если в <strong>TxRing</strong> есть место, то он сразу летит туда. Запомни, <strong>Software</strong> <strong>Queue</strong> начинает заполняться, только если в <strong>Hardware</strong> <strong>Queue</strong> нет места.</p> Classification and marking with VPN 2010-04-14T11:18:12Z 2010-04-14T11:18:12Z http://cisco-conf.ru/qos/84-classification-and-marking-with-vpn.html barabu errorlog@mail.ru <p>Когда циска выполняет <strong>VPN</strong> функции (<strong>IPSec</strong>, <strong>GRE</strong>, …), то она <strong><em>АВТОМАТИЧЕСКИ</em></strong> копирует <strong>ToS</strong> байт из оригинального IP-пакета во вновь создаваемый IP-заголовок. Если правильно выполнить классификацию оригинального пакета ещё до его входа в Tunnel, то ISP сможет увидеть <strong>ToS</strong> байт для того, чтобы выполнить <strong>QoS</strong>. <br /><br /> Итак, на входе в циску классифицируем и маркируем пакет, на выходе он туннелируется, а исходный <strong>ToS</strong> байт автоматически копируется в новый, внешний заголовок. Т.е. на выходе мы получаем новый IP-заголовок со старым <strong>ToS</strong> байтом, а вся информация об оригинальных IP <em>Src</em>, <em>Dst</em>, <em>TCP</em>\<em>UDP</em>-портах теряется (внутренний пакет может быть зашифрован). На выходе из роутера <strong>QoS</strong> механизмы видят только внешний заголовок, а вдруг мы хотим применить исходящий <strong>QoS</strong>-механизм очередей, работающий c параметрами оригинального пактета (<em>IP-адреса</em>, типы приложений, просто копирования поля <strong>ToS</strong> недостаточно). В этом случае нам нужна команда <strong>qos pre-classify</strong>. Если у нас <strong>tunnel</strong>-интерфейс, то команда выполняется в его контексте, если IPSec, то в крипто-мапе.<br /><br /> <p>Когда циска выполняет <strong>VPN</strong> функции (<strong>IPSec</strong>, <strong>GRE</strong>, …), то она <strong><em>АВТОМАТИЧЕСКИ</em></strong> копирует <strong>ToS</strong> байт из оригинального IP-пакета во вновь создаваемый IP-заголовок. Если правильно выполнить классификацию оригинального пакета ещё до его входа в Tunnel, то ISP сможет увидеть <strong>ToS</strong> байт для того, чтобы выполнить <strong>QoS</strong>. <br /><br /> Итак, на входе в циску классифицируем и маркируем пакет, на выходе он туннелируется, а исходный <strong>ToS</strong> байт автоматически копируется в новый, внешний заголовок. Т.е. на выходе мы получаем новый IP-заголовок со старым <strong>ToS</strong> байтом, а вся информация об оригинальных IP <em>Src</em>, <em>Dst</em>, <em>TCP</em>\<em>UDP</em>-портах теряется (внутренний пакет может быть зашифрован). На выходе из роутера <strong>QoS</strong> механизмы видят только внешний заголовок, а вдруг мы хотим применить исходящий <strong>QoS</strong>-механизм очередей, работающий c параметрами оригинального пактета (<em>IP-адреса</em>, типы приложений, просто копирования поля <strong>ToS</strong> недостаточно). В этом случае нам нужна команда <strong>qos pre-classify</strong>. Если у нас <strong>tunnel</strong>-интерфейс, то команда выполняется в его контексте, если IPSec, то в крипто-мапе.<br /><br /> Пример MQC (Modular QoS) создание policy map 2010-04-14T10:31:20Z 2010-04-14T10:31:20Z http://cisco-conf.ru/qos/83--mqc-modular-qos-policy-map.html barabu errorlog@mail.ru <p><strong>MQC</strong> - это принцип создания политики косов через командную строку.</p> <p>Создание политики происходит в 3 этапа</p> <ol> <li>Классификация трафика с помощью класса (<strong>class-map</strong>).</li> <li>Создания политики для классифицированного трафика (<strong>policy-map</strong>). Определяет действие над трафиком.</li> <li>Применение политики на интерфейсе (<strong>service-policy</strong>). </li> </ol> <p>Задаем критерии классификации:</p> <p><strong>match ip rtp</strong> <em>&lt;low_number&gt;</em> <em>&lt;range&gt;</em> – захватывает только четные UDP-порты из заданного диапазона.<br /><br />Помещаем весь <strong>telnet</strong> траф в класс <strong>defaut</strong>:<br /><br /><strong>ip</strong> <strong>access-list</strong> <strong>extended</strong> <em>acl-telnet</em><br /> <strong>permit tcp any any eq 23</strong><br /> <strong>permit tcp any eq 23 any</strong></p> <p> </p> <p><strong>MQC</strong> - это принцип создания политики косов через командную строку.</p> <p>Создание политики происходит в 3 этапа</p> <ol> <li>Классификация трафика с помощью класса (<strong>class-map</strong>).</li> <li>Создания политики для классифицированного трафика (<strong>policy-map</strong>). Определяет действие над трафиком.</li> <li>Применение политики на интерфейсе (<strong>service-policy</strong>). </li> </ol> <p>Задаем критерии классификации:</p> <p><strong>match ip rtp</strong> <em>&lt;low_number&gt;</em> <em>&lt;range&gt;</em> – захватывает только четные UDP-порты из заданного диапазона.<br /><br />Помещаем весь <strong>telnet</strong> траф в класс <strong>defaut</strong>:<br /><br /><strong>ip</strong> <strong>access-list</strong> <strong>extended</strong> <em>acl-telnet</em><br /> <strong>permit tcp any any eq 23</strong><br /> <strong>permit tcp any eq 23 any</strong></p> <p> </p> QoS инструменты 2010-04-14T09:48:27Z 2010-04-14T09:48:27Z http://cisco-conf.ru/qos/82-qos-.html barabu errorlog@mail.ru <p>Каждый <strong>QoS</strong> инструмент так или иначе использует <em>классификацию</em>. Каждому инстр-ту нужно как-то "сортировать" трафик, чтобы каждый тип трафа получил требуемое обслуживание. Поэтому всегда думай так:<br /><br /><strong>Queuing</strong> - это <em>Classification</em> and <em>Queuing</em><br /><strong>Shaping</strong> - это <em>Classification</em> and <em>Shaping</em><br /><strong>Policing</strong> - это <em>Classification</em> and <em>Policing</em><br /><strong>Marking</strong> - это <em>Classification</em> and <em>Marking </em><br /><strong>Compression</strong> - это <em>Classification</em> and <em>Compression</em> (<strong>TCP</strong> or <strong>RTP</strong> <strong>header</strong> <strong>compression</strong> для пакета в классе трафика)<br /><br /><br /><strong>Shaping</strong> and <strong>Policing</strong><br />--------------------<br /><strong>Policing</strong> как правило используется на входе - провайдер режет траф кастомера. <strong>Shaping</strong> используется на выходе, чтобы избежать дропов пакетов провайдером.</p> <p> <p>Каждый <strong>QoS</strong> инструмент так или иначе использует <em>классификацию</em>. Каждому инстр-ту нужно как-то "сортировать" трафик, чтобы каждый тип трафа получил требуемое обслуживание. Поэтому всегда думай так:<br /><br /><strong>Queuing</strong> - это <em>Classification</em> and <em>Queuing</em><br /><strong>Shaping</strong> - это <em>Classification</em> and <em>Shaping</em><br /><strong>Policing</strong> - это <em>Classification</em> and <em>Policing</em><br /><strong>Marking</strong> - это <em>Classification</em> and <em>Marking </em><br /><strong>Compression</strong> - это <em>Classification</em> and <em>Compression</em> (<strong>TCP</strong> or <strong>RTP</strong> <strong>header</strong> <strong>compression</strong> для пакета в классе трафика)<br /><br /><br /><strong>Shaping</strong> and <strong>Policing</strong><br />--------------------<br /><strong>Policing</strong> как правило используется на входе - провайдер режет траф кастомера. <strong>Shaping</strong> используется на выходе, чтобы избежать дропов пакетов провайдером.</p> <p> Знакомство с QoS, подсчет размера голосового пакета 2010-04-14T08:58:32Z 2010-04-14T08:58:32Z http://cisco-conf.ru/qos/81--qos-.html barabu errorlog@mail.ru <p><strong>QoS</strong> - <strong>Quality of Service</strong> (<em>качество обслуживания</em>). Изначально придумывался для голосового трафика. Термин определяющий <strong><em>набор механизмов</em></strong> для увеличения качественных характеристик сети относящихся к определенному виду трафика!  К этим механизмам относятся: <strong>Queing</strong> (очереди <em>FIFO</em>, <em>WRED</em>, <em>WFQ</em>, <em>CBWFQ</em>, <em>LLQ</em>), <strong>LFI</strong> (перемешивание пакетов), <strong>Shaping</strong> (ограничение скорости и буферизация), Compression (сжатие пакетов), <strong>RED</strong> (механизм предотвращения перегрузки), и т.д.</p> <p>Пакет всегда отправляется на скорости <em>Clock</em> <em>Rate</em>. <em>Bandwith</em> влияет только на работу некоторых инструментов<br />и изменяет поведение некоторой статистики.</p> <p>Рассмотрим основные типы задержек на сети:</p> <ul> <li><strong>Serialization</strong> <em>Delay</em> - время отправки битов пакета через физический порт.</li> <li><strong>Propogation</strong> <em>Delay</em> - время движения одного бита по линку от одной точки до другой. Это функция от длины линки и скорости света.</li> <li><strong>Queuing</strong> <em>Delay</em> - время нахождения фрейма в очереди.</li> <li><strong>Forwarding</strong> <em>Delay</em> - время коммутации внутри коробки</li> <li><strong>Shaping</strong> <em>Delay</em> - время отстоя в shape-очереди</li> </ul> <p><em> <p><strong>QoS</strong> - <strong>Quality of Service</strong> (<em>качество обслуживания</em>). Изначально придумывался для голосового трафика. Термин определяющий <strong><em>набор механизмов</em></strong> для увеличения качественных характеристик сети относящихся к определенному виду трафика!  К этим механизмам относятся: <strong>Queing</strong> (очереди <em>FIFO</em>, <em>WRED</em>, <em>WFQ</em>, <em>CBWFQ</em>, <em>LLQ</em>), <strong>LFI</strong> (перемешивание пакетов), <strong>Shaping</strong> (ограничение скорости и буферизация), Compression (сжатие пакетов), <strong>RED</strong> (механизм предотвращения перегрузки), и т.д.</p> <p>Пакет всегда отправляется на скорости <em>Clock</em> <em>Rate</em>. <em>Bandwith</em> влияет только на работу некоторых инструментов<br />и изменяет поведение некоторой статистики.</p> <p>Рассмотрим основные типы задержек на сети:</p> <ul> <li><strong>Serialization</strong> <em>Delay</em> - время отправки битов пакета через физический порт.</li> <li><strong>Propogation</strong> <em>Delay</em> - время движения одного бита по линку от одной точки до другой. Это функция от длины линки и скорости света.</li> <li><strong>Queuing</strong> <em>Delay</em> - время нахождения фрейма в очереди.</li> <li><strong>Forwarding</strong> <em>Delay</em> - время коммутации внутри коробки</li> <li><strong>Shaping</strong> <em>Delay</em> - время отстоя в shape-очереди</li> </ul> <p><em> Фрагментация и LMI на Frame-Relay 2010-04-12T06:45:04Z 2010-04-12T06:45:04Z http://cisco-conf.ru/qos/77--mlp-frame-relay.html barabu errorlog@mail.ru <p><strong>Fragmentation and Interleaving with MLP over Frame-Relay</strong> - на<strong> FR </strong>сети можно достичь фрагментации с перемешиванием двумя способами: Средствами FRTS + FRF.12 Средствами MLP LFI over Frame-Relay Несколько слов об обычном MLP LFI.</p> <p>Несколько слов об обычном <strong>MLP LFI</strong>.</p> <ul> <li>Если MLP объединяет несколько ррр-линков, то фрагментация включается автоматически, причем каждый пакет делится на равные части по числу линков.</li> <li>Если MLP состоит из одной линки, то по умолчанию фрагментация не выполняется до тех пор пока явно не введена команда “<strong>ppp multilink</strong> <strong>fragment</strong> <strong>delay</strong> <strong>X</strong>”. При наличии нескольких линков эта команда просто меняет размер фрагмента (фрагментация уже <p><strong>Fragmentation and Interleaving with MLP over Frame-Relay</strong> - на<strong> FR </strong>сети можно достичь фрагментации с перемешиванием двумя способами: Средствами FRTS + FRF.12 Средствами MLP LFI over Frame-Relay Несколько слов об обычном MLP LFI.</p> <p>Несколько слов об обычном <strong>MLP LFI</strong>.</p> <ul> <li>Если MLP объединяет несколько ррр-линков, то фрагментация включается автоматически, причем каждый пакет делится на равные части по числу линков.</li> <li>Если MLP состоит из одной линки, то по умолчанию фрагментация не выполняется до тех пор пока явно не введена команда “<strong>ppp multilink</strong> <strong>fragment</strong> <strong>delay</strong> <strong>X</strong>”. При наличии нескольких линков эта команда просто меняет размер фрагмента (фрагментация уже