Мы видимо о разном, redistribute - это перераспределение маршрутов, стало быть и выбор каких маршрутов... есть connected, это те которые получены путем поднятия на интерфейсах самого маршрутизатора..есть еще куча других (BGP, OSPF) включая и Static.
Так вот представьте себе, подключился клиент по pppoe, ему выдало IP 1.1.1.1/32 (это Connected), а следом (в ответе Radius) приходит набор доп. роутинга, к примеру 2.2.2.0/24 -> 1.1.1.1/32. Этот маршрут появился и пропадет динамически в зависимости от состояния клиента, но с точки зрения таблицы маршрутизации он является "Per User Static" (U) И относится к Static маршрутам в таблице (S)... Адреса будут работать так же, представьте есть пул с динамическими /32 , есть пул со статическими /32 и есть пул с дополнительным адресами любых масок. Они анонсируются одинаково и составляют общий клиентский пул адресов и в BGP выглядят одинаково, так что и динамика между 7204 и MT как я полагаю обеспечена именно за счет этого. Я не имел ввиду, что что-то где-то прописываю сам руками для клиентов, статически.... Но без redistribute static .... в моем случае не будут роутиться доп. сети выданные клиентам... Естественно не все static нужны, по этому я четко описал исходящие префиксы их максимальную длину и все такое..
Наверное по тому, что это выбор каждого какие системы подключать какие нет?
[ Обновление ]
Появилась интересная возможность бесплатного хостинга с активацией за $1.00.
По факту если использовать тариф без нарушений получится хостинг за 1$ на год, два, три, и.т.п пока мы будем поддерживать данное предложение. Сразу поясню, явных ограничений (в плане функционала) у хостинга не будет, т.е будет полноценный акаунт со всеми функциями присущими виртуальному хостингу.
Никаких баннеров! Никакой рекламы!
Все отличия описаны на страницах нашего сайта.
Вы о чем сейчас ?:)
У меня есть PPPoE клиент который при коннекте получает /32, при этом есть клиенты, которые заказали себе >1 IP адреса и дополнительный блок выдается путем статической маршрутизации на основной IP /32 так же в момент авторизации путем ответа Radius в NAS....
Сама /32 считается direct (D), а вот выданные доп. адреса , это уже per user static (U) (подразделение Static (S), из документации понял так) и вместе с connected они не редистрибьютятся.
Наверное как и у хетзнера сервера по 20 Euro..... Дотации, которые вскоре превратятся в неоправданные расходы ;) Главное захват рынка :D
Zaqwr, к сожалению pppoe ISP будет отправлять нам клиентов round-robin схемой, по этому быстрее никто отвечать не будет, будут отвечать по очереди ;) Но это не самый интересный момент ;)))) Я в принципе уже разобрался как реализовать данную схему, сейчас ожидаю прибытие и коммутацию MT на месте, что бы проверить вторую часть балета, но с первого взгляда все должно быть нормально :D
Схема будет выглядеть так:
1. Между 4000 и Internet будет eBGP (оно в принципе уже есть)
2. Между 4000 и 7204 будет iBGP
3. Между 4000 и MT будет iBGP
4. 7204 И MT будут настроены на redistribute static & redistribute connected.
5. 4000 - будет отдавать по iBGP только default route.
Таким образом при подключении клиента на MT к примеру, после авторизации поднимется интерфейс, появится connected пользователь и он уйдет по iBGP в 4000.... стало быть там появится маршрут на правильный GW относительно схемы :)
Пока протестировал данную схему без MT :) Но думаю там будет нечто подобное :)
Ниже показываю полную схему с описаниями.
P.S: Еще под вопросом организация паритетного линка между 7204 и MT... им вроде как обмениваться ни чем не надо.... стало быть и особого смысла в линке этом нет?
Текущая схема включения, MT пока нет, но он будет завтра уже, шипим его в арию где он будет стоять :D
При этом все еще открыт вот этот вопрос
Поддерживаю систему с иерархией на основании md5.
В принципе особой разницы нет как делить фото, правильно замечено, главное что бы они в одну директорию все не попались, а так по 1-2-3 тысячи файлов на каталог - и думаю проблема будет решена.
Поймите одну штуку, A класс сетей это:
1я сеть 1.x.x.x
2я сеть 2.x.x.x
3я сеть 3.x.x.x
Их в мире всего 255..
Блоки класса "A" выдаются (они уже давно все розданы естественно) только RIR или мега крупным корпорациям типа Google, Xerox, Министерство обороны США... Часть этих сетей А класса зарезервирована в том числе под всем известные 127.0.0.0/8, 10.0.0.0/8... часть сетей А класса выдана в Multicast.... В общем точно считать не буду сейчас, но думаю что на мир ... остается штук 200... :) Вы хотите найти в России провайдера который предоставит на 1 сервер такое? Это НЕ ВОЗМОЖНО ... причем не только в России, а ни в какой другой точке мира....
Нет, конечно техническое задание: пригнать на сервер ИП адреса из 100 A классов - решаемо.....
Но я боюсь что стоимость такого решения обойдется в десятки тысяч долларов... Если вы готовы к таким бюджетам, можем обсудить :D---------- Добавлено 05.12.2013 в 09:23 ----------
Ага, мульены просто....
Получил забавный ответ, возможно дело в этом, но что "это" пока не понимаю.
Это пинг со стороны VM #1 в момент когда я со своей тачки "перестаю на время" пинговать хост:
(ответы от моего домашнего Border)
где:
x.x.x.x - мой домашний border
y.y.y.y - шлюз установленный на VM #1 (Фактически поднятный в Dom0)
z.z.z.z - вообще прикол, но это ИП шлюза в этом VLAN
Какая-то хрень вообще :D
Судя по всему да, пинговал с разных мест, связь пропадает одновременно. В обратную сторону (от VM) не пробовал, но думаю ввиду событий описанных выше думаю тоже самое.
