В первой точке имеется коммутатор Cisco 3750, на него в приходит два vlan'а:
vlan100 - vpn layer3 от одного провайдера, адресация 10.1.0.0/24
vlan200 - vpn layer3 от другого провайдера, адресация 10.2.0.0/24
там же есть маршрутизатор Cisco 2811

Каждый влан по сетям провайдера доведен до второй точки, с адресациями:
vlan100 - 10.10.0.0/24
vlan200 - 10.20.0.0/24

канал каждого провайдера - 4 мбита.

Первая точка должна видеть вторую точку всегда, пусть на низкой скорости - но всегда!

Задача:
а) Выбрать циску для второй точки, чтоб можно было эти каналы собрать в один (пусть псевдо, но..) 8 мбит, чтоб падение канала одного провайдера не влияло на работоспособность, а только на "проседание" канала до 4 мбит.

б) Как составить гуглю запрос для того, чтоб это настроить?

• Объединение двух каналов vpn в  один,Merridius, 22:31 , 15-Мрт-11
  • Объединение двух каналов vpn в  один,Aplei, 23:34 , 15-Мрт-11
    • Объединение двух каналов vpn в  один,Merridius, 23:57 , 15-Мрт-11
      • Объединение двух каналов vpn в  один,Merridius, 00:06 , 16-Мрт-11
        • Объединение двух каналов vpn в  один,Aplei, 08:38 , 16-Мрт-11
          • Объединение двух каналов vpn в  один,GolDi, 10:02 , 16-Мрт-11
            • Объединение двух каналов vpn в  один,Aplei, 22:50 , 16-Мрт-11
              • Объединение двух каналов vpn в  один,GolDi, 12:39 , 17-Мрт-11
          • Объединение двух каналов vpn в  один,Puk, 10:59 , 16-Мрт-11
            • Объединение двух каналов vpn в  один,Aplei, 22:54 , 16-Мрт-11
              • Объединение двух каналов vpn в  один,Merridius, 23:11 , 16-Мрт-11
                • Объединение двух каналов vpn в  один,Aplei, 23:12 , 16-Мрт-11

>[оверквотинг удален]
> vlan100 - 10.10.0.0/24
> vlan200 - 10.20.0.0/24
> канал каждого провайдера - 4 мбита.
> Первая точка должна видеть вторую точку всегда, пусть на низкой скорости -
> но всегда!
> Задача:
> а) Выбрать циску для второй точки, чтоб можно было эти каналы собрать
> в один (пусть псевдо, но..) 8 мбит, чтоб падение канала одного
> провайдера не влияло на работоспособность, а только на "проседание" канала до
> 4 мбит.

А чем 28я не устроила? или я чего-то не понял?

> б) Как составить гуглю запрос для того, чтоб это настроить?

>[оверквотинг удален]
>> vlan200 - 10.20.0.0/24
>> канал каждого провайдера - 4 мбита.
>> Первая точка должна видеть вторую точку всегда, пусть на низкой скорости -
>> но всегда!
>> Задача:
>> а) Выбрать циску для второй точки, чтоб можно было эти каналы собрать
>> в один (пусть псевдо, но..) 8 мбит, чтоб падение канала одного
>> провайдера не влияло на работоспособность, а только на "проседание" канала до
>> 4 мбит.
> А чем 28я не устроила? или я чего-то не понял?

в первой точке комплект оборудования: 3750+2811,
во второй пустой шкаф,
совсем пустой,
в него приходит два кабеля по 8 жил обжатые в пластмассовые коннекторы.
Нужно понять что нужно для второй точки, однако 2811 во вторую точку - это перебор, как мне кажется..
Не знаю как подробней объяснить..

+ Не знаю какую тему почитать для того, чтоб сделать "RAID0" для vpn, основанного на маршрутизации, а не просто vlan

>[оверквотинг удален]
>> А чем 28я не устроила? или я чего-то не понял?
> в первой точке комплект оборудования: 3750+2811,
> во второй пустой шкаф,
> совсем пустой,
> в него приходит два кабеля по 8 жил обжатые в пластмассовые коннекторы.
> Нужно понять что нужно для второй точки, однако 2811 во вторую точку
> - это перебор, как мне кажется..
> Не знаю как подробней объяснить..
> + Не знаю какую тему почитать для того, чтоб сделать "RAID0" для
> vpn, основанного на маршрутизации, а не просто vlan

как я понял схема у вас следующая
первая точка--два влана--вторая точка

тогда предлагаю через протоколы динамической маршрутизации разрулить эту ситуацию(ospf, eigrp, на худой конец rip)

при таких скоростях хватит и 1811 cisco во второй точке ( у нее два встроенных порта wan + свитч на 8 портов)  

к тому же вам не нужно настраивать никакие vpn, как я понял все за вас сделали провайдеры
все что вам нужно это, скажем ospf и ecmp.

а выбор обоудования нужно делать исходя из требований (в зависимости какие функции вам нужни и/или понадобятся), ну и тип интерфейсов, и производительность.

> к тому же вам не нужно настраивать никакие vpn, как я понял
> все за вас сделали провайдеры
> все что вам нужно это, скажем ospf и ecmp.
> а выбор обоудования нужно делать исходя из требований (в зависимости какие функции
> вам нужни и/или понадобятся), ну и тип интерфейсов, и производительность.

картина немного проясняется..

теперь еще по порядку:
1. с помощью ospf или ecmp можно каналы объединять в один для увеличения пропускной способности?
2. Мощность такая: канал с 0 до 8 утра спит.. с 8 утра до 12 дня нагрузка полнейшая 6-8 мбит, с 12 до 17 на уменьшение, после 18 - опять спит. Трафик внутри разный, телефония, web, ftp.
3. vpn настраивать не нужно, это делается на мплс сети провайдера

>[оверквотинг удален]
>> вам нужни и/или понадобятся), ну и тип интерфейсов, и производительность.
> картина немного проясняется..
> теперь еще по порядку:
> 1. с помощью ospf или ecmp можно каналы объединять в один для
> увеличения пропускной способности?
> 2. Мощность такая: канал с 0 до 8 утра спит.. с 8
> утра до 12 дня нагрузка полнейшая 6-8 мбит, с 12 до
> 17 на уменьшение, после 18 - опять спит. Трафик внутри разный,
> телефония, web, ftp.
> 3. vpn настраивать не нужно, это делается на мплс сети провайдера

Если каналы одинаковые по качеству, то eigrp и можно объединить.
Если качество разное то лучше этого не делать.

>[оверквотинг удален]
>> теперь еще по порядку:
>> 1. с помощью ospf или ecmp можно каналы объединять в один для
>> увеличения пропускной способности?
>> 2. Мощность такая: канал с 0 до 8 утра спит.. с 8
>> утра до 12 дня нагрузка полнейшая 6-8 мбит, с 12 до
>> 17 на уменьшение, после 18 - опять спит. Трафик внутри разный,
>> телефония, web, ftp.
>> 3. vpn настраивать не нужно, это делается на мплс сети провайдера
> Если каналы одинаковые по качеству, то eigrp и можно объединить.
> Если качество разное то лучше этого не делать.

насколько они должны быть одинаковые?
На первом пинг от 2 до 11 мс, потери 5-8%, на втором 1-3 мс, потери 0-1%

>[оверквотинг удален]
>>> 2. Мощность такая: канал с 0 до 8 утра спит.. с 8
>>> утра до 12 дня нагрузка полнейшая 6-8 мбит, с 12 до
>>> 17 на уменьшение, после 18 - опять спит. Трафик внутри разный,
>>> телефония, web, ftp.
>>> 3. vpn настраивать не нужно, это делается на мплс сети провайдера
>> Если каналы одинаковые по качеству, то eigrp и можно объединить.
>> Если качество разное то лучше этого не делать.
> насколько они должны быть одинаковые?
> На первом пинг от 2 до 11 мс, потери 5-8%, на втором
> 1-3 мс, потери 0-1%

У меня было 4 мс и 20 мс без потерь, попробовал объединить через eigrp и с variance игрался потом отказался, не понравилось.

>[оверквотинг удален]
>> вам нужни и/или понадобятся), ну и тип интерфейсов, и производительность.
> картина немного проясняется..
> теперь еще по порядку:
> 1. с помощью ospf или ecmp можно каналы объединять в один для
> увеличения пропускной способности?
> 2. Мощность такая: канал с 0 до 8 утра спит.. с 8
> утра до 12 дня нагрузка полнейшая 6-8 мбит, с 12 до
> 17 на уменьшение, после 18 - опять спит. Трафик внутри разный,
> телефония, web, ftp.
> 3. vpn настраивать не нужно, это делается на мплс сети провайдера

Я хотел бы заметить, что 100%-ная нагрузка на канал в течение нескольких часов каждый день - повод задуматься о том, что пропускной способности каналов не хватает.
При достижении 60%-ной загрузки каналов уже стоит начинать работы по их расширению.
По моему что-то изначально неправильно.
Вместо объединения в непонятные 8мбит/сек, на цисках есть policy routing и ip sla.

>[оверквотинг удален]
>> 17 на уменьшение, после 18 - опять спит. Трафик внутри разный,
>> телефония, web, ftp.
>> 3. vpn настраивать не нужно, это делается на мплс сети провайдера
> Я хотел бы заметить, что 100%-ная нагрузка на канал в течение нескольких
> часов каждый день - повод задуматься о том, что пропускной способности
> каналов не хватает.
> При достижении 60%-ной загрузки каналов уже стоит начинать работы по их расширению.
> По моему что-то изначально неправильно.
> Вместо объединения в непонятные 8мбит/сек, на цисках есть policy routing и ip
> sla.

близкая к 100% нагрузка связана с телефонией в основном, утром очень много звонков, естественно имеется ограничение на максимальное количество одновременных сессий + с утра всем надо срочно погоду и вконтакте проверить!

А зачем 4-5 мбита держать в резерве? Если ежедневный трафик полностью известен?

>[оверквотинг удален]
>> часов каждый день - повод задуматься о том, что пропускной способности
>> каналов не хватает.
>> При достижении 60%-ной загрузки каналов уже стоит начинать работы по их расширению.
>> По моему что-то изначально неправильно.
>> Вместо объединения в непонятные 8мбит/сек, на цисках есть policy routing и ip
>> sla.
> близкая к 100% нагрузка связана с телефонией в основном, утром очень много
> звонков, естественно имеется ограничение на максимальное количество одновременных сессий
> + с утра всем надо срочно погоду и вконтакте проверить!
> А зачем 4-5 мбита держать в резерве? Если ежедневный трафик полностью известен?

затем, что если срочно понадобятся эти 4 мбита, ну там гендиректору для чего-нибудь например у вас их не будет, и придется всех остальных урезать.

>[оверквотинг удален]
>>> По моему что-то изначально неправильно.
>>> Вместо объединения в непонятные 8мбит/сек, на цисках есть policy routing и ip
>>> sla.
>> близкая к 100% нагрузка связана с телефонией в основном, утром очень много
>> звонков, естественно имеется ограничение на максимальное количество одновременных сессий
>> + с утра всем надо срочно погоду и вконтакте проверить!
>> А зачем 4-5 мбита держать в резерве? Если ежедневный трафик полностью известен?
> затем, что если срочно понадобятся эти 4 мбита, ну там гендиректору для
> чего-нибудь например у вас их не будет, и придется всех остальных
> урезать.

ну до 10 утра и директор с пониманием потерпит