alex_001 Posted May 8, 2010 · Report post Kто как раздает? Сейчас у меня в основном через vpn или напрямую на eth. В случае с vpn все нормально , но от него очень хочется уйти на чистый IPoE. А вот сдесь начинаются проблемы - если неправильно оцениваем количество клиентов на интерфейсе теряется много адресов либо получается зоопарк из alias'ов. В идеале хотелось бы видеть схему а la vpn (одна большая сеть , не тратим адреса на net,broadcast,gw) но на eth. Из возможных вариантов в голову приходит только DNAT/SNAT на внутренние ip , host route (но тут уже на клиенте проблема настроить). Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
jab Posted May 8, 2010 · Report post man vlan Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alex_001 Posted May 8, 2010 · Report post man vlan unnumbered я так понимаю этим предлагается? проблема в том что далеко не везде на доступе управляемые порты. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted May 8, 2010 · Report post >man vlan Ну и как это поможет решить проблему того, что либо давать сетку /30 на абонента, либо предсказывать сколько будет абонентов на (саб)интерфейсе? То, что хочет alex_001 называется ip unnumbered, как это реализуется на линуксах/фряхах и т.п. я не знаю, но как это делается на cisco есть howto даже на русском: http://www.opennet.ru/base/cisco/catalyst_...number.txt.html Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
photon Posted May 8, 2010 (edited) · Report post Если на доступе есть тупые свичи, то почему бы не сделать на агрегации по влану на каждый downlink, идущий к домовым свичам? Еще можно порезать мусорный трафик с помощью ACL. Все лучше будет, чем вообще без сегментов. На агрегации какие свичи стоят? Edited May 8, 2010 by photon Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alex_001 Posted May 8, 2010 · Report post Если на доступе есть тупые свичи, то почему бы не сделать на агрегации по влану на каждый downlink, идущий к домовым свичам? Еще можно порезать мусорный трафик с помощью ACL. Все лучше будет, чем вообще без сегментов. На агрегации какие свичи стоят? Так и сделано. Вопрос в том что на эти vlan'ы тратится дофига реальных ip , из за низкого коэфф. использования адресов или на brd,net,gw в случае мелких масок. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
photon Posted May 8, 2010 (edited) · Report post Значит надо сделать сегменты покрупнее, по влану на несколько портов, настроить ip unnumbered, если оборудование позволяет, и арендовать у своего апстрима дополнительную подсеть белых IP. Edited May 8, 2010 by photon Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted May 8, 2010 · Report post Ну так с мыльницами будут воровать друг у друга мак-адреса и пользоваться ip адресом соседа по свитчу. Так? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alex_001 Posted May 8, 2010 · Report post Значит надо сделать сегменты покрупнее, по влану на несколько портов, настроить ip unnumbered, если оборудование позволяет, и арендовать у своего апстрима дополнительную подсеть белых IP. Адреса есть .. Хочется просто более экономно раздавать и все. А то RIPE новые блоки отдает все более неохотно (и правильно делает). Вобщем тему надо было назвать "нестандартные методы раздачи реальников" - просто все что тут предлагалось тривиально , и уже сделано где возможно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
jab Posted May 8, 2010 · Report post Ну и как это поможет решить проблему того, что либо давать сетку /30 на абонента, либо предсказывать сколько будет абонентов на (саб)интерфейсе? что мешает загнать все реальники в один vlan ? жадность или религия ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alex_001 Posted May 8, 2010 · Report post Ну и как это поможет решить проблему того, что либо давать сетку /30 на абонента, либо предсказывать сколько будет абонентов на (саб)интерфейсе? что мешает загнать все реальники в один vlan ? жадность или религия ? Повторяю. Мешает отсутствие во многих местах управляемых портов на доступе. Соответственно нет возможности в произвольном месте этот влан выдернуть. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
jab Posted May 8, 2010 · Report post Повторяю. Мешает отсутствие во многих местах управляемых портов на доступе. Соответственно нет возможности в произвольном месте этот влан выдернуть. Это как раз называется жадностью. :-) В исходном постинге было написано про IPoE, а потом про неуправляемые свичи. Подмена MAC/IP хорошо лечит от раздачи реальников мимо VPN на неуправляемой сети. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Lynx10 Posted May 8, 2010 · Report post Повторяю. Мешает отсутствие во многих местах управляемых портов на доступе. Соответственно нет возможности в произвольном месте этот влан выдернуть. Это как раз называется жадностью. :-) В исходном постинге было написано про IPoE, а потом про неуправляемые свичи. Подмена MAC/IP хорошо лечит от раздачи реальников мимо VPN на неуправляемой сети. да так надо и сказать - если есть тупые свичи на доступе то конфетка не получится - всё равно будет кака! пока не поменяете свичи спокойно о нормальном IPoE можете забыть! как не крути а вам на доступе надо или сделать так чтобы они между собой не бегали - тогда можна в один влан пихать их или вообще влан на юзера - как в первом так и в другом случае надо управляемый свич! Мне нравится первый вариант - тоесть влан на дом - и запрешение обмена между портамина дому! Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Дегтярев Илья Posted May 8, 2010 (edited) · Report post при отсутствии ip unnumbered (геморно его сделать) решили затестить схему с ip dhcp smart ralay. В вилане 256 реальников и 256 виртуальных. Постоянно сидящие в сети получают реальный, остальным что попадется. Edited May 8, 2010 by Дегтярев Илья Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Abram Posted May 10, 2010 · Report post А чем не угодил ISG? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Lynx10 Posted May 10, 2010 (edited) · Report post А чем не угодил ISG? а раздавать под ISG выхотите статически или динамически? если динамически то вы же наверное должны к чему то привязаться для того чтобы они их просто не поменяли - например к маку - да ? маки сопрут и будут менять клиенты которые сидят на мыльницах тупых! со статическим вариантом будет то же самое! и опять же таки - а что ISG чем то поможет если человек не хочет давать /30 ? тут ISG вообще ни при чём! надо ip unnumbered кроме того надо управляемые свичи чтобы был намертво привязан порт клиента к маку! причём к одному! то есть чтобы а на порте работал только один мак причём именно тот который прописан! Edited May 10, 2010 by Lynx10 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vop Posted May 11, 2010 · Report post Из возможных вариантов в голову приходит только DNAT/SNAT на внутренние ip В принципе, этот вариант выглядит одним из самых экономных и до простоты надежных. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted May 11, 2010 · Report post Если использовать NAT(и S и полный D), то каким образом отличать абонента A от абонента B с учётом того, что у автора темы есть мыльницы на доступе? И каким образом выставлять тарифный план? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vop Posted May 11, 2010 (edited) · Report post Если использовать NAT(и S и полный D), то каким образом отличать абонента A от абонента B с учётом того, что у автора темы есть мыльницы на доступе? И каким образом выставлять тарифный план? Я так подозреваю, что так же, как и отличают абонентов, у которых нет реальных ip, и которые работают в приватных адресах - средствами своего стандартного биллинга. А тарифный план выставляется на услугу "реального ip", при этом локальный ip не тарифицируется, или тарифицируется, как локальный, если ральный оплачитвается дополнительно. Edited May 11, 2010 by vop Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alex_001 Posted May 12, 2010 · Report post Если использовать NAT(и S и полный D), то каким образом отличать абонента A от абонента B с учётом того, что у автора темы есть мыльницы на доступе? И каким образом выставлять тарифный план? Ух , привязались к мыльницам. Забудьте хоть на время про security - тут вопрос решен другими методами. Про мыльницы писал только в том плане что не всегда есть возможность выкинуть конкретный vlan на конкретный порт. В случае с натом подсчет точно такой-же , просто считается трафло на ip из rfc1918 , реальник висит отд. услугой.. Кстати схему с симметричным натом я встречал у кого-то из операторов (не помню правда уже у кого и весьма давно..) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Lynx10 Posted May 12, 2010 · Report post Из возможных вариантов в голову приходит только DNAT/SNAT на внутренние ip В принципе, этот вариант выглядит одним из самых экономных и до простоты надежных. лишняя и ненужная нагрузка на маршрутизатор... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alex_001 Posted May 12, 2010 · Report post Из возможных вариантов в голову приходит только DNAT/SNAT на внутренние ip В принципе, этот вариант выглядит одним из самых экономных и до простоты надежных. лишняя и ненужная нагрузка на маршрутизатор... В свете скорого наступления полной Ж с IPv4 возможность выделять в любом месте сети просто /32 кажется крайне заманчивой , несмотря на нагрузку (да и явно поменьше она , чем если туннели терминировать + local идет мимо).Из недостатков - не совсем прозрачная настройка для клиента , и проблемы вызванные самим натом. Очень интересно знать заранее где тут грабли (у меня много клиентов за натом (односторонним)- проблем вроде немного , но возможно встречаются разные нетривиальные варианты (в свете замены такой конструкцией реальника), интересно бы о них заранее знать). Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Abram Posted May 13, 2010 · Report post А чем не угодил ISG? а раздавать под ISG выхотите статически или динамически? если динамически то вы же наверное должны к чему то привязаться для того чтобы они их просто не поменяли - например к маку - да ? маки сопрут и будут менять клиенты которые сидят на мыльницах тупых! со статическим вариантом будет то же самое! и опять же таки - а что ISG чем то поможет если человек не хочет давать /30 ? тут ISG вообще ни при чём! надо ip unnumbered кроме того надо управляемые свичи чтобы был намертво привязан порт клиента к маку! причём к одному! то есть чтобы а на порте работал только один мак причём именно тот который прописан! Вот как раз так пирблизительно я у себя сейчас делаю :). Жестко буду прибивать маки к портам. DHCP раздавать на основе маков из биллинга. А при чем тут /30? В ISG человек получает внутренние айпи, на которые уже при потребности пробрасываются внешние (stateless NAT). Не забываем также, что у ISG существует понятие сессии (как у PPTP/PPPoE, да-да). Так что проблема перерасхода внешних адресов тоже фактически отпадает. Товарищи! Всё уже придумано! Нехер изобретать велосипеды! Из возможных вариантов в голову приходит только DNAT/SNAT на внутренние ip В принципе, этот вариант выглядит одним из самых экономных и до простоты надежных. лишняя и ненужная нагрузка на маршрутизатор... А вот совсем нет, если stateless. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Lynx10 Posted May 13, 2010 · Report post Вот как раз так пирблизительно я у себя сейчас делаю :). Жестко буду прибивать маки к портам. DHCP раздавать на основе маков из биллинга.можна сказать без этого никак!А при чем тут /30? В ISG человек получает внутренние айпи, на которые уже при потребности пробрасываются внешние (stateless NAT). Не забываем также, что у ISG существует понятие сессии (как у PPTP/PPPoE, да-да). Так что проблема перерасхода внешних адресов тоже фактически отпадает.ISG это классно, сессии тоже классно всё классно а вот НАТ - это как по мне через зад! Это не раздача реальников а это проход серого под одним и тем же белым - то есть снат ! А если извне надо присоединится ? будете днат делать один в один? И это вы называете раздачей белых адресов ?ну у нас значит разное представление о раздачи белых адресов! А вот совсем нет, если stateless.конечно нет - погреть воздух процесором - это прикольно вместо того чтобы вообще без ната делать! Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted May 13, 2010 · Report post >Очень интересно знать заранее где тут грабли (у меня много клиентов за натом (односторонним)- проблем вроде немного , но возможно встречаются разные нетривиальные варианты (в свете замены такой конструкцией реальника), интересно бы о них заранее знать). Из того, что сразу приходит в голову это проблема использования ipsec совместно с nat Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
