HTB qdisc ребенок другого HTB qdisc недостатки
Я думаю, что необходимо выглядеть немного ближе на то, какой уровень Вы пытаетесь измерить. Вы пытаетесь измерить уровень времени сходимости протоколов маршрутизации, сетевой пропускной способности или чего-то еще?
Я предполагаю, что один проект посмотрел бы в то время, когда он может взять для маршрутизатора для выбора другого пути, когда текущий путь понижается. Вы могли посмотреть на различия в маршрутном обновлении между различными протоколами маршрутизации в различных проектах топологии? Однако я предполагаю, что этот вид вещи уже хорошо документируется для различных алгоритмов/реализаций маршрутизации.
Я не думаю, что маршрутизатор будет заботиться слишком много, какой LAN это - часть... звезды, кольца, сетки. Это создаст свою таблицу переадресации согласно тому, что это получает известие от других маршрутизаторов в сети и выберет лучший путь к другим сетям.
Вы говорите, что немного смущены так это, возможно, лучше всего для работы немного над вопросом и что Вы хотите протестировать перед вскакиванием в него.
Бывают ситуации, когда требуется отложенная передача - например, при имитации медленного соединения. В простом случае приоритезации трафика подойдет создание двух или более классов HTB с разными приоритетами и использование фильтров для назначения им трафика. Но, тем не менее, вы должны добавить qdisc стохастической справедливой очереди в качестве дочернего qdisc ваших классов HTB, чтобы убедиться, что одно соединение внутри класса не истощает другие. На lartc.org есть несколько примеров по этой теме - ознакомьтесь с ними.