https://www.opennet.ru/openforum/vsluhforumID6/18040.html Всем доброго времени суток! Подскажите, пожалуйста, как эффективно загрузить два интерфейса Cisco. Есть маршрутизатор Cisco с serial0/0, serial0/1, serial0/2, fa0/0. На serial0/0 горло 1024 кб/с, за которым 8 сетей. Все они (а еще локалка этого рутера через fa0/0) стремятся качать данные из/в 2 сети, находящихся за serial0/1, serial0/2. До этих сетей по OSPF через serial0/1 один hop (у serial0/1 band = 1024 ) . До этих же сетей по OSPF через serial0/2 два hop'а (у serial0/2 band = 768 ) . Естественно, OSPF выбирает serial0/1, в результате все 8 сетей идут через serial0/1, возникает перегрузка serial0/1, а serial0/2 простаивает. Я хотел часть сетей отправить через serial0/2 статикой в стиле: ip route x.x.x.0 255.255.255.0 serial0/2 , трафик, конечно, направляется, но следующий за serial0/2 маршрутизатор не хочет направлять пакеты дальше и эта сеть остается без связи. Вообще, можно чтобы трафик автоматически добавлялся в serial0/2 только при перегрузке serial0/1 (скажем процентов на 80). Баловался с PBR, https://www.opennet.ru/openforum/vsluhforumID6/18040.html#30 Mon, 02 Feb 2009 11:07:22 GMT &gt;[оверквотинг удален]<br>&gt;&gt;frame-relay interface-dlci ? <br>&gt;&gt; &lt;16-1007&gt; Define a switched or locally terminated DLCI<br>&gt;&gt;несколько (не более 10 штук) из них служебные, и использовать их нельзя <br>&gt;&gt;- но вот какие уже точно непомню, надо доку смотреть :) <br>&gt;&gt;<br>&gt;<br>&gt;Вообщем, попробовал на реальной системе - в целом в таком варианте пока <br>&gt;удовлетворяет. Думаю, вопрос наверно можно считать закрытым. Возникнет ли необходимость в <br>&gt;дополнительных настройках - покажет время. В любом случае это уже другая <br>&gt;тема. Большое спасибо!!! <br><br>Та нема за что :)<br> https://www.opennet.ru/openforum/vsluhforumID6/18040.html#29 Mon, 02 Feb 2009 08:36:06 GMT &gt;[оверквотинг удален]<br>&gt;Конечно ОДИН пользователь в ОДНУ закачку ВСЮ скорость не получает, <br>&gt;но это даже ничего - другие попадают в другой канал и <br>&gt;работают вполне комфортно, по крайней мере половина из них :) <br>&gt;<br>&gt;Количество DLCI <br>&gt;frame-relay interface-dlci ? <br>&gt; &lt;16-1007&gt; Define a switched or locally terminated DLCI<br>&gt;несколько (не более 10 штук) из них служебные, и использовать их нельзя <br>&gt;- но вот какие уже точно непомню, надо доку смотреть :) <br>&gt;<br><br>Вообщем, попробовал на реальной системе - в целом в таком варианте пока удовлетворяет. Думаю, вопрос наверно можно считать закрытым. Возникнет ли необходимость в дополнительных настройках - покажет время. В любом случае это уже другая тема. Большое спасибо!!!<br> https://www.opennet.ru/openforum/vsluhforumID6/18040.html#28 Mon, 02 Feb 2009 07:36:07 GMT &gt;[оверквотинг удален]<br>&gt;2) Band на подинтерфейсах DLCI - для метрики OSPF или это как-то <br>&gt;влияет на реальную полосу пропускания (учитывая, что FR - протокол канального <br>&gt;уровня) и все-таки можно было обойтись им одним без применения OSPF <br>&gt; per-packet balance ? <br>&gt;3) Если пропущено много DLCI в одном физическом интерфейсе то, когда хосты <br>&gt;качают данные, каждая сессия стремится забрать под себя полосу пропускания по <br>&gt;нарастающей, вплоть до исчерпания физики. Значит надо настраивать ограничения на каждый <br>&gt;транзитный DLCI на его концах в стиле деления физической полосы транзитных <br>&gt;интерфейсов на кол-во DLCI. Так и до модемной скорости упадет. Или <br>&gt;я чего-то не понимаю ? <br><br>Читаете теорию по FR-у, там много описано :)<br>А "на пальцах" - CIR - "гарантированная" скорость - FR свич пытается обеспечить ее любыми средствами, EIR- "негарантированая", максимально допустимая - CIR + EIR, если канал на данный момент имеет емкость CIR + EIR - абонент получит всю полосу, если канал становится подгруженым, кон https://www.opennet.ru/openforum/vsluhforumID6/18040.html#27 Sat, 31 Jan 2009 14:33:41 GMT &gt;[оверквотинг удален]<br>&gt;&gt;<br>&gt;&gt;2)При создании FR позиционировалось как соединение без коррекции ошибок(notification не в счет). <br>&gt;<br>&gt;TCP/IP с этим должен справиться. <br>&gt;<br>&gt;&gt;Хотя, если в кабеле ошибки - и PPP не поможет. <br>&gt;&gt;3)Что, если destination еще дальше за RouterC,а там везде PPP ? (хотя <br>&gt;&gt;это не должно влиять) <br>&gt;<br>&gt;Опятьже - IP трафику неположено знать поверх чего он бегает. <br><br>Сделал на DLCI 44 физически полосу 14 таймслотов (channel-group 2 timeslots 1-14), т.е. 896 кб/с. Папка перекачивается без ошибки, но скорость по обоим физическим интерфейсам, по которым идут DLCI 43,44 равна 896 кб/с, а хотелось бы, чтобы по одному интерфейсу шло 2048 кб/с, а по второму - 896 кб/с. Т.е. интерфейс с более широким горлом остается недогруженным. Cisco так, наверно, распределяет, потому что видит в своем конфиге channel-group 2 timeslots 1-14. А в реальности более узкое горло сформировано физически не на Cisco. Тогда она наверно будет пихать в оба интерфейса со скоростью 2048 кб/с и в более узком будут отбросы п https://www.opennet.ru/openforum/vsluhforumID6/18040.html#26 Fri, 30 Jan 2009 14:29:10 GMT &gt;.... Сейчас сделаю горло на одном из этих двух линков <br>&gt;в 1,5 раза меньше (сделаю не unframed, а timeclots 1-20 например), <br>&gt;и посмотрю, будут ли в нем теряться пакеты и перекачается ли <br>&gt;папка (так как на реальной системе физически линки отличаются по полосе). <br><br>вот тут уже можно с трафик шейпингом на FR-ах поиграться, CIR, EIR и т.д. <br><br><br>&gt;<br>&gt;Если будут теряться - вопрос далек от окончательного решения. <br>&gt;Per-destination рекомендуется, когда пакеты идут очень отличающимися путями (что у меня наверно <br>&gt;в реальности и будет и как применять эту per-destination - еще <br>&gt;не знаю). <br>&gt;О результатах напишу. Конфиги и show ниже. <br>&gt;Наверно, тоже (ip load-sharing per-packet) получилось бы без FR, но удобство FR <br>&gt;очевидно в плане обслуживания виртульных линков и присвоения им band для <br>&gt;OSPF. Вообще, возникает желание сделать на сети FR full-mesh, но: <br>&gt;1)Сколько можно пропустить (switched) DLCI через один физический порт (в среднем E1-порт)? <br><br>Пока DLCI не закончаться :)<br>В реалиях 50 шт работало без пр https://www.opennet.ru/openforum/vsluhforumID6/18040.html#25 Fri, 30 Jan 2009 13:08:41 GMT &gt;Ну как? получилось что-нить или нет? <br><br>Поднял ip load-sharing per-packet (совместно с ip cef) на обоих концах RouterA, RouterC. Нагрузка равномерно распределилась по обоим DLCI 43,44. Т.е. это балансировка OSPF per-packet, когда в таблице маршрутизации до одной сети - два маршрута с равными метриками. Cisco тогда кидает поочередно пакеты то в один интерфес, то в другой. Проверял, перекачивая папку 70Мб с помощью NetOp File Tranfer. Получилось по функциональности как мультилинк, причем папка перекачивается ровно в два раза быстрее, чем через один линк. Включить subinterfaces в реальный non-distributed мультилинк-bundle Cisco не дает (и в мануале также). Сейчас сделаю горло на одном из этих двух линков в 1,5 раза меньше (сделаю не unframed, а timeclots 1-20 например), и посмотрю, будут ли в нем теряться пакеты и перекачается ли папка (так как на реальной системе физически линки отличаются по полосе). <br>Если будут теряться - вопрос далек от окончательного решения.<br>Per-destination рекомендуется, когда пакеты https://www.opennet.ru/openforum/vsluhforumID6/18040.html#24 Fri, 30 Jan 2009 11:23:54 GMT Ну как? получилось что-нить или нет?<br> https://www.opennet.ru/openforum/vsluhforumID6/18040.html#23 Thu, 29 Jan 2009 07:15:53 GMT Поповоду сборки пакетов - пакеты могут приходить не в том порядке, в котором были отправлены - это да, но tcp к этому приспособлен.<br>Кроме того при некритичной нагрузке на каналы - разница в задержке крайне мала, в чем собственно и прелесть FR-а - транзитные FR свичи при коммутации FR кадров практически не вносят задержек - попробуйте погасить поочереди DLCI 43 и 44 и сравните задержку :)<br> https://www.opennet.ru/openforum/vsluhforumID6/18040.html#22 Thu, 29 Jan 2009 07:06:25 GMT &gt;[оверквотинг удален]<br>&gt;line vty 0 4 <br>&gt; logging synchronous <br>&gt; login local <br>&gt; transport input telnet <br>&gt;! <br>&gt;scheduler allocate 20000 1000 <br>&gt;! <br>&gt; end <br>&gt;<br>&gt;RouterC#exit <br><br>Чтобы получить попакетную балансировку надо cef отключить.<br>Таким тестом врядли что-то удидите, одна сессия попадет в один канал, балансировка будет наблюдаться при достаточно большом количестве сессий.<br><br>Мультилинк на FR-е поднимал только между 2-мя соседними маршрутерами, незнаю можно ли 2 dlci обьединить в мультилинк.<br>