| 1.3, terminus (ok), 11:22, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А каким образом будет разделяться трафик между маршрутами с разным "весом" - как в случае с dummynet queue, скажем 70/30, или пока маршрут с высшим приоритетом не умрет низший не задействуется?
| | |
| |
| 2.14, RapteR (ok), 11:58, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
 Вес то на то и вес, что обозначает короткий путь из пункта А в пункт В. Он выбирает живые маршруты с наименьшим весом, это же не балансировка нагрузки в конце то концов, а просто маршрутизация.
| | |
| |
| 3.23, Andrew Kolchoogin (?), 12:26, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
> Вес то на то и вес, что обозначает короткий путь из пункта
> А в пункт В. Он выбирает живые маршруты с наименьшим весом,
> это же не балансировка нагрузки в конце то концов, а просто
> маршрутизация.
Нет. (C)
Добавлена именно _балансировка нагрузки_.
| | |
| |
| 4.30, iZEN (ok), 13:06, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Добавлена именно _балансировка нагрузки_.
Какой нагрузки? Нагрузки на что?
Если включен мультироутинг, то одни IP-пакеты могут отправлятся к одному шлюзу с одной скоростью, к другому шлюзу с другой скоростью, так что ли?
| | |
| |
| 5.31, Andrew Kolchoogin (?), 13:56, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Какой нагрузки? Нагрузки на что?
На канал.
> Если включен мультироутинг, то одни IP-пакеты могут отправлятся
> к одному шлюзу с одной скоростью, к другому шлюзу с другой скоростью, так что ли?
Нет, СКОРОСТЬ отправки пакетов роутер менять не может -- это характеристика канала, и управляется только электроникой. Но он может регулировать ЧАСТОТУ ПОМЕЩЕНИЯ пакетов в исходящую очередь интерфейса. И отношение частот помещения будет обратно пропорционально отношению метрик. То есть, если на данный хост существует два возможных маршрута через интерфейсы с метриками 34 и 66, в исходящую очередь второго интерфейса пакеты будут попадать вдвое реже, чем в исходящую очередь первого.
Это, конечно, в теории: на практике всё заметно сложнее. Так как на практике для ускорения работы маршрутизатора используется клонирование маршрутов (то есть, не обход RADIX-Tree FIB на КАЖДЫЙ пакет, а после такого обхода для первого пакета строится клон маршрута типа "адрес получателя+nexthop" -- скажем, если у маршрутизатора в FIB пять тысяч сетей и дефолт, и пакет должен идти на дефолт, создаётся клон типа "хост такой-то роутится на дефолтный маршрутизатор", чтобы в следующий раз этот маршрут нашёлся до обхода дерева в пять тысяч маршрутов) и помещение клона в Routing Cache, приходится заметно "хитрить", чтобы такой способ балансировки работал адекватно.
| | |
|
|
| 3.26, terminus (ok), 12:30, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Ну как бы неоднозначно... Ведь оригинальный коммит от Qing Li добавлял именно http://en.wikipedia.org/wiki/Equal-cost_multi-path_routing что и есть разделение трафика между несколькими маршрутами. А этот коммит расширяет функциональность...
Все же, наверно, правильно не метрика, а "вес" маршрута? Как в случае с queue?
>add weights to allow mpath to do more than equal cost | | |
|
|
| 1.18, Аноним (-), 12:10, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Очень странно! Я на juniper точно разные метрики для маршрутов назначал, помню. А ведь там FreeBSD даже не 5.Х. Сами видимо дописывали
| | |
| |
| 2.21, Andrew Kolchoogin (?), 12:19, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
> Очень странно! Я на juniper точно разные метрики для маршрутов назначал, помню.
> А ведь там FreeBSD даже не 5.Х. Сами видимо дописывали
На FreeBSD в JunOS'е сделаны только высокоуровневые вещи (типа протоколов динамической маршрутизации, route decision engine, etc.). Непосредственно маршрутизацией пакетов заведует NPU, и работает он под управлением совсем не FreeBSD. :)
| | |
|
|
