[Diamont]

Падо пакет на свиче доступа убивать на всех портах кроме аплинкового?

True.

Или проще таки сделать сегментацию трафика при л2 сети, а при пппое она таки будет л2.

False.

[NiTr0]

Всё левое блокируется на доступе. Вланы и сегментация при этом не нужны.

На неуправляемой мыльнице, как рекомендует Сааб? :)

[Saab95]

Угу. Уворовал пароль у соседа - и фиг кто найдет виновника... Помойка же :)

 

Пусть сворует, только сосед быстро с ним разберется. Т.к. в доме всего 2-5 абонента.

 

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

 

Опять же пусть поднимает, про ситуацию с соседом уже писал.

 

Зачем вланы? Хотя можно и их в общем-то.

Я вас спрашивал - нахрена вам пппое на станции поднимать, если станция и так однозначно идентифицируется по ее маку?

И нахрена городить поверх этого EoIP, в который засовывать PPPoE, если хватит станции в режиме бриджа, которая соединена с нормальным свичом с опцией 82?

 

PPPoE поднимается для авторизации абонентов и доступа в интернет.

Если нужно предоставить L2 канал, то поверх PPPoE по этим адресам поднимается EoIP туннель, при этом ничего на сети менять не нужно.

Если абоненту нужна подсеть белых адресов, то она анонсится через OSPF, который работает поверх PPPoE.

 

Где вы тут увидели извраты?

 

И нахрена городить поверх этого EoIP, в который засовывать PPPoE

Это для всех загадка...

 

Я уже писал что это для тех, кому нужен L2 туннель.

 

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

 

Он не будет сорить в туннель. И попадать на антенну не надо, если нужно абонента заблокировать - достаточно скинуть с сервера и заблокировать учетку, больше он ничего передать в сеть со своей антенны не сможет. Если вы сделаете влан на БС, то заблокировав этот влан на ней, сама CPE абонента продолжит передавать данные в радио и будет занимать ресурс, соответственно вам нужно будет зайти на нее и погасить. Сбросить с БС вы сможете, но вот заблокировать по маку без сброса всех остальных абонентов не сможете.

 

А про автоматизацию мы ничего не слышали? Сменить свитч\бс в профайле абона к которой подключен абон и автоматом влан прокинется, делается один раз и не надо потом тратить много времени как вы себе представляете.

 

Опять свичи? У вас сеть кабельная и основной вид предоставляемой услуги подключение абонентов витухой с порта коммутатора? Представьте есть и другие виды сетей, где основной вид предоставляемой услуги подключение абонентов по радио а по кабелю чисто побочный продукт.

 

Всё левое блокируется на доступе. Вланы и сегментация при этом не нужны.

На неуправляемой мыльнице, как рекомендует Сааб? :)

 

Блокируется трафик в центр всего кроме PPPoE. Походу вы читать просто не умеете и понимание от вашего понимания не понимаете.

 

Представьте есть дом в поселке 2 этажа 2 подъезда, в каждом 3 или 4 квартиры. В этом доме подключается один абонент и пользуется сетью, антенна настроена в виде PPPoE клиента. Теперь там появляется второй абонент, на антенне создается EoIP туннель в центр и подключается к PPPoE, после чего устанавливается тупой хаб и к нему подключаются абоненты. Тупой хаб ставится по той причине, что за лето там постоянно все выгорает по несколько раз, и никакая грозозащита не помогает.

[Sergeylo]

PPPoE поднимается для авторизации абонентов и доступа в интернет.

Если нужно предоставить L2 канал, то поверх PPPoE по этим адресам поднимается EoIP туннель, при этом ничего на сети менять не нужно.

Если абоненту нужна подсеть белых адресов, то она анонсится через OSPF, который работает поверх PPPoE.

 

Где вы тут увидели извраты?

Ну вот лично я вижу изврат в чрезмерном задействовании pppoe там, где он не нужен в принципе. Ладно, с этим, вероятно, можно жить.

На вашу лесенку из mtu посмотреть можно? Вот что действительно любопытно.

Пусть сворует, только сосед быстро с ним разберется. Т.к. в доме всего 2-5 абонента.

Похоже на шутку, но не шутка, да?

Port Isolation есть почти везде, и от таких глупостей избавляет полностью.

[Ivan_83]

Пусть сворует, только сосед быстро с ним разберется. Т.к. в доме всего 2-5 абонента.

Зачем нужен провайдер который создаёт проблемы с соседями?

 

Где вы тут увидели извраты?

Действительно, трудно объяснить жителю Садомы в чём он не прав.

[Diamont]

На неуправляемой мыльнице, как рекомендует Сааб?

Покажи, где он такое советовал.

[pppoetest]

Пусть сворует, только сосед быстро с ним разберется. Т.к. в доме всего 2-5 абонента.

Что делать если в доме подключено овер 60 абонов? У нас есть и такие.

[pppoetest]

На неуправляемой мыльнице, как рекомендует Сааб?

Покажи, где он такое советовал.

На начальном этапе можно дешевых свичей понаставить за 300р, никто их ложить мусором не будет, т.к. на каждом будет 2-10 клиентов максимум. Как наберете большую базу будете думать переходить или нет.

[Sonne]

Главное преимущество PPPOE в радио - это его отличное управление IP пространством. В микротиковской реализации достаточно включить редистрибуцию статических адресов и хостроуты типа /32 прекрасно маршрутизируются по сети. В биллинге достаточно настроить один пул и выдавать адреса кому угодно, где угодно! Так же в радиосети можно включить изолцицию трафика клиентов и все проблемы с фейковыми PPPOE серверами исчезают.

 

Проблема в том что многие админы крупных сетей в силу своей узкой специализации не понимают отличие радиосетей от кабельных.

 

В кабельных сетях схемы с VLAN, DHCP безусловно лучше, особенно когда есть возможность собирать толстые пучки на мощные железки и заворачивать в Q-in-Q.

 

Для радиосети есть одно единственное вечное правило - только L3! Если даже делается L2, то желательно его на базовой станции быстро перевести в L3. В очень крупной радиосети состоящей из сотен базовых станций и тысяч абонентов каналы связи часто ненадежны. Используются и кольца и деревья и множественные линки. L2 в такой конфигурации тупо не работает by design. Вот и весь сказ.

 

Зачетный вывод у человека: http://forum.nag.ru/forum/index.php?showtopic=96994&view=findpost&p=1020184

[Sonne]

А вот я вопрос задам.

 

Есть необходимость мигрировать специфическую сеть с L3 на L2. Была чудо железка в центре, на ней пул адресов вида 172.16.0.0/18 поддерживала несколько тысяч туннелей внутри которых маршруты /32. Управлялась всем что можно через Радиус сервер. Железка достигла потолка, с производства снята, сделать ничего нельзя.

 

Единственная возможность переключить базы в L2. На базах худо-медно можно настроить аутентификацию по логину-паролю. Но вот остальное должен делать некий NAS или BRAS, а именно

 

1. Выдавать DHCP

2. Выдавать /32 адрес на CPE клиента.

3. Шейпить адрес клиента.

4. Маршрутизировать /32 выше через ядро.

 

Задача решается идеально с PPPOE, но к сожалению наши специфические CPE не поддерживают PPOE.

 

Наверно первое предложение будет - разбить 172.16.0.0/18 на 172.16.0.0/24, 172.16.1.0/24 и т.д. Затем выдать на каждую базу по подcети и выдавать IP. Так вот, нужно обеспечить совместимость с первоначальной схемой на время перевода, это значит что единственно возможный тип маршрутизации - хоcты /32, в то время как агрегат будет по прежнему направлен на старый NAS.

 

Хочу посмотреть как это можно сделать без PPPOE, годятся любые костыли - сколько угодно микротиков на базы и может быть один BRAS/Cisco ISG в центре.

 

Ваши предложения господа?

[Ivan_83]

Главное преимущество PPPOE в радио - это его отличное управление IP пространством.

Поднимаешь ДХЦП сервер на моём перловом скрипте или на фрирадиусе, настраиваешь логику как тебе нужно и всё.

[NiTr0]

Пусть сворует, только сосед быстро с ним разберется. Т.к. в доме всего 2-5 абонента.

Сосед сначала будет капать на моск вашей поддержке (ибо это не его проблема, что недопровайдер не может обеспечить ему доступ), а потом - тупо свалит к конкуренту при малейшей возможности. И будет прав.

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

 

PPPoE поднимается для авторизации абонентов и доступа в интернет.

Если нужно предоставить L2 канал, то поверх PPPoE по этим адресам поднимается EoIP туннель, при этом ничего на сети менять не нужно.

Если абоненту нужна подсеть белых адресов, то она анонсится через OSPF, который работает поверх PPPoE.

Да-да, а если на доме 4-5 абонов - у вас поднимается PPPoE, поверх которого EoIP, поверх которого PPPoE...

 

Покажи, где он такое советовал.

В многоквартирных домах где подключены 2-5 человек стоит не управляемый хаб

 

1. Выдавать DHCP

2. Выдавать /32 адрес на CPE клиента.

3. Шейпить адрес клиента.

4. Маршрутизировать /32 выше через ядро.

 

Задача решается идеально с PPPOE, но к сожалению наши специфические CPE не поддерживают PPOE.

1) выдавать дхцп лизу с маской /24 (или сколько там), первые N адресов зарезервировать на брас/брасы (их можно поставить и параллельно к слову), анонсить маршрут /32 через брас и на брасе его добавлять на нужный ифейс

2) настроить isolation на точках доступа, сегментацию трафика на свичах (а лучше - влан на ТД) и proxy arp на брасах

3) CPE в вашей зоне ответственности как я понял - т.е. можно доверять их макам, и авторизировать клиента по маку (если CPE в режиме роутера, если бридж - несколько хуже с т.з. управляемости сего бардака)

 

accel-ppp в качестве браса вроде как должен уметь п.1 в полной мере (с shared режимом пока не особо экспериментировал), может получать адреса как из радиуса, так и от дхцп сервера...

[Saab95]

Ну вот лично я вижу изврат в чрезмерном задействовании pppoe там, где он не нужен в принципе. Ладно, с этим, вероятно, можно жить.

На вашу лесенку из mtu посмотреть можно? Вот что действительно любопытно.

 

MTU в данном контексте не имеет никакого значения, т.к. проходят пакеты размером 1500 байт без проблем, если нужно скрыть от абонента, легко делается через MRRU, в EoIP MTU вообще 65535.

 

Что делать если в доме подключено овер 60 абонов? У нас есть и такие.

 

Тогда ставить нормальное оборудование. Вы видели тупые хабы на 60 портов?

 

На начальном этапе можно дешевых свичей понаставить за 300р, никто их ложить мусором не будет, т.к. на каждом будет 2-10 клиентов максимум. Как наберете большую базу будете думать переходить или нет.

 

Так на начальном этапе же четко написано - то есть подключили несколько абонентов а дальше смотрите.

 

Есть необходимость мигрировать специфическую сеть с L3 на L2. Была чудо железка в центре, на ней пул адресов вида 172.16.0.0/18 поддерживала несколько тысяч туннелей внутри которых маршруты /32. Управлялась всем что можно через Радиус сервер. Железка достигла потолка, с производства снята, сделать ничего нельзя.

 

Единственная возможность переключить базы в L2. На базах худо-медно можно настроить аутентификацию по логину-паролю. Но вот остальное должен делать некий NAS или BRAS, а именно

 

1. Выдавать DHCP

2. Выдавать /32 адрес на CPE клиента.

3. Шейпить адрес клиента.

4. Маршрутизировать /32 выше через ядро.

 

Наверно первое предложение будет - разбить 172.16.0.0/18 на 172.16.0.0/24, 172.16.1.0/24 и т.д. Затем выдать на каждую базу по подcети и выдавать IP. Так вот, нужно обеспечить совместимость с первоначальной схемой на время перевода, это значит что единственно возможный тип маршрутизации - хоcты /32, в то время как агрегат будет по прежнему направлен на старый NAS.

 

Вам не надо ничего бить, вешаете везде сеть 172.16.0.0/18, включаете прокси арп и раздаете адреса по DHCP с маской /18, прописав на интерфейс сеть абонента по типу /ip address add address=172.16.0.1/18 network=172.16.0.2 и так далее, соответственно эти адреса поштучно анонсируются через OSPF. А дальше отшейпить уже без проблем сможете.

[pppoetest]

Тогда ставить нормальное оборудование. Вы видели тупые хабы на 60 портов?

Удивлен, что не предложил поставить с десяток тупых мыльниц )))

Так на начальном этапе же четко написано - то есть подключили несколько абонентов а дальше смотрите.

Какая нахер разница, 1 абон или 10. Или сразу ставить управляшки или не лезть в сетестроительство вообще.

[Sonne]

Главное преимущество PPPOE в радио - это его отличное управление IP пространством.

Поднимаешь ДХЦП сервер на моём перловом скрипте или на фрирадиусе, настраиваешь логику как тебе нужно и всё.

 

Как DHCP сервер может решить вопрос с маршрутизацие хостроутов?

[Sonne]

Пусть сворует, только сосед быстро с ним разберется. Т.к. в доме всего 2-5 абонента.

Сосед сначала будет капать на моск вашей поддержке (ибо это не его проблема, что недопровайдер не может обеспечить ему доступ), а потом - тупо свалит к конкуренту при малейшей возможности. И будет прав.

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

 

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

 

1. Выдавать DHCP

2. Выдавать /32 адрес на CPE клиента.

3. Шейпить адрес клиента.

4. Маршрутизировать /32 выше через ядро.

 

Задача решается идеально с PPPOE, но к сожалению наши специфические CPE не поддерживают PPOE.

1) выдавать дхцп лизу с маской /24 (или сколько там), первые N адресов зарезервировать на брас/брасы (их можно поставить и параллельно к слову), анонсить маршрут /32 через брас и на брасе его добавлять на нужный ифейс

2) настроить isolation на точках доступа, сегментацию трафика на свичах (а лучше - влан на ТД) и proxy arp на брасах

3) CPE в вашей зоне ответственности как я понял - т.е. можно доверять их макам, и авторизировать клиента по маку (если CPE в режиме роутера, если бридж - несколько хуже с т.з. управляемости сего бардака)

 

accel-ppp в качестве браса вроде как должен уметь п.1 в полной мере (с shared режимом пока не особо экспериментировал), может получать адреса как из радиуса, так и от дхцп сервера...

 

1) Невозможно изменить пул, т.к. клиенты раскиданы по сети произвольно.

2) Никаких VLAN в радио сети. Либо Eheret over IP туннели, либо локальные брасы.

3) По маку можно, да в данном случае это единственный вариант. Только потребуется полная переделка биллинга который хаточен на логин/пароль.

 

Иными словами, то что PPPOE умеет делать искаробки на железке стоимостью 50$, предлагается попробовать на непонятной левой софтине.

 

Можно увидеть надежное стабильное решение на нормальном вендоре? Если не микротике то на циске на крайний случай?

[Sonne]

Вам не надо ничего бить, вешаете везде сеть 172.16.0.0/18, включаете прокси арп и раздаете адреса по DHCP с маской /18, прописав на интерфейс сеть абонента по типу /ip address add address=172.16.0.1/18 network=172.16.0.2 и так далее, соответственно эти адреса поштучно анонсируются через OSPF[. А дальше отшейпить уже без проблем сможете.

 

/ip address add address=172.16.0.1/18 network=172.16.0.2

Это можно выдать через радиус? Или вы предлагаете прописывать вручную?

[Saab95]

/ip address add address=172.16.0.1/18 network=172.16.0.2

Это можно выдать через радиус? Или вы предлагаете прописывать вручную?

 

В 6 версии ПО у DHCP сервера появились поля для выполнения скриптов в момент выдачи и забриания адресов, вот они:

 

Script that will be executed after lease is assigned or deassigned. Internal "global" variables that can be used in the script:

leaseBound - set to "1" if bound, otherwise set to "0"

leaseServerName - dhcp server name

leaseActMAC - active mac address

leaseActIP - active IP address

 

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

[Sonne]

Saab я видел это поле. В Winboxе это называется lease script, т.е. он срабатывает при назначении IP. Как он будет убирать при отключении - скриптом проверять перменную leaseBound?

 

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

 

Попробовать однако стоит. Есть ли где то примеры у людей или как всегда малоиспользумая и непонятная фича будет глючить со страшной силой?

[Saab95]

Saab я видел это поле. В Winboxе это называется lease script, т.е. он срабатывает при назначении IP. Как он будет убирать при отключении - скриптом проверять перменную leaseBound?

 

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

 

Попробовать однако стоит. Есть ли где то примеры у людей или как всегда малоиспользумая и непонятная фича будет глючить со страшной силой?

 

В поле выдачи указываете команду на добавления адреса, в поле забирания адреса указываете команду на удаления с использованием find network, тогда при окончании срока аренды адрес автоматически удалится. Если поставить время аренды 5 минут, то не должно быть особых проблем при переходе на другую БС, максимум это перерыв связи возникнет, т.к. на старом устройстве этот адрес еще не удалился.

 

NAS может стоять в центре, с каждой базы пробросите вланы или EoIP туннели в центр. Но это уже как удобнее. Кроме всего можно собирать логи со всех устройств, и при выдаче по DHCP адреса, который уже где-то прописан, просто удалять его, подключившись по SSH.

[NiTr0]

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

Смотря где и как. Если это фиксированный доступ, но по радио вместо проводов - то подключение "везде" не нужно.

 

1) Невозможно изменить пул, т.к. клиенты раскиданы по сети произвольно.

2) Никаких VLAN в радио сети. Либо Eheret over IP туннели, либо локальные брасы.

3) По маку можно, да в данном случае это единственный вариант. Только потребуется полная переделка биллинга который хаточен на логин/пароль.

 

1) А никто и не говорит о смене пула. Один пул. Клиенту выбается подсеть на весь пул. На брасе - маршрут /32 на клиента и прокси арп.

2) У вас что, до точек доступа тоже радио прокинуто?

3) Какой на л2 может быть логин-пароль? Не, можно конечно чиллиспот какой-то поставить или проприетарный хотспот, но за такое - прову по рукам давать надо. Хотя вернее если отдельный логин для доступа к услуге - можно его юзать, из мака сымитировать (хотя для qinq оно кошернее было бы - но это не про радио), но все же.

 

Можно увидеть надежное стабильное решение на нормальном вендоре? Если не микротике то на циске на крайний случай?

Cisco ISG... На микротике IPoE нормального нет и навряд появится, сплошь костыли и костылики, прописывание маршрутов вручную/нескучными костыликами из скриптов и т.п., при этом ребут микротика с кучей прописанных таким образом роутов легко может поставить сеть враскоряку - ибо маршруты при добавлении автоматом попадают в конфиг, а лизы - скорее всего нет...

[Sonne]

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

Смотря где и как. Если это фиксированный доступ, но по радио вместо проводов - то подключение "везде" не нужно.

 

Даже если доступ фиксированный. Едет монтажник к клиенту и не знает на какой из трех ближайших баз будет оптимальный сигнал. Одну сторону закрывает дерево, другая база перегружена и там не разрешен тариф и т.д. И все это в воскресенье вечером, когда главный админ еще не проснулся. Авторизация от абоненета, а не порта - это суровая необходимость, а не глупая прихоть.

 

1) А никто и не говорит о смене пула. Один пул. Клиенту выбается подсеть на весь пул. На брасе - маршрут /32 на клиента и прокси арп.

 

Давайте конкретно. Каждому клиенту выдается сейчас адрес из пула 172.16.0.0/18. На одной базе может оказаться клентс адресом 172.16.0.10 и 172.16.7.10. Маска /18. Какая подсеть по вашему должна стоять в этом случае на интерефейсе NAS? Если вы правильно ответите на этот вопрос, то спрашиваю следующий - откуда на брасе возникнет /32?

 

2) У вас что, до точек доступа тоже радио прокинуто?

 

Конечно, в том реальном мире в котором живут радиооператоры подключение баз выполняется всеми мысленными способами. Часто VLAN непозволительная роскошь, еще чаще кольцо из 2-3 UBNT/Mikrotik единсвенный способ дать надежну связь. Нормальное резервирование при этом работает исключительно на L3 с использованием OSPF.

 

3) Какой на л2 может быть логин-пароль? Не, можно конечно чиллиспот какой-то поставить или проприетарный хотспот, но за такое - прову по рукам давать надо. Хотя вернее если отдельный логин для доступа к услуге - можно его юзать, из мака сымитировать (хотя для qinq оно кошернее было бы - но это не про радио), но все же.

 

Логин-пароль это основной способ аутентификации WIMAX, который прекрасно работает на L3 c туннелями. Скажем так это тяжелое наследие легаси системы, которое является дополнительным отягчающим обстоятельством. Заметьте и в PPPOE и в WIMAX это прекрасно работает. И лишь для схемы с DHCP это неверотяно сложно применить. Это к теме топика DHCP vs PPPOE.

 

Можно увидеть надежное стабильное решение на нормальном вендоре? Если не микротике то на циске на крайний случай?

Cisco ISG... На микротике IPoE нормального нет и навряд появится, сплошь костыли и костылики, прописывание маршрутов вручную/нескучными костыликами из скриптов и т.п., при этом ребут микротика с кучей прописанных таким образом роутов легко может поставить сеть враскоряку - ибо маршруты при добавлении автоматом попадают в конфиг, а лизы - скорее всего нет...

Я знаю что Cisco ISG прекрасно работает по source IP, но не уверен что оно умеет делать /32 роуты по MAC адресу.

Я бы сказал что системы на DHCP by design не умеют создавать хостроуты и любое использование их в этом качестве подразумевает костыли. Это не проблема Микротика, это проблема неправильного применения протокола.

 

Решение, которое предложил Saab по крайней мере лекго поддается проверке и выглядит жизнеспособным. Хотелось бы увидеть конфиг ISG для подобной задачи.

[NiTr0]

Едет монтажник к клиенту и не знает на какой из трех ближайших баз будет оптимальный сигнал. Одну сторону закрывает дерево, другая база перегружена и там не разрешен тариф и т.д. И все это в воскресенье вечером, когда главный админ еще не проснулся. Авторизация от абоненета, а не порта - это суровая необходимость, а не глупая прихоть.

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

 

Давайте конкретно. Каждому клиенту выдается сейчас адрес из пула 172.16.0.0/18. На одной базе может оказаться клентс адресом 172.16.0.10 и 172.16.7.10. Маска /18. Какая подсеть по вашему должна стоять в этом случае на интерефейсе NAS? Если вы правильно ответите на этот вопрос, то спрашиваю следующий - откуда на брасе возникнет /32?

Никакой подсети на интерфейсе. Маршрут на клиента через интерфейс.

 

Логин-пароль это основной способ аутентификации WIMAX, который прекрасно работает на L3 c туннелями. Скажем так это тяжелое наследие легаси системы, которое является дополнительным отягчающим обстоятельством. Заметьте и в PPPOE и в WIMAX это прекрасно работает.

Это наследие диалапа. Которое да, работает, но это не плюс, а минус. Ибо пережиток.

 

И лишь для схемы с DHCP это неверотяно сложно применить. Это к теме топика DHCP vs PPPOE.

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

 

Я бы сказал что системы на DHCP by design не умеют создавать хостроуты и любое использование их в этом качестве подразумевает костыли. Это не проблема Микротика, это проблема неправильного применения протокола.

Какие такие костыли? В случае accel-ppp - никаких костылей, все кучеряво, маршруты создаются-удаляются по мере коннектов пользователей, без каких-либо сторонних подпорок из скриптов, которые в случае внепланового ребута превратят брас в геморрой для всей сети...

 

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

[Sonne]

Едет монтажник к клиенту и не знает на какой из трех ближайших баз будет оптимальный сигнал. Одну сторону закрывает дерево, другая база перегружена и там не разрешен тариф и т.д. И все это в воскресенье вечером, когда главный админ еще не проснулся. Авторизация от абоненета, а не порта - это суровая необходимость, а не глупая прихоть.

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

 

Вы не понимаете потому что это не технический вопрос, а организационный, точнее вопрос бизнеса. Операторы связи работают чтобы удовлетворять потербности клиентов и приносить деньги владельцам, а не для того чтобы сумашедшие админы имели полный котроль. Да к слову, контроль над CPE итак всегда остается у оператора. Подключение без CPE к радиосети невозможно. Так что ваши фантазии про кулхацкеров помойки и т.д. являются бредом.

 

Давайте конкретно. Каждому клиенту выдается сейчас адрес из пула 172.16.0.0/18. На одной базе может оказаться клентс адресом 172.16.0.10 и 172.16.7.10. Маска /18. Какая подсеть по вашему должна стоять в этом случае на интерефейсе NAS? Если вы правильно ответите на этот вопрос, то спрашиваю следующий - откуда на брасе возникнет /32?

Никакой подсети на интерфейсе. Маршрут на клиента через интерфейс.

 

DHCP не работает без какой нибудь подсети. Садитесь два.

 

Логин-пароль это основной способ аутентификации WIMAX, который прекрасно работает на L3 c туннелями. Скажем так это тяжелое наследие легаси системы, которое является дополнительным отягчающим обстоятельством. Заметьте и в PPPOE и в WIMAX это прекрасно работает.

Это наследие диалапа. Которое да, работает, но это не плюс, а минус. Ибо пережиток.

Ну да, симкарта пережиток как и любой тип персональной аутентификации абонента. Кстати в WIMAX применяется аутентификация на основе MAC, которая вообще умерла не родившись. Неужели вы не способны понять, что единственный способ аутентификации мобильного абонента - это персональный, а не сетевой аутентификатор?

[NiTr0]

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

Это - не вопрос бизнеса Это - вопрос отсутствия какого-либо представления о информационной безопасности.

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

 

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

Уверены? А если пользователь доберется до терминала CPE, или через дыру в фирмвари вычитает пароль к админке/PSK для подключения к базе - управление тоже будет у оператора?

 

DHCP не работает без какой нибудь подсети. Садитесь два.

Работает, и прекрасно. Садитесь, два. DISCOVER получается отлично без каких-либо адресов на интерфейсе. OFFER уходит туда же без адресов. REQUEST получается опять же по маку, адрес раса поднят на другом интерфейсе. ACK - прописывается предварительно маршрут на клиента через интерфейс, и пакет уходит тудой.

 

Вопрос вам на засыпку: какая подсеть для каждого клиентского qinq влана будет на accel-ppp или MX80?

 

Ну да, симкарта пережиток как и любой тип персональной аутентификации абонента.

Сим-карта как и смарт-карта - вполне имеет место быть. Только вот причем она к древнему логину-паролю? :)

 

Неужели вы не способны понять, что единственный способ аутентификации мобильного абонента - это персональный, а не сетевой аутентификатор?

Единственный правильный способ аутентификации абонента - должен 1) не напрягать абонента лишними действиями 2) максимально исключать подделку. Сим-карта этому удовлетворяет. Логин-пароль, с которым можно коннектиться из любой точки сети - нет.