Kip Macy добавил (http://svn.freebsd.org/viewvc/base?view=revision&revision=19...) в дерево исходных текстов FreeBSD HEAD реализацию поддержки метрик маршрутов. Внесенные изменения дополняют добавленную (http://www.opennet.me/opennews/art.shtml?num=15356) в прошлом году реализацию поддержки создания нескольких маршрутов, которая допускала использование только одинакового веса.В команде route появилось несколько новых ключей:
- Параметр "weight" для задания веса маршрута (mpath);- Параметры "sticky" / "nostick" для выключения или включения балансировки нагрузки на уровне соединений;- Параметр "show", работающий как алиас к "get".
URL: http://docs.FreeBSD.org/cgi/mid.cgi?200904142305.n3EN5a2E022652
Новость: http://www.opennet.me/opennews/art.shtml?num=21262
А каким образом будет разделяться трафик между маршрутами с разным "весом" - как в случае с dummynet queue, скажем 70/30, или пока маршрут с высшим приоритетом не умрет низший не задействуется?
Вес то на то и вес, что обозначает короткий путь из пункта А в пункт В. Он выбирает живые маршруты с наименьшим весом, это же не балансировка нагрузки в конце то концов, а просто маршрутизация.
> Вес то на то и вес, что обозначает короткий путь из пункта
> А в пункт В. Он выбирает живые маршруты с наименьшим весом,
> это же не балансировка нагрузки в конце то концов, а просто
> маршрутизация.Нет. (C)
Добавлена именно _балансировка нагрузки_.
> Добавлена именно _балансировка нагрузки_.Какой нагрузки? Нагрузки на что?
Если включен мультироутинг, то одни IP-пакеты могут отправлятся к одному шлюзу с одной скоростью, к другому шлюзу с другой скоростью, так что ли?
> Какой нагрузки? Нагрузки на что?На канал.
> Если включен мультироутинг, то одни IP-пакеты могут отправлятся
> к одному шлюзу с одной скоростью, к другому шлюзу с другой скоростью, так что ли?Нет, СКОРОСТЬ отправки пакетов роутер менять не может -- это характеристика канала, и управляется только электроникой. Но он может регулировать ЧАСТОТУ ПОМЕЩЕНИЯ пакетов в исходящую очередь интерфейса. И отношение частот помещения будет обратно пропорционально отношению метрик. То есть, если на данный хост существует два возможных маршрута через интерфейсы с метриками 34 и 66, в исходящую очередь второго интерфейса пакеты будут попадать вдвое реже, чем в исходящую очередь первого.
Это, конечно, в теории: на практике всё заметно сложнее. Так как на практике для ускорения работы маршрутизатора используется клонирование маршрутов (то есть, не обход RADIX-Tree FIB на КАЖДЫЙ пакет, а после такого обхода для первого пакета строится клон маршрута типа "адрес получателя+nexthop" -- скажем, если у маршрутизатора в FIB пять тысяч сетей и дефолт, и пакет должен идти на дефолт, создаётся клон типа "хост такой-то роутится на дефолтный маршрутизатор", чтобы в следующий раз этот маршрут нашёлся до обхода дерева в пять тысяч маршрутов) и помещение клона в Routing Cache, приходится заметно "хитрить", чтобы такой способ балансировки работал адекватно.
Ну как бы неоднозначно... Ведь оригинальный коммит от Qing Li добавлял именно http://en.wikipedia.org/wiki/Equal-cost_multi-path_routing что и есть разделение трафика между несколькими маршрутами. А этот коммит расширяет функциональность...Все же, наверно, правильно не метрика, а "вес" маршрута? Как в случае с queue?
>add weights to allow mpath to do more than equal cost
Очень странно! Я на juniper точно разные метрики для маршрутов назначал, помню. А ведь там FreeBSD даже не 5.Х. Сами видимо дописывали
> Очень странно! Я на juniper точно разные метрики для маршрутов назначал, помню.
> А ведь там FreeBSD даже не 5.Х. Сами видимо дописывалиНа FreeBSD в JunOS'е сделаны только высокоуровневые вещи (типа протоколов динамической маршрутизации, route decision engine, etc.). Непосредственно маршрутизацией пакетов заведует NPU, и работает он под управлением совсем не FreeBSD. :)
Хорошо! Просто замечательно!