[Abram]

Под Windows XP все это проходит незаметно для клиента.

Под Windows 7 - попытка подключения висит секунд 10, потом уже выдает ошибко. Не комильфо, однако.

 

Предпочитаю попытаться разобраться, возможно ли привести поведение семерки к аналогичному в ХП.

Пишите МС, пусть разбираются.

Они не будут. Им похер.

[Ivan_83]

Они так и ответили?

[samodelkin]

Они так и ответили?

Аха, мне тоже интересно.

Напишу сегодня, через представителей, у кого покупаем софт.

[Abram]

Они так и ответили?

Нет, но это очевидно.

[Ivan_83]

Нет, но это очевидно.

Мне совсем не очевидно.

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

Если писать очень конкретно и на инглише то реагируют.

В данном случае проблема где то в RAS.

Это достаточно автономная подсистема, и вроде не сильно костыльная/не плохо спроектированная, потому есть шанс что быстро найдут.

 

 

PS: похоже вы опоздали: сегодня выкатили очень много патчей, похоже готовятся закрывать год/к праздникам.

[Abram]

Нет, но это очевидно.

Мне совсем не очевидно.

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

Если писать очень конкретно и на инглише то реагируют.

В данном случае проблема где то в RAS.

Это достаточно автономная подсистема, и вроде не сильно костыльная/не плохо спроектированная, потому есть шанс что быстро найдут.

 

 

PS: похоже вы опоздали: сегодня выкатили очень много патчей, похоже готовятся закрывать год/к праздникам.

А сфигли они будут меня слушать, если у меня нет софта от M$? :) (Реально нет, ворованного тоже. Просто изначально все в офисе сделал на линухах)

[ivan999]

Прочитал я это все. Но есть вопрос.

 

Дано: есть необходимость использовать несколько NASов.

Допустим у меня 2 , 3 или больше NAS серверов (MikroTik) - одинаковых по производительности.

Вполне меня устроил бы вариант с одним доменным именем для всех NASов и "рандомное" распределение клиентов при помощи DNS.

А теперь скажите мне - если у меня на NAS не юзается NAT - как мне настроить маршрутизацию на бордере (в который воткнуты все NASы), если юзеры получают белые адреса для pptp из пула средствами радиус с биллинга.

Нужно же четко прописать на бордере - какую подсеть белых адресов завернуть назад на какой NAS.

 

А так у меня получается, например: юзер1 подрубился на первый NAS1 - получил белый адрес 9.9.9.9. Я должен указать маршрут на бордере - этот адрес (эта подсеть) - гнать пакеты на NAS1.

 

В следующий раз этот же юзер1 втыкается по теории вероятности : ))) на NAS2, получает белый адрес 9.9.9.9, но маршрут то на бордере указывает на NAS1.....

И в добавок в этот момент юзер2 коннектиться на NAS1 и получает адрес из этой же подсети (пула), 9.9.9.8, что и юзер1 на другом NAS

 

Пока есть такие мысли: не можем настроить маршрутизацию на бордере в данном случае - юзаем коммутацию, прописываем IP адреса фейсам NASов, которые смотрят на бордер - из той же подсети, что и юзеры получают для VPN. Может также нужно в данном случае читать про proxyARP и/или bridge.

Допустим , эта схема прокатит. Но это если пул один. А если много "рваных" не смежных белых пулов есть - как то все усложняется....

И надо проверять - не усложниться ли в этом случае настройка Tree Queue и прочих фишек....

 

Кто как делает при таких условиях?

Какие есть варианты в данном случае?

Изменено 18 декабря, 2010 пользователем ivan999

[Valaskor]

слинковать насы с бордером по ospf или bgp

на насе пишем в конфиг что то вроде:

redistribute connected route-map USERS

в роутмапе USERS соответственно разрешаем /32-маршруты на пользовательские зоны.

можно еще вообще без динамической маршрутизации - включить на насах arp-proxy. Он будет отвечать бордеру по арп так, как будто юзер включен прямо в подсеть, а не через nas.

[ivan999]

Я тоже думал про динамическую маршрутизацию, но все же проще (как бы : ) ) - Proxy ARP.

 

Кто знает - как на Микротиках конкретно это делать, а то там ProxyARP упоминается в нескольких "местах".

И нужно ли трогать настройки "bridge" (и тоже в разных местах - глобально, в фаере, в профиле ppp и еще вроде где-то)?

[AlKov]

А теперь скажите мне - если у меня на NAS не юзается NAT - как мне настроить маршрутизацию на бордере (в который воткнуты все NASы), если юзеры получают белые адреса для pptp из пула средствами радиус с биллинга.

Нужно же четко прописать на бордере - какую подсеть белых адресов завернуть назад на какой NAS.

NAT здесь совсем не при делах, хотя у меня он есть на бордере.

Решаю подобную задачу с помощью RIP из пакета quagga. Никаких проблем и никаких заморочек с подсетями. NAS-ы "сообщают" бордеру роут на конкретный IP (/32).

NAS-ы на FreeBSD (mpd), бордер на CentOS. Если ваши MicroTik-и умеют RIP, то все решается "на раз-два".

 

P.S. NAS-ов у меня пока два, но знаю что у коллег работает по такой схеме аж 5 шт. Все жужжит аки пчёл. :)

Изменено 18 декабря, 2010 пользователем AlKov

[ivan999]

>NAT здесь совсем не при делах, хотя у меня он есть на бордере.

Речь идет о NAT не на бордере, а на NASах - если NAT на NAs - то никаких заморочек с маршрутизацией вообще нет - просто статически роуты прописываешь и все (потому что мы четко знаем на каждом NAS - адрес (адреса) ) для натирования юзеров ....

[Valaskor]

Я тоже думал про динамическую маршрутизацию, но все же проще (как бы : ) ) - Proxy ARP.

 

Кто знает - как на Микротиках конкретно это делать, а то там ProxyARP упоминается в нескольких "местах".

И нужно ли трогать настройки "bridge" (и тоже в разных местах - глобально, в фаере, в профиле ppp и еще вроде где-то)?

Если не ошибаюсь, просто поставить галочку arp-proxy в настройках интерфейса, смотрящего в сторону бордера.

Но я бы лучше все таки сделал динамику. Не знаю как будет работать бордер с тысячами записей в арп-таблице. А вот с сотнями тысяч записей в таблице маршрутов оно работает спокойно.

[ivan999]

Я понял суть с анонсированием маршрутов /32 , и что можно реализовать с помощью любого протокола динамической маршрутизации. (Микротик поддерживате RIP, OSPF. BGP).

Но, вроде как с proxyARP - еще проще - на бордере тогда вообще ничего не надо настраивать. Осталось только выяснить - какие могут быть нюансы, недостатки при использовании ARP Proxy ?

[AlKov]

>NAT здесь совсем не при делах, хотя у меня он есть на бордере.

Речь идет о NAT не на бордере, а на NASах - если NAT на NAs - то никаких заморочек с маршрутизацией вообще нет - просто статически роуты прописываешь и все (потому что мы четко знаем на каждом NAS - адрес (адреса) ) для натирования юзеров ....

Ничего не понимаю.. Зачем Вам NAT если

юзеры получают белые адреса для pptp из пула средствами радиус с биллинга.

?????

И еще раз - причём здесь NAT вообще??! Какая разница будет он, или нет, и где он будет/не будет?

Вам же всего лишь нужно элементарно "сказать" роутеру, куда (на какой NAS) отправлять трафик для IP XXX.XXX.XXX.XXX/32. И не надо ничего ни к чему (юзеров к IP, подсети к NAS-ам) прикручивать статикой.

 

[ivan999]

>NAT здесь совсем не при делах, хотя у меня он есть на бордере.

Речь идет о NAT не на бордере, а на NASах - если NAT на NAs - то никаких заморочек с маршрутизацией вообще нет - просто статически роуты прописываешь и все (потому что мы четко знаем на каждом NAS - адрес (адреса) ) для натирования юзеров ....

Ничего не понимаю.. Зачем Вам NAT если

юзеры получают белые адреса для pptp из пула средствами радиус с биллинга.

?????

И еще раз - причём здесь NAT вообще??! Какая разница будет он, или нет, и где он будет/не будет?

Вам же всего лишь нужно элементарно "сказать" роутеру, куда (на какой NAS) отправлять трафик для IP XXX.XXX.XXX.XXX/32. И не надо ничего ни к чему (юзеров к IP, подсети к NAS-ам) прикручивать статикой.

давайте не будем путать народ - я как раз сказал в первом посте - что у меня нет NAT. А сказал я это потому, что если бы он был (именно на NASах)- можно было бы не настраивать динамическую маршрутизацию, а вручную статикой прописать роуты на адреса, которые были бы на NAS для "натирования" юзеров.

Изменено 18 декабря, 2010 пользователем ivan999

[Abram]

Решаю подобную задачу с помощью RIP из пакета quagga.

aka Rest In Peace?

Недальновидно.

[ivan999]

почему недальновидно - аргументируйте

[Abram]

почему недальновидно - аргументируйте

Потому что Rest In Peace. Не надо воскрешать мертвых.

[martin74]

Но тем не менее - RIP - самый нересурсоемкий протокол маршрутизации. Минимум настроек. Зачем сюда прикручивать BGP сессии, OSPF арии с пересчетом после каждого коннекта?

[ivan999]

тоже аргумент

[AlKov]

Решаю подобную задачу с помощью RIP из пакета quagga.

aka Rest In Peace?

Недальновидно.

Ага! Т.е. уж если бабахать, то только из пушки по воробьям и никак иначе! ;)

Ну-ну..

[Abram]

Но тем не менее - RIP - самый нересурсоемкий протокол маршрутизации. Минимум настроек. Зачем сюда прикручивать BGP сессии, OSPF арии с пересчетом после каждого коннекта?

Тогда сделайте себе Arp Proxy - и вообще можно всем этим не страдать ;).

 

Решаю подобную задачу с помощью RIP из пакета quagga.

aka Rest In Peace?

Недальновидно.

Ага! Т.е. уж если бабахать, то только из пушки по воробьям и никак иначе! ;)

Ну-ну..

Предпочитаю OSPF с несколькими area. 0.0.0.0 aka backbone для локалки и вторая - NAS-NAS-border.

[AlKov]

Но тем не менее - RIP - самый нересурсоемкий протокол маршрутизации. Минимум настроек. Зачем сюда прикручивать BGP сессии, OSPF арии с пересчетом после каждого коннекта?

Тогда сделайте себе Arp Proxy - и вообще можно всем этим не страдать ;).

Хорошо. А что Вы можете сказать вот про это

...skip.. Не знаю как будет работать бордер с тысячами записей в арп-таблице. А вот с сотнями тысяч записей в таблице маршрутов оно работает спокойно.

И вообще, в чём конкретно преимущество Arp Proxy перед RIP в контексте решения этой задачи??

Только в том, что RIP устарел? Но ведь как известно, "старый конь борозды не портит", а "пахать глубоко" ему как раз и не нужно в данном случае :)

[ivan999]

да, тут ПроксиАРП еще под вопросом - нужно, чтобы кто-то отписался, как оно себя буит вести при нескольких тысячах юзеров онлайн - получиться на бордере очень много ARP записей.

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

[Abram]

Но тем не менее - RIP - самый нересурсоемкий протокол маршрутизации. Минимум настроек. Зачем сюда прикручивать BGP сессии, OSPF арии с пересчетом после каждого коннекта?

Тогда сделайте себе Arp Proxy - и вообще можно всем этим не страдать ;).

Хорошо. А что Вы можете сказать вот про это

...skip.. Не знаю как будет работать бордер с тысячами записей в арп-таблице. А вот с сотнями тысяч записей в таблице маршрутов оно работает спокойно.

Бордер кто?

Писюк? Тогда ему пофигу.

Железка? Тогда сеть уже, видимо, разрослась и внутри сети точно есть OSPF. =)

И вообще, в чём конкретно преимущество Arp Proxy перед RIP в контексте решения этой задачи??

Только в том, что RIP устарел? Но ведь как известно, "старый конь борозды не портит", а "пахать глубоко" ему как раз и не нужно в данном случае :)

Кому не портит, а кому сдох и воняет ;).

Цитата из выдачи гугла на вопрос RIP disadvantages:

Because itЃfs a distance vector system, when revising the network etc., it takes time for convergence

 

With default configuration, each router broadcasts out all the routing information it has to neighboring routers once every 30 seconds

 

ThereЃfs lots of routing information traffic

 

Nodes that arenЃft participating in ‚q‚h‚o also have to process non-relevant information, resulting in waste

Ну и http://docs.hp.com/en/B2355-90110/ch09s01.html#fb38807 туда же.

 

да, тут ПроксиАРП еще под вопросом - нужно, чтобы кто-то отписался, как оно себя буит вести при нескольких тысячах юзеров онлайн - получиться на бордере очень много ARP записей.

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

Proxy ARP - это была шутка. Не вижу смысла применять его более чем на 20-50 юзерах.

Изменено 21 декабря, 2010 пользователем Abram