kha0s

Так не интересно - приоткройте занавес!

Угу, либо аплинк поделился конфигом к mtrg и у обоих там одинаковые значения MaxBytes при превышении которых рисуются нули.

Поскольку исходных данных ноль, вангую превышения зашитого макс. значения каунтера в конфиге mrtg

Да, спасибо. Был невнимателен и пропустил слово relay в предложении использовать lvs.

40Гбит DHCP запросов? Ты хоть разберись о чем тут пишут. Эта схема работает на HTTP/FTP хоть на 1Тбит хоть на 100Тбит живого траффика Да, возможно. Просто в схеме работы lvs визуально выглядит что весь балансируемый траффик транзитом проходит черер сам балансер в обе стороны.

Нагрузка какая? мх я так подозреваю не на гигосик покупался? линуксам плохо не станет гбит на сорок?

Одиночная продажа равна одиночному подключению. Абонплата тоже размазана по серьезной ежемесячной затратной части. 15М? Это только по квартире. И то должно быть акуратненько выложено вдоль плинтусов, через каждый метр скоба. Дальше еще +-50м кабеля до свитча. Или у вас по свитчу на каждую лестничную? Свитч тоже не копеечная мыльница. Абонент обычно подключается не в том-же доме где монтажники живут, им нужно куда-то ехать с перфораторами и бухтой кабла. Это как минимум бензин. И тд. И того разовые 200 грн от абона это вообще ни что. На одно построение узла этих разовых ушло куда больше. И ещ

Ну как же так? Время одного конкретного продавца ты ценишь золотом а время другого (нашего провайдера) вообще у тебя ни во что не уперлось. Стоимость расходников и оборудованя я вообще в данном ключе не учитываю.

У нас два разных Барвита Продавец который палец о палец не ударил взял аванс и не вернул значит прав на все 100, а тут затратив реально раз в 10 больше провайдер не прав. Браво!

У BARVIT увели аккаунт? Или это альтернативный BARVIT от того, который с пеной у рта защищал продавца в "черном списке"? Провайдер до дома оптику приводит, проект делает, дармоедам-жекам платит, в конце концов свитч покупает., технари работают, всё это монтируют, к абоненту тянут, дырки сверлят. И это куда больше этих разовых 200 грн. Кстати - тут тоже 200 грн

Хех, заполучить побольше генераторов валидного контента - розовая мечта всех IX. За таких клиентов целые войны идут (ну шли как минимум)

В областный центрах - около 14, в райнентрах - около 60. В среднем - 36.6

ipset это аналог нашего ipfw table что-ли? А вообще много вкусного имплементили в каррент в ipfw, тот же аналог отдельных правил на интерфейс, как во всяких кошках. Не слежу замтенденциями, мне и так уютно.

Паром уже не устраивает?

oops, "решили доставить" я прочитал как "доставили".

IPoE якраз і вирішує проблему з MTU що присутня в PPtP, PPPoE. Хто в вашій схемі може різати mtu? Там всюди по дефолту повинно пролізати 1500. Плеймаркет тут ні до чого, він чудово працює з дефолтовим 1500. Зарізаючи mtu забезпечте принаймі аналог ip tcp adjust-mss на своєму бордері.

Это понятно но по условиям задачи уже имеется пара мх80 и именно из нее надо соорудить максимально возможный failover

Неправда ваша У вас %Inconsistent address and mask

Опечатка в маске. ip route x.x.x.4 255.255.255.252 x.x.x.2 name Client

Давайте мух от котлет отделим. Под маршрутизацией подразумевается явно прописаное на провайдерском бордере что-то типа: ip route x.x.x.0 255.255.255.248 x.x.x.2 name Client В нашем же случае у провайдера сеть x.x.x.0/29 не маршрутизируется, так как она уже "терминирована, читай скомутировання" на wan интерфейсе. Так понятней или дальше будем продолжать этот бессмысленный диалог?

Здесь Перевожу: У _провайдера_ прописан наш wan как х.х.х.1/29, мы его у себя терминируем на eth0 как х.х.х.2/29 и шлюзом прописываем _провайдерский_ х.х.х.1. Т.е. никакой маршрутизации. Недоразумения исчерпаны?

То Вы пару тысяч организмов через прокси-арп при наличии оспф-а запускать не пробовали - шедевральный непередаваемый п@зд#ц. Безусловно подключение к апстриму с маской отличной от /30 есть зло. Я выходил из существующих реалий, не более.

Вы разницу между юникастом и бродкастом улавливаете? Если у Вас на машине IP _из бродкастовой сети гугла_ - ДА. Гду сказано что сеть на него _СМАРШРУТИЗИРОВАНА_?

Что как? Алгоритм работы маршрутизации в данной схеме подключения - выше. На FreeBSD у меня эта схемка катается много лет. Я так из дома в рабочую сеть попадаю, получая белый IP из /27 езернет сегмента по pptp. Что там еще у Вас докручено на линуксе я не знаю.

У провайдера 1.1.1.1/29, у клиента на BRAS (раз мы о PPPoE) 1.1.1.2/29. Клиент по ррр выдает 1.1.1.4. Из инета приходит пакет для 1.1.1.4. Поскольку этот адрес принадлежит бродкаст сегменту 1.1.1.0/29, провайдер шлет бродкаст запрос - who has 1.1.1.4 - ему нужен MAC устройства, на который этот пакет пробросить. Так вот при отсутствии на 1.1.1.2 proxy-arp этот 'who has' не получит ответа и пакет дропнется. Ежели на 1.1.1.2 будет включен proxy-arp, то этот 1.1.1.2 ответит на who has 1.1.1.4 своим MAC адресом (проксирует), получит пакет для 1.1.1.4 и перебросит его в ppp. Вуаля. Быстро, качествен