Ранее...

Михаил Евграфович говорил, что в жажде подвига трепещет живое человеческое сердце, скрывается пытливый и никогда не успокаивающийся человеческий разум. Памятуя это, мы попробуем создать гибрид рисунков 14 и 15.

Рисунок 16. Гибридная схема. Агент-инициатор включен безопасно T-образно, сопряжённый ему использует пользовательское оборудование.

Зачем мы это сделали? А для того, чтобы придать рабочему варианту гибкость, которой несколько лишены его предшественники. Мы не будем класть все яйца в одну корзину, давая службе эксплуатации сети возможность выбора. И не забудем разобрать по пунктам уже знаменитый список сомнений.

1. Дополнительные точки отказа в данной схеме контролируются теми, кто создаёт включение. Плюсы схем 2.2 и 2.3 можно суммировать.

2. Связанная производительность так же полностью контролируется. При необходимости в нужных точках можно использовать нужное число дополнительных агентов. Опять плюсы.

3. Привязки к производителю так же контролируются. Где-то рационально использовать патентованные решения, а где-то стандартные. Если на сети уже есть какая-то технология, то можно и использовать её. Опять плюсы.

4. Про расстановку и говорить стыдно. Очевидно, что можно устанавливать и включать агенты только там, где реально необходимо, и при этом решение будет вписываться в доступный бюджет. Вновь плюсы.

Напоследок заметим, что в качестве агента-инициатора можно использовать как встроенный в ПО, так и выделенный. То, что на рисунке 16 инициатор именно выделен, является рекомендованным, но отнюдь не обязательным. Умный подход — вот наш путь!

Под конец раздела, памятуя научный опыт, попробуем обозреть окрестности, держа в уме вопрос: а какие схемы используют уже существующие решения?

1. RFC-2544.
Как уже написано в разделе 1.5, мы не являемся сторонниками данного стандарта. Полный список аргументов мы обсудим позднее, а здесь упомянем, что схема включения DUT, даже в форме multiple, никак не относится к реальной сети, только к лаборатории. Поэтому схема включений может быть выбрана произвольно.

2. Y.1540.
Данный текст проработан уже лучше по сравнению с предыдущим, однако схема рекомендована только в виде рисунка 13, что не может быть признано удовлетворительным. Так как его минусы мы привели выше. Да и. кроме того, источником вдохновения для авторов стандарта послужил безусловно I.353, что хотя и понятно, но всё-таки для сетей стандарта TCP/IP странно. Ведь синхронного поведения тут нет априори.

3. vendor lock.
В этом пункте мы объединили всех производителей, как патентованных, так и просто недокументированных протоколов. Схемы включений могут быть разными, так как технологии отличаются. Однако, заметим, что большинство всё-таки склоняется к схеме на рисунке 16. Во многих случаях производитель, как уже и было сказано ранее, «рекомендует» закупать побольше устройств для расстановки на сети в виде дополнительных агентов. За подробностями отсылаем к соответствующим документам.

4. G.8013.
Поскольку данный стандарт создан только для Ethernet-сетей канального уровня, мы считаем, что здесь, где обсуждаются сети TCP/IP, использовать его схемы неразумно.

5. iperf3.
Данное свободное программное обеспечение может быть установлено на любое устройство, поддерживающее ОС Linux/BSD и им подобные. Хотя схема включений в документации и не конкретизирована, можно сказать, что она аналогична рисунку 15 или рисунку 16 в зависимости от того, используется ли конкретная аппаратная платформа в виде CE или нет. Так как указанное прикладное ПО встроено в ОС общего назначения, но при этом не умеет оперировать с трафиком транзита.

6. ping, bwping.
Упомянутое ПО широко используется и в целом схема полностью аналогична случаю с iperf.

7. RFC-5357 (TWAMP), RFC-4656 (OWAMP).
Поскольку в обоих стандартах описываются протоколы, реализуемые на том или ином устройстве в ОС или прикладном ПО, можно говорить что схема включений аналогична рисунку 15 или рисунку 16, как и в предыдущих двух случаях.

Итак, аргументы мы привели. Рекомендации по использованию рисунка 16 как базового дали. Вам следует решить, что делать в реальности. Мы не навязываем свой метод, однако сами используем на практике именно его. Если у вас есть новые аргументы в пользу чего-то иного, с удовольствием узнаем ваше мнение.

cc: lj, telegraph, vk, telegram: 1,2, zen, AT, MMM

Далее...