Zaqwr: это ещё зачем? не начинайте с плохого, не юзайте статики.
Вы о чем сейчас ?:)
У меня есть PPPoE клиент который при коннекте получает /32, при этом есть клиенты, которые заказали себе >1 IP адреса и дополнительный блок выдается путем статической маршрутизации на основной IP /32 так же в момент авторизации путем ответа Radius в NAS....
Сама /32 считается direct (D), а вот выданные доп. адреса , это уже per user static (U) (подразделение Static (S), из документации понял так) и вместе с connected они не редистрибьютятся.
sladkydze: Подскажите, каким образом у вас по SPLA такие цены на винду? 1. Ценник базовый на сервер стандарт 419 рублей. 2. Запрещается лицензировать Datacenter и продавать под ним в розницу.
Наверное как и у хетзнера сервера по 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... им вроде как обмениваться ни чем не надо.... стало быть и особого смысла в линке этом нет?
В принципе особой разницы нет как делить фото, правильно замечено, главное что бы они в одну директорию все не попались, а так по 1-2-3 тысячи файлов на каталог - и думаю проблема будет решена.
KrutE: Хостинги понятно что можно взять. Хотелось бы именно решение с сервером
Поймите одну штуку, 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 ----------
Hostnames: Да полно таких серверов, в гугле можешь поискать, тебе для каких целей ? И хотелось бы узнать какой бюджет?
pupseg: а в обратную сторону, со стороны VM на ваш хост, с которого вы пинговали VM до этого ?
Получил забавный ответ, возможно дело в этом, но что "это" пока не понимаю.
Это пинг со стороны VM #1 в момент когда я со своей тачки "перестаю на время" пинговать хост:
(ответы от моего домашнего Border)
64 bytes from x.x.x.x: icmp_seq=9 ttl=47 time=148 ms
64 bytes from x.x.x.x: icmp_seq=10 ttl=47 time=149 ms
From y.y.y.y: icmp_seq=11 Redirect Host(New nexthop: z.z.z.z)
64 bytes from x.x.x.x: icmp_seq=11 ttl=47 time=149 ms
64 bytes from x.x.x.x: icmp_seq=12 ttl=47 time=149 ms
где:
x.x.x.x - мой домашний border
y.y.y.y - шлюз установленный на VM #1 (Фактически поднятный в Dom0)
z.z.z.z - вообще прикол, но это ИП шлюза в этом VLAN
Какая-то хрень вообще :D
pupseg:
так же теряется ? проблема одинакова со всех узлов за пределами Dom0 и с VM до этих узлов?
Судя по всему да, пинговал с разных мест, связь пропадает одновременно. В обратную сторону (от VM) не пробовал, но думаю ввиду событий описанных выше думаю тоже самое.
iwant2beahoster: С одной стороны запустить ping с другой стороны послушать tcpdump. Может это что-то прояснит.
Брижди смотрел?
Говорю же, пропадает даже TCP... Но более детально сегодня еще раз буду проверять.....
Бриджи смотрел, думаю может STP выделывается, но там как-то тихо, стоимость путей вроде в норме, хотя я может че-то не так понимаю:
# brctl showstp xenintbr
xenintbr
bridge id 8000.feffffffffff
designated root 8000.feffffffffff
root port 0 path cost 0
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 0.00 bridge forward delay 0.00
ageing time 300.01
hello timer 0.81 tcn timer 0.00
topology change timer 0.00 gc timer 0.01
flags
vifvps40 (14)
port id 800e state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 800e forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
vifwolg0 (13)
port id 800d state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 800d forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
vifttre0 (12)
port id 800c state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 800c forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
viftnie1 (11)
port id 800b state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 800b forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
viftnie0 (10)
port id 800a state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 800a forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
viftnie3 (9)
port id 8009 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8009 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
viftnie4 (8)
port id 8008 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8008 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
viftnie2 (7)
port id 8007 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8007 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
vifsall0 (6)
port id 8006 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8006 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
vifsall1 (5)
port id 8005 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8005 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
vifchea0 (3)
port id 8003 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8003 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
peth2 (2)
port id 8002 state forwarding
designated root 8000.feffffffffff path cost 19
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
vif0.2 (1)
port id 8001 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
&
# brctl show
bridge name bridge id STP enabled interfaces
xenintbr 8000.feffffffffff no vifvps40
vifwolg0
vifttre0
viftnie1
viftnie0
viftnie3
viftnie4
viftnie2
vifsall0
vifsall1
vifchea0
peth2
vif0.2
Что еще посмотреть? Я все таки склонен к переполнению каких-то буферов и значений..... но при таком мизерном трафике даже не понимаю куда посмотреть бы.... ;(
---------- Добавлено 05.12.2013 в 08:10 ----------
Вот прямо сейчас повторяется аномалия, прикрепляю еще два скриншота, что бы было понятно о чем я:
Первый скрин - на нем пинг идет вроде бы нормально , но в один прекрасный момент почему-то 2k+ ms ответ и так иногда проскакивает.
Второй скрин, это положение дел в момент когда я пингую VM #1, при этом пинг на VM #2 идет вполне себе нормально... потом ситуация может поменяться, например на VM #1 идет нормально а на VM #2 пропал пинг.... и вот такая вот чехарда непонятная.....
В обе стороны в моменты лагов сегодня еще проверю....
pupseg: а в обратную сторону, со стороны VM на ваш хост, с которого вы пинговали VM до этого ?
так же теряется ? проблема одинакова со всех узлов за пределами Dom0 и с VM до этих узлов? у меня это было на хецнере как то....но грешу скорее на хецнер
В обратную сторону не пробовал, но думаю что нечто похожее, хотя как выясняется проблема весьма не стабильно себя ведет, например прямо сейчас отпинговал 3 VM машинки ... пинг замечательный - 0% loses, но в остальное время перегрузок каналов не обнаружено ни где....
seocore: возможно какой-то флажочек в ядре, что-то из разряда - net.ipv4.tcp_ecn и т.п.
Если можно чуть подробнее, буду весьма признателен. Я тоже почему-то смотрю в сторону настроек.... Хотя честно говоря чувствую , что машинка простаивает, т.е там нет напруги..... Был бы там средний трафик 90MB/s я бы все понимал, а так там в пики мегабит 5.... т.е явно какая-то бяка.
это ещё зачем? не начинайте с плохого, не юзайте статики.
Вы о чем сейчас ?:)
У меня есть PPPoE клиент который при коннекте получает /32, при этом есть клиенты, которые заказали себе >1 IP адреса и дополнительный блок выдается путем статической маршрутизации на основной IP /32 так же в момент авторизации путем ответа Radius в NAS....
Сама /32 считается direct (D), а вот выданные доп. адреса , это уже per user static (U) (подразделение Static (S), из документации понял так) и вместе с connected они не редистрибьютятся.
Подскажите, каким образом у вас по SPLA такие цены на винду?
1. Ценник базовый на сервер стандарт 419 рублей.
2. Запрещается лицензировать Datacenter и продавать под ним в розницу.
Наверное как и у хетзнера сервера по 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 на ваш хост, с которого вы пинговали VM до этого ?
Получил забавный ответ, возможно дело в этом, но что "это" пока не понимаю.
Это пинг со стороны VM #1 в момент когда я со своей тачки "перестаю на время" пинговать хост:
(ответы от моего домашнего Border)
64 bytes from x.x.x.x: icmp_seq=9 ttl=47 time=148 ms
64 bytes from x.x.x.x: icmp_seq=10 ttl=47 time=149 ms
From y.y.y.y: icmp_seq=11 Redirect Host(New nexthop: z.z.z.z)
64 bytes from x.x.x.x: icmp_seq=11 ttl=47 time=149 ms
64 bytes from x.x.x.x: icmp_seq=12 ttl=47 time=149 ms
где:
x.x.x.x - мой домашний border
y.y.y.y - шлюз установленный на VM #1 (Фактически поднятный в Dom0)
z.z.z.z - вообще прикол, но это ИП шлюза в этом VLAN
Какая-то хрень вообще :D
так же теряется ? проблема одинакова со всех узлов за пределами Dom0 и с VM до этих узлов?
Судя по всему да, пинговал с разных мест, связь пропадает одновременно. В обратную сторону (от VM) не пробовал, но думаю ввиду событий описанных выше думаю тоже самое.
С одной стороны запустить ping с другой стороны послушать tcpdump. Может это что-то прояснит.
Брижди смотрел?
Говорю же, пропадает даже TCP... Но более детально сегодня еще раз буду проверять.....
Бриджи смотрел, думаю может STP выделывается, но там как-то тихо, стоимость путей вроде в норме, хотя я может че-то не так понимаю:
# brctl showstp xenintbr
xenintbr
bridge id 8000.feffffffffff
designated root 8000.feffffffffff
root port 0 path cost 0
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 0.00 bridge forward delay 0.00
ageing time 300.01
hello timer 0.81 tcn timer 0.00
topology change timer 0.00 gc timer 0.01
flags
vifvps40 (14)
port id 800e state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 800e forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
vifwolg0 (13)
port id 800d state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 800d forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
vifttre0 (12)
port id 800c state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 800c forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
viftnie1 (11)
port id 800b state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 800b forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
viftnie0 (10)
port id 800a state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 800a forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
viftnie3 (9)
port id 8009 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8009 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
viftnie4 (8)
port id 8008 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8008 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
viftnie2 (7)
port id 8007 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8007 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
vifsall0 (6)
port id 8006 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8006 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
vifsall1 (5)
port id 8005 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8005 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
vifchea0 (3)
port id 8003 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8003 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
peth2 (2)
port id 8002 state forwarding
designated root 8000.feffffffffff path cost 19
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
vif0.2 (1)
port id 8001 state forwarding
designated root 8000.feffffffffff path cost 100
designated bridge 8000.feffffffffff message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
&
# brctl show
bridge name bridge id STP enabled interfaces
xenintbr 8000.feffffffffff no vifvps40
vifwolg0
vifttre0
viftnie1
viftnie0
viftnie3
viftnie4
viftnie2
vifsall0
vifsall1
vifchea0
peth2
vif0.2
Что еще посмотреть? Я все таки склонен к переполнению каких-то буферов и значений..... но при таком мизерном трафике даже не понимаю куда посмотреть бы.... ;(
---------- Добавлено 05.12.2013 в 08:10 ----------
Вот прямо сейчас повторяется аномалия, прикрепляю еще два скриншота, что бы было понятно о чем я:
Первый скрин - на нем пинг идет вроде бы нормально , но в один прекрасный момент почему-то 2k+ ms ответ и так иногда проскакивает.
Второй скрин, это положение дел в момент когда я пингую VM #1, при этом пинг на VM #2 идет вполне себе нормально... потом ситуация может поменяться, например на VM #1 идет нормально а на VM #2 пропал пинг.... и вот такая вот чехарда непонятная.....
В обе стороны в моменты лагов сегодня еще проверю....
а в обратную сторону, со стороны VM на ваш хост, с которого вы пинговали VM до этого ?
так же теряется ? проблема одинакова со всех узлов за пределами Dom0 и с VM до этих узлов? у меня это было на хецнере как то....но грешу скорее на хецнер
В обратную сторону не пробовал, но думаю что нечто похожее, хотя как выясняется проблема весьма не стабильно себя ведет, например прямо сейчас отпинговал 3 VM машинки ... пинг замечательный - 0% loses, но в остальное время перегрузок каналов не обнаружено ни где....
Прикрепляю смешной граф нагрузки на свич-порт. ;(
возможно какой-то флажочек в ядре, что-то из разряда - net.ipv4.tcp_ecn и т.п.
Если можно чуть подробнее, буду весьма признателен. Я тоже почему-то смотрю в сторону настроек.... Хотя честно говоря чувствую , что машинка простаивает, т.е там нет напруги..... Был бы там средний трафик 90MB/s я бы все понимал, а так там в пики мегабит 5.... т.е явно какая-то бяка.