Везде написано, что при включенном ip cef (включен по умолчанию) и наличии двух статических маршрутов в одну сеть с одинаковой метрикой должна происходить балансировка трафика per-destination (т.е. в зависимости от адреса назначения) между этими маршрутами.У меня на стендовой 2811, например, настроено:
ip cef
interface FastEthernet0/0.10
encapsulation dot1Q 10
ip address 192.168.254.1 255.255.255.0
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
ip address 192.168.253.1 255.255.255.0
!
interface FastEthernet0/1
ip address 10.0.0.70 255.255.255.0ip route 0.0.0.0 0.0.0.0 192.168.254.254 10
ip route 0.0.0.0 0.0.0.0 192.168.253.254 10Для проверки пингую с адреса 10.0.0.10 (компьютер, подключенный к Fa 0/1 и имеющий шлюзом 10.0.0.70) одновременно два адреса - 172.30.0.1 и 172.30.1.1. Ожидаю, что трафик на один адрес пойдет по одному маршруту (через fa 0/0.10), к другому - через другой (через fa 0/0.20).
Но весь трафик уходит через один маршрут. Через второй маршрут трафик не идет совсем.r2#sh ip cef exact-route 10.0.0.10 172.30.0.1
10.0.0.10 -> 172.30.0.1 => IP adj out of FastEthernet0/0.20, addr 192.168.253.254
r2#sh ip cef exact-route 10.0.0.10 172.30.1.1
10.0.0.10 -> 172.30.1.1 => IP adj out of FastEthernet0/0.20, addr 192.168.253.254То же самое вижу и на включенном в разрыве сети анализаторе трафика - весь трафик идет по одному интерфейсу fa0/0.20.
Если добавлять пинги на другие адреса - картина та же (при этом все адреса реально есть в сети и пинги ходят, но никакой балансировки между маршрутами не происходит).
Что я делаю не так?
Понятно, что тест не вполне честный, пинг никакой реальной нагрузки на каналы не дает - но если обещали балансировку per-destination, то хочу ее увидеть.
попробуй другой соурс-IPэто все работает, когда реально разный траффик
> попробуй другой соурс-IP
> это все работает, когда реально разный траффикПробовал. Без разницы.
смотрю
r2#sh cef int fa 0/0.20
и вижу:FastEthernet0/0.20 is up (if_number 6)
Corresponding hwidb fast_if_number 6
Corresponding hwidb firstsw->if_number 2
Internet address is 192.168.253.1/24
ICMP redirects are always sent
Per packet load-sharing is disabled
IP unicast RPF check is disabled
Output features: Post-Ingress-NetFlow
IP policy routing is disabled
BGP based policy accounting on input is disabled
BGP based policy accounting on output is disabled
Hardware idb is FastEthernet0/0
Fast switching type 1, interface type 18
IP CEF switching enabled
IP CEF switching turbo vector
IP prefix lookup IPv4 mtrie 8-8-8-8 optimized
Input fast flags 0x0, Output fast flags 0x0
ifindex 2(2)
Slot Slot unit 0 VC -1
IP MTU 1500аналогично для fa 0/0.10
в выводе есть строка Per packet load-sharing is disabled - т.е. на этих интерфейсах балансировка выключена.
попытка включить балансировку на интерфейсе
r2(config-subif)#ip load-sharing per-packet
ни к чему не приводит (везде сказано, что она включена по дефолту, похоже на то - новых строк в конфигурации интерфейса не появляется, в sh run all строка присуствует).вопрос - как бы ее (балансировку) все-таки включить? или на сабинтерфейсах это нельзя? (тогда плохо - когда разные каналы включены на один физический интерфейс через vlan'ы - нормальная ситуация в наше время).
> в выводе есть строка Per packet load-sharing is disabled - т.е.
> на этих интерфейсах балансировка выключена.
> вопрос - как бы ее (балансировку) все-таки включить?Был неправ. включается и выключается она как-то сама по себе. Что-то похожее на балансировку иногда даже происходит, но по своершенно непонятной мне логике.
запустил одновременные пинги
с 10.0.0.10 на 172.30.0.1
с 10.0.0.10 на 172.30.1.1
с 10.0.0.10 на 172.30.2.1
с 10.0.0.80 на 172.30.0.1сеть 172.30.0.0/16 находится за другим маршрутизатором со сторого анадогичными настройками.
в итоге вижу, что в одну сторону (от 10.0.0.0/24 к 172.30.0.0/16) трафик идет от одного источника по одному интерфейсу, по другому с другого (т.е. балансировка типа per-source, а не per-destinantion получается, хотя такой способ вообще нигде не описан и не упоминается):
r2#sh ip cef exact-route 10.0.0.10 172.30.0.1
10.0.0.10 -> 172.30.0.1 => IP adj out of FastEthernet0/0.20, addr 192.168.253.254
r2#sh ip cef exact-route 10.0.0.10 172.30.1.1
10.0.0.10 -> 172.30.1.1 => IP adj out of FastEthernet0/0.20, addr 192.168.253.254
r2#sh ip cef exact-route 10.90.90.10 172.30.2.1
10.0.0.10 -> 172.30.2.1 => IP adj out of FastEthernet0/0.20, addr 192.168.253.254
r2#sh ip cef exact-route 10.90.90.80 172.30.0.1
10.0.0.80 -> 172.30.0.1 => IP adj out of FastEthernet0/0.10, addr 192.168.254.254при этом на интерфейсе fa0/0.10 per packet load-sharing стал enabled, на fa0/0.20 все равно disabled.
FastEthernet0/0.10 is up (if_number 5)
Corresponding hwidb fast_if_number 5
Corresponding hwidb firstsw->if_number 2
Internet address is 192.168.254.1/24
ICMP redirects are always sent
Per packet load-sharing is enabled
IP unicast RPF check is disabled
Output features: Post-Ingress-NetFlow
IP policy routing is disabled
BGP based policy accounting on input is disabled
BGP based policy accounting on output is disabled
Hardware idb is FastEthernet0/0
Fast switching type 1, interface type 18
IP CEF switching enabled
IP CEF switching turbo vector
IP prefix lookup IPv4 mtrie 8-8-8-8 optimized
Input fast flags 0x0, Output fast flags 0x0
ifindex 2(2)
Slot Slot unit 0 VC -1
IP MTU 1500
r2#sh cef int fa 0/0.20
FastEthernet0/0.20 is up (if_number 6)
Corresponding hwidb fast_if_number 6
Corresponding hwidb firstsw->if_number 2
Internet address is 192.168.253.1/24
ICMP redirects are always sent
Per packet load-sharing is disabled
IP unicast RPF check is disabled
Output features: Post-Ingress-NetFlow
IP policy routing is disabled
BGP based policy accounting on input is disabled
BGP based policy accounting on output is disabled
Hardware idb is FastEthernet0/0
Fast switching type 1, interface type 18
IP CEF switching enabled
IP CEF switching turbo vector
IP prefix lookup IPv4 mtrie 8-8-8-8 optimized
Input fast flags 0x0, Output fast flags 0x0
ifindex 2(2)
Slot Slot unit 0 VC -1
IP MTU 1500
С другой стороны (при аналогичной настройке маршрутизатора) что-то больше похожее на per-destination:R1#sh ip cef exact-route 172.30.0.1 10.0.0.10
172.30.0.1 -> 10.0.0.10 => IP adj out of FastEthernet0/0.10, addr 192.168.254.1
R1#sh ip cef exact-route 172.30.1.1 10.0.0.10
172.30.1.1 -> 10.0.0.10 => IP adj out of FastEthernet0/0.10, addr 192.168.254.1
R1#sh ip cef exact-route 172.30.2.1 10.0.0.10
172.30.2.1 -> 10.0.0.10 => IP adj out of FastEthernet0/0.10, addr 192.168.254.1
R1#sh ip cef exact-route 172.30.0.1 10.0.0.80
172.30.0.1 -> 10.0.0.80 => IP adj out of FastEthernet0/0.20, addr 192.168.253.1и при этом на R1 Per packet load-sharing на обоих интерфейсах disabled
Не могу понять эту логику (а поэтому и применять на реальной системе - страшно, хотя очень хочется).
> - страшно, хотя очень хочется).а что вы теряете? у вас 100% загрузка линка?
В общем, загадочная система.
нашел команду ip cef load-sharing algorithm
требует задать один из 4-х вариантов:
original
universal [id]
tunnel [id]
include-portsпо умолчанию в sh run all не показывается. но прочитал что по умолчанию стоит в universal c неким уникальным для железки id. Этот id влияет на способ формирования hash-записей для форвардинга. Подробно в это углубляться не стал, попробовал экспериментально.
запустил трафик с одного адреса источника на 4 разных получателя.
с original - весь трафик идет по одному маршруту.
c tunnel - честно и равномерно распределяется по двум имеющимся маршрутам
с universal - без параметра id (когда циска сама его придумывает, уникальный для железки) - весь трафик идет по одному маршруту, но другому, чем с original
если менять id у universal (диапазон громадный, 1-FFFFFFFF, попробовал на вскидку несколько вариантов с маленькими и с большими значениями), то поведение меняется.
то весь трафик по одному маршруту, то по другому, то распределяется равномерно, то с перекосом (поскольку получателей в тесте всего 4, то получается 3:1) на один маршрут. Короткого внятного описания, как устроено хеширование, как на него влияет id и что должно в итоге получаться - не нашел. Есть слова про то, как устроено хеширование, но что из этого следует - сходу не понял, надо толстые книжки читать, видимо...
include-ports (в зависимости от source/dest портов) даже пробовать не стал, не мой случай.остается надеяться, что на реальном канале с сотнями разных адресов в проходящих пакетах, будет работать честно (и для ситуации "два линка - два провода(туннеля) между маршрутизаторами, как я понял, оптимальный вариант tunnel).
но все оказывается гораздо более заморочено, чем кажется поначалу.
>[оверквотинг удален]
> на него влияет id и что должно в итоге получаться -
> не нашел. Есть слова про то, как устроено хеширование, но что
> из этого следует - сходу не понял, надо толстые книжки читать,
> видимо...
> include-ports (в зависимости от source/dest портов) даже пробовать не стал, не мой
> случай.
> остается надеяться, что на реальном канале с сотнями разных адресов в проходящих
> пакетах, будет работать честно (и для ситуации "два линка - два
> провода(туннеля) между маршрутизаторами, как я понял, оптимальный вариант tunnel).
> но все оказывается гораздо более заморочено, чем кажется поначалу.Исессно, простая по началу весч обростает кучей "улучшений/дополнений/обвеса" и....
Имеем, что имеем.а еще per-flow балансировка вроде встречается....
>[оверквотинг удален]
>> видимо...
>> include-ports (в зависимости от source/dest портов) даже пробовать не стал, не мой
>> случай.
>> остается надеяться, что на реальном канале с сотнями разных адресов в проходящих
>> пакетах, будет работать честно (и для ситуации "два линка - два
>> провода(туннеля) между маршрутизаторами, как я понял, оптимальный вариант tunnel).
>> но все оказывается гораздо более заморочено, чем кажется поначалу.
> Исессно, простая по началу весч обростает кучей "улучшений/дополнений/обвеса" и....
> Имеем, что имеем.
> а еще per-flow балансировка вроде встречается....Это не считая "пер-пакет"
>[оверквотинг удален]
> 10.0.0.10 -> 172.30.1.1 => IP adj out of FastEthernet0/0.20, addr 192.168.253.254
> То же самое вижу и на включенном в разрыве сети анализаторе трафика
> - весь трафик идет по одному интерфейсу fa0/0.20.
> Если добавлять пинги на другие адреса - картина та же (при этом
> все адреса реально есть в сети и пинги ходят, но никакой
> балансировки между маршрутами не происходит).
> Что я делаю не так?
> Понятно, что тест не вполне честный, пинг никакой реальной нагрузки на каналы
> не дает - но если обещали балансировку per-destination, то хочу ее
> увидеть.sh arp