[wtyd]

Кстати, тут в последнем ядре линукса (2.6.34) заявлена реализация фичи типа ip unnumbered, забыл какое RFC. Т.е. по вилану на абона + proxy-arp = по однойму ойпи на абона, а не по /30. Так вот, может быть кто-то уже тему раскрыл ? :-).

..........

Это вроде и раньше можно было сделать через vlans+bridge. Тоесть эксперементировать можно хоть сейчас , вот только рулить доступ на PC - тяжеловато...

Бридж это плохо, зачем тогда по вилану на юзера делать, если все виланы бриджевать потом ? Бесполезно тратить ресурсы на бридживание ? Роутить для РС гораздо легче, чем бриджевать.

 

Тут у многих есть NAS на РС и живут же. Только NAS делает обычно либо pppoe либо pptp, это гораздо накладнее, чем роутить :-).

 

P.S. Я несколько лет назад сбриджевал виланы и ... ну у меня тогда для тестов был только русский свич lightcom, оказалось он так не может :-). Меня долго не могли понять в сапорте лайткомов :-).

[wtyd]

>Это вроде и раньше можно было сделать через vlans+bridge.

 

Можно поподробнее? Предлагается делать bridge между каждой парой сабинтерфейсов или все в одну кучу? Под bridge понимается обеспечение связности на L2? Ещё предлагается делать проверка source ip через iptables? До каждого абонента добавлять маршрут /32?

Скорее всего не получится всё сделать одной командой как в цыске ip innumbered на сабе (вланском интерфейсе). Скорее всего придётся делать так:

 

1. нарезаем в свичах и нужных сетевух картах по вилану на абона

2. делаем на каждом сабе ip li set up dev eth0.10 ... eth0.40 ... eth1.10 ... (всё абонские сабы)

3. куда-то вешаем ойпи из подсети для абонентов -- это будет для них шлюз

4. включаем proxy_arp на всез абонских сабах и включем proxy_arp_pvlan -- это и есть новая фишка ведра.

5. для каждого абонского ойпи прописываем роут типа ip r a 192.168.0.10/32 dev eth0.10

 

Ещё можно включить rp_filter на абонских сабах для антиспуфинга если ломает или невозможно прописать acl на порту свича доступа.

 

Теоретически этого должно хватить, но я не проверял :-).

 

Все остальные шняжки типа htb теперь делаются per subinterface, только я не знаю, будут ли они от этого работать шустрее, ведь наличие сабов само по себе тоже тратит ЦПУ. Т.е. я не знаю, есть ли во всё этом смысл кроме "а мы крутой оператор - у нас каждый абонент в своём вилане сидит!".

[s.lobanov]

>3. куда-то вешаем ойпи из подсети для абонентов -- это будет для них шлюз

 

вот всё-таки интересно куда именно вешаем. есть подозрение, что надо вешать на каждый саб один и тот же ip (шлюза) c большой маской

 

>ip r a 192.168.0.10/32 dev eth0.10

 

Если на eth0.10 не висит ip, то тогда надо ещё и src указать наверное

 

 

[wtyd]

>3. куда-то вешаем ойпи из подсети для абонентов -- это будет для них шлюз

 

вот всё-таки интересно куда именно вешаем. есть подозрение, что надо вешать на каждый саб один и тот же ip (шлюза) c большой маской

 

>ip r a 192.168.0.10/32 dev eth0.10

 

Если на eth0.10 не висит ip, то тогда надо ещё и src указать наверное

1. Вешать надо один раз, наверное в какое-нибудь одно правильное место (на какой-то один юзерский саб с правильной маской не /32), остальное сделает прокси_арп и новая фича, которая этот прокси_арп теперь умеет правильно пропускать куда надо. В цыске с ip unnumbered вообще на loopback вешают вроде бы. Вообще должно быть не важно - прокси_арп должен справиться с этим.

 

2. src *следует* указывать для локально сгенерёных пакетов. Если мы говорим о роутре, то это, во-первых, не очень-то и надо, во-вторых, src должен сам выбраться правильным, если сделать п.1. Ну ... я так думаю :-). Я не проверял.

 

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