[WY6EPT]

ну вы сами писали:

>1й юрик, потом 2й, 3й будут в одной подсети, политически неверно.

они как бы в любом случае будут в одной подсети, вопрос только в том, что будут ли между ними arp брудкаст

 

IPoE это называют и даже применяют именно таким образом и даже большие дядьки =)

 

на крайняк можно сделать ассиметричный vlan, где то видел такое.

что бы все порты видели аплинки, но не видели друг друга =) очень удобно

 

ну реально вы думаете как придумать велосипед, тут либо пппое либо влан с подсетью, остальное лишние навороты

[alibek]

ну вы сами писали

И как из этого следует, что кто-то не хочет, что-бы ЮЛ могли обмениваться трафиком друг с другом?

Будут обмениваться, просто не напрямую, а через шлюз.

Велосипед и костыли — это как раз ассиметричный VLAN, но из-за дефицита IP-адресов его начинают применять.

Выделенный VLAN с отдельной подсетью и статической маршрутизацией — это правильно и архитектурно красиво.

[WY6EPT]

про ассиметричный я напиал, что крайний случай =)

а про VLAN абсолютно согласен, этот вариант сразу и предлагал ;)

[ShyLion]

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

 

Если контроль IPoE сеанса реализован на BRAS а на доступе ничего не включается и не выключается при изменении баланса, то как раз таки на доступе клиенты должны быть изолированы, чтобы не могли "мимо кассы" работать. И политика с религией тут непричем.

[YuryD]

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

Конфликты - неизбежны, увы, в голове что-то сдохло - но маськвичи никогда не согласятся с признанием своих глюков, и хрен докажешь, в gre я заглянуть не могу... Пока решаю так - у нас на ластмиле всё изумительно, звоните в маськву, и там разбирайтесь. По моему опыту, после этого такая заявка снимается сразу. К тому, что крупная сеть не имеет админов на местах вообще, и даже если их реальный IP попал в спамблок - никто не пошевелится сверху вообще. Есть пример - gre есть, но мимо туннеля их клиентская хрень бомбит по smtp... Вайлдохрененные, с триппером видимо везде, до их верних адвинов недостучаться. Хотя - схема бизнеса такая...

[ShyLion]

Вообще - глупо запрещать юрикам обмен между собой.

Т.е. даже если они не платят, пущай общаются?

[[anp/hsw]]

Т.е. даже если они не платят, пущай общаются?

Если на обоих концах - внешние IP, то что-то там запрещать вы права не имеете.

Ограничить скорость - пожалуйста.

При положительном балансе, да.

А при отрицательном - рубите весь порт/vlan, и нет проблем.

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

[alibek]

Вообще - глупо запрещать юрикам обмен между собой.

Наверно я какими-то другими буквами пишу.

Попробую еще раз.

Пусть общаются. Но не напрямую, а через узел оператора.

[[anp/hsw]]

Пусть общаются. Но не напрямую, а через узел оператора.

Они и так общаются не напрямую, а через узел оператора, иначе зачем им этот оператор вообще сдался?

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

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

 

Почему не использовать ACL на свиче или просто делать shutdown на порту? Могу придумать только один вариант: биллинг не умеет контролировать свичи.

[alibek]

' timestamp='1475223403' post=1327858]

если они в одной коммутируемой подсети

Так это не от хорошей жизни, а обычно из-за дефицита IP и перехода на ip unnumbered.

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

Если же выделять подсеть на ЮЛ, то такой ерундой заниматься не нужно, они изолированы изначально.

[[anp/hsw]]

Если же выделять подсеть на ЮЛ, то такой ерундой заниматься не нужно, они изолированы изначально.

Это 3-кратный перерасход IP (большинству юриков больше одного ип не нужно).

Сейчас IPv4 уже достаточно ценный ресурс, чтобы им так щедро раскидываться.

[alibek]

Можно выделять /31, а не /30.

Ну и платят ЮЛ больше в том числе и поэтому.

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

[ShyLion]

' timestamp='1475220450' post='1327843']

А при отрицательном - рубите весь порт/vlan, и нет проблем.

 

Почему мы прям должны рубить порт или vlan? Может нам удобнее не авторизовать сессию на BRAS и ставить L4 redirect.

Может я не хочу привязывать билинг к топологии.

[[anp/hsw]]

Может я не хочу привязывать билинг к топологии.

Тогда ip unnumbered + proxy arp или какой-нибудь pppoe. Иначе нерационально тратятся внешние адреса, которые сейчас на вес золота.

[ShyLion]

' timestamp='1475232426' post='1327927']

Может я не хочу привязывать билинг к топологии.

Тогда ip unnumbered + proxy arp или какой-нибудь pppoe. Иначе нерационально тратятся внешние адреса, которые сейчас на вес золота.

Оно так и есть.

[DobroFenix]

Микротик так умеет?

Микротик вообще не умеет выдавать белые ip адреса. Только танцы с pppoe, либо с netmap, что и то и то является не совсем правильным способом выдачи белых ip адресов клиентам.

[EShirokiy]

DobroFenix, wat?

Оказывается микротик выдавать не умеет, а мы как то выдаем, чудеса)

На вилан на микротике навешиваю IP с маскрой /32, который является шлюзом всей вашей подсети /27. В нетворк указываю IP клиента. Все прекрасно работает. У клиента прописываем статикой внешку с маской /27 и шлюз. При этом, клиенты не могут видеть друг друга.

Т.е. шлюз /27 - это xx.xx.xx.1

IP абонента xx.xx.xx.2

На микроте выглядит так:

add address=xx.xx.xx.1 interface=urik_vlan network=xx.xx.xx.2

[myth]

Перерасход IP же

[SyJet]

Микротик так умеет?

Микротик вообще не умеет выдавать белые ip адреса. Только танцы с pppoe, либо с netmap, что и то и то является не совсем правильным способом выдачи белых ip адресов клиентам.

От куда же вы такие беретесь...

[EShirokiy]

myth, только на шлюз и на бродкаст, можно в такой схеме вообще использовать /24 или больше)

От куда же вы такие беретесь...

Тупой хейт микротика в моде.

[myth]

только на шлюз и на бродкаст

2 адреса из 3 уходят вникуда

 

можно в такой схеме вообще использовать /24 или больше

Очень плохая идея

[EShirokiy]

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

[GrandPr1de]

это микротиковский вариант аннамбереда

нет там никакого перерасхода, конечно если будет \30 подсеть то там 3 адреса в никуда уйдут

ну так это проблема маленькой сети из 4 адресов

берем класический вариант /24, и у нас из 256 адресов остается 253.

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

 

и что за сеть из 3 адресов конечно вопрос....

[Butch3r]

Можно выделять /31, а не /30.

Ну и платят ЮЛ больше в том числе и поэтому.

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

у нас /30 по запросу. Просто так - аннаберед. Очень жирно по 4 адреса выдавать ЮЛ, которые им не нужны. У нас куча крупных абонентов также просит 1 адрес в инете, главное чтоб он был статичный. Сети нужны тем, у кого есть админы :)

[Saab95]

Вообще при схеме с микротиком абоненту целесообразно делать не /27 а /24 или более, тогда у всех абонентов будут одинаковые настройки, а общаться друг с другом через прокси-арп. Это очень помогает решать проблемы техподдержки, т.к. при случае меньшей маски нужно определять какую абоненту поставить, или смотреть в биллинге комментарии и т.п.