Элементарно...
Используется:
172.16.0.0 маска 255.255.252.0 gate 172.16.152.255
&
10.0.0.0 mask 255.0.0.0 gate 172.16.152.255

Некоторым провайдерам лень назначать шлюзу дополнительный адрес, и тогда найти его можно только по ARP. Как кстати с этим обстоят дела у 210?

Возник очередной вопрос, если суммирование пропускной способности в настоящее время нет, то что тогда подразумевается под балансировкой?
По логике то это и есть суммирование каналов или я что то не так понимаю???

Суммирование это объединение 2 линий в одну виртуальную.
Балансировка это подключение к 2 различным линиям и их использование в зависимости от текущей загрузки каждого канала.

2_RTFM77
Давайте придём к общему знаменателю. Вы сначала говорили, что сети:
10.0.0.0 маска 255.0.0.0 гейт 172.16.152.255
Сейчас это уже
172.16.0.0 маска 255.255.252.0 gate 172.16.152.255
Что в итоге?!
2 Beliar
Даже не представляю как такое может работать. Если ещё ко всему этому использовать proxyARP то можно поверить, но как устройство без соотвествующего интерфейса будет слать ответ? Кому оно будет слать ARP? А DFL-210 скорее всего сделает как от него требуется, пошлёт ARP, если будет ответ сформирует пакет.

Все это работает на основе ARP-таблиц в оконечном сегменте сети, о нормальной маршрутизации конечно речь не идет. Уже у 2 разных провайдеров в разных городах встречал такое.

Это роуты которые надо прописать...
Ну вот такой у меня провайдер...
10.10.10.2 - там находится у прова статистика
10.10.10.3 - там находится у прова ДНС
172.16.0.0 маска 255.255.252.0 - Это локальные ИП адреса
172.16.152.255 - Это гейт
Я что то упустил?
Спасибо.


Ну по сути я считаю это одинаковым, если смотреть дальше, то получается, при выставлении 99% в нагрузке на каждый канал, получается полностью загружены два канала, по логике мы и получим суммарную полосу пропускания..
Чисто так теоретичеки... или я опять неправ?

Да 2 канала можно использовать для ручного распределения нагрузки, но это не есть полное суммирование пропускной способности. Я ошибся, 210 не может пока как LB604 на основании нагрузки выбирать нужный канал. Зато позволяет ограничивать скорость и выдавать гарантированную пропускную способность в случае его 100% загрузки.

Выдаваемый вам адрес находиться в подсети 172.16.0.0 или 10.0.0.0?

Так. получается то, что я нифига не понимаю.
Переделаем вопрос так.

Провайдер 1 (TC-EXE)
Прописываем роуты:
10.0.0.0 маска 255.0.0.0 гейт 172.16.152.255
172.16.0.0 маска 255.255.252.0 gate 172.16.152.255
Ип в диапазоне 172.16.155.2
По ВПН получаем прямой ИП адрес идем в инет

Провайдер 2 (Corbina)
route -p add 85.21.29.242 mask 255.255.255.255 шлюз
route -p add 10.0.0.0 mask 255.0.0.0 шлюз
route -p add 195.14.50.26 mask 255.255.255.255 шлюз
route -p add 195.14.50.16 mask 255.255.255.255 шлюз
route -p add 85.21.79.0 mask 255.255.255.0 шлюз
route -p add 85.21.90.0 mask 255.255.255.0 шлюз
route -p add 83.102.231.32 mask 255.255.255.240 шлюз
route -p add 85.21.108.16 mask 255.255.255.240 шлюз
route -p add 85.21.138.208 mask 255.255.255.240 шлюз
route -p add 85.21.52.254 mask 255.255.255.255 шлюз
route -p add 85.21.88.130 mask 255.255.255.255 шлюз
route -p add 83.102.146.96 mask 255.255.255.224 шлюз
Шлюз будет в подсети 10.0.0. и скорей всего один на все роуты
ИП адрес в подсети 10.0.0.
По ВПН так же буду получать прямой ИП адрес.

Чего хотелось бы:
- При использовании торрента, что бы отдача и закачка шла по двум каналам
- Что бы Емул работал так же
Такое возможно?


У первого провайдера да,
У второго в 172.16

Тогда с маршрутизацией проблем не будет. Торрент для закачки будет использовать 2 канала если роуты к клиентам будут прописаны через разные интерфейсы. А насчет отдачи у вас будет 2 IP, нужно смотреть как это зарегистрировать на сервере.

Вот взять бы данную железку на тест, проблем бы небыло :о(((
Кстати, ту увидел что в Самаре данное оборудование можно взять на тест...

Вы в этом уверены?
Что значит роуты к клиентам?

Да, кажется бредом, но даже под Win это реально заработает! Но только если назначать эти параметры ТОЛЬКО В СВОЙСТВАХ ИНТЕРФЕЙСА. Попытка же задать точно такой же маршрут
route add 0.0.0.0 mask 0.0.0.0 172.16.152.255 IF 0x????
ни к чему не приведёт - "оно" выдаст "шлюз лежит вне сети интерфейса".
Собственно, если задуматся вглубь, то шлюз в eth-сети хосту нужен даже не в вмде IP, а в виде МАС-адреса, IP шлюза он реально использует только для этого, то есть для ARP-запроса.

Короче, в итоге это работает, но:
1) влечёт за собой кучу граблей
2) далеко не всё оборудование это поддерживает
3) собственно, я пока так и не понял, это соответствует RFC или нет и какому?

Торрент как известно использует прямые соединения для связи между клиентами. Соответсвенно если часть клиентов доступно через одного провайдера, а часть через другого то закачка происходит быстрее.

В итоге вообще можно "поиметь" косяк - если торрент-сервер публикует свой адрес1 в сети провайдера1, но имеет прямой маршрут к сети2, то без жесткой PBR на основании SourceAddress клиенты из сети провайдера2 могут вообще не достучаться до торрент-сервера, т.к. запросы будут входить на адрес1, а ответы ввиду наличия маршрута будут уходить не с адреса1 в сеть1, а вполне вероятно или с адреса2 в сеть2 (в итоге на той стороне раскосячится ТСР) или с адреса1 в сеть2 (что может порезать провайдер, Корбина, к примеру, режет)
Это касается ЛЮБОГО серверного IP-сервиса.