Jump to content
Калькуляторы

мультибизнес кампус - раздача инета Что? Где? Как?

Имеется следующие juniper-железки:

10 дистриб-свичей;

2 свича ядра;

2 бордер-маршрутизатора (пиринг BGP, 2 ISP);

Задача:

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

выдать подключаемым пользователям интернет;

организовать связь (помимо инета) для «распределенных» юр.лиц;

обеспечить необходимую полосу пропускания в инет;

обезопасить сеть от спуфинга адресов (считать/нарезать полосу, вероятнее всего по IP-адресу);

 

Раздача инета:

Есть желание раздать пользователям публичные адреса (статикой) или, при необходимости, подсети. В качестве шлюза для пользователей использовать дистриб-свич. Далее в ядро OSPF ECMP с серой транспортной адресацией.

Спуфинг:

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

а-ля VPN (связь для «распределенных пользователей»):

Вот тут начинаются неприятные вещи. Если первая L3-точка для пользователя – дистриб-свич, от которого в ядро уходят L3-линки, то как прокинуть вилан с одного блока распределения на другой?(если бы L2, то, тупо в сторону пользователя транк с пропуском 2-х его виланов - инета и "vpn").

QoS:

Где правильней нарезать полосу в инет для пользователей? сразу на дистрибе? в ядре?

 

Есть ли смысл терминировать пользовательские "инет"- и "vpn"- виланы на дистибе? или лучше по L2-линкам дотащить в ядро? (все железки «умные» - и дистриб и ядро).

Edited by altair

Share this post


Link to post
Share on other sites

MPLS приходит в голову.

Share this post


Link to post
Share on other sites

ой, как-то стало неутно....

можно подробнее?

Share this post


Link to post
Share on other sites

Ядро переводим на коммутацию по меткам, юриков запихиваем в отдельные VRF, делаем им впны.

 

Фактически, ваши требования идеально описыват назначение мплс :)

Share this post


Link to post
Share on other sites

=) когда заходил вопрос об этом с реализацией на цискином железе, то VRF-lite мне все в голову лез, однако, люди сказали, что с ним лучше не связываться - очень много "ручной" работы - типа прописей vlan-vrf и прочее.

 

А как с остальным? Например, где резать полосу?...

Share this post


Link to post
Share on other sites

А руками SVI и ацл прописывать - это не много работы?

 

Остальное - кос есть, а трафик резать - так это к мплс не относится. Ну я на клиентских портах режу.

Share this post


Link to post
Share on other sites
А руками SVI и ацл прописывать - это не много работы?
Это точно - много.

По поводу остального - может подкинете ссылку с "примером"? А то что-то по поводу мплс не в зуб ногой - не понятно, как инет с выдачей паблик-адресов+"впн" работает там? (в смысле без ната).

Edited by altair

Share this post


Link to post
Share on other sites
Имеется следующие juniper-железки:

10 дистриб-свичей;

2 свича ядра;

2 бордер-маршрутизатора (пиринг BGP, 2 ISP);

тут велосипеда я бы вообще не придумывал

влан на клиента, на RVI uRPF, VRRP на двух бордерах, там же считаем и шейпим.

Все, больше тут ничего не нужно на 10 свитчах распределения.

Share this post


Link to post
Share on other sites
Имеется следующие juniper-железки:

10 дистриб-свичей;

2 свича ядра;

2 бордер-маршрутизатора (пиринг BGP, 2 ISP);

тут велосипеда я бы вообще не придумывал

влан на клиента, на RVI uRPF, VRRP на двух бордерах, там же считаем и шейпим.

Все, больше тут ничего не нужно на 10 свитчах распределения.

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

 

Опять же не ясен вопрос "инет+"vpn"" в "одном порту".

Share this post


Link to post
Share on other sites
Имеется следующие juniper-железки:

10 дистриб-свичей;

2 свича ядра;

2 бордер-маршрутизатора (пиринг BGP, 2 ISP);

А какие это конкретно коробки? Сколько абонентов предполагается к этому подключить? Все абоненты юрики?

Share this post


Link to post
Share on other sites
Имеется следующие juniper-железки:

10 дистриб-свичей;

2 свича ядра;

2 бордер-маршрутизатора (пиринг BGP, 2 ISP);

А какие это конкретно коробки? Сколько абонентов предполагается к этому подключить? Все абоненты юрики?

Коробки следующие:

 

ex4200 - дистриб;

ex8200 - ядро;

m7i - бордеры.

(между m7i и 8200 - пара srx3400)

абонентов <= 400;

Все юрики.

Edited by altair

Share this post


Link to post
Share on other sites

Люди, а кто-нибудь может подсказать "+" и "-" вот этого:

 

Ядро переводим на коммутацию по меткам, юриков запихиваем в отдельные VRF, делаем им впны.

 

Фактически, ваши требования идеально описыват назначение мплс :)

против вот этого:

 

А руками SVI и ацл прописывать - это не много работы?

Короче плюсы/минусы схемы с vrf и "схемы без vrf"...

Share this post


Link to post
Share on other sites
Имеется следующие juniper-железки:

10 дистриб-свичей;

2 свича ядра;

2 бордер-маршрутизатора (пиринг BGP, 2 ISP);

тут велосипеда я бы вообще не придумывал

влан на клиента, на RVI uRPF, VRRP на двух бордерах, там же считаем и шейпим.

Все, больше тут ничего не нужно на 10 свитчах распределения.

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

 

Опять же не ясен вопрос "инет+"vpn"" в "одном порту".

RVI на ядре или вообще на бордере

VPN с чем? с соседним филиалом? в 1 влан их

 

насчет rpf-check "сразу на всех" - нет такого

Share this post


Link to post
Share on other sites
насчет rpf-check "сразу на всех" - нет такого

http://www.juniper.net/techpubs/en_US/juno...-ex-series.html

Почти в конце странички - "When Not to Enable Unicast RPF"

 

"Note: Do not enable unicast RPF if any switch interfaces are asymmetrically routed because unicast RPF is enabled globally on all interfaces. All switch interfaces must be symmetrically routed for you to enable unicast RPF without the risk of the switch's discarding traffic that you want to forward."

 

RVI на ядре или вообще на бордере
Растягивать L2 до бордера...Как-то не айс. (с учетом того, что все свичи - L3 с OSPF и прочими плюшками).

 

VPN с чем? с соседним филиалом? в 1 влан их

И на все подключаемые железки этого вилана давать по паблик-адресу? Можно ли сделать следующим образом?

 

дать пользователю "транк" на одной "площадке" (дистриб-свич-А) - в нем vpn-vlan и internet-vlan (шлюз для инета на дистриб-свиче-А), а на 2-й

"площадке" (дистриб-свич-Б) - только vpn-vlan. И пусть он сам выпускает свою 2-ю площадку в инет через 1-ю. Но это, опять же получается, растягивать виланы на весь дистриб/ядро =(.

 

Или это тоже геморройный вариант?

Edited by altair

Share this post


Link to post
Share on other sites

Имхо, с мплс на таких объемах заморачиваться не стоит.

 

Раз свитчи умеют L3, цепляйте к ним как хотели.

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

Если коммутаторы доступа умеют L3 интерфейс к SVI привязать, то нет проблем и влан для VPN прокинуть через uplink порт к другому кусту.

В сторону клиента проще отдать все в акцессе, если ему нужен vpn, то дополнительный порт на коммутаторе подарить.

 

Share this post


Link to post
Share on other sites
Если коммутаторы доступа умеют L3 интерфейс к SVI привязать, то нет проблем и влан для VPN прокинуть через uplink порт к другому кусту.

не понял...

Share this post


Link to post
Share on other sites
насчет rpf-check "сразу на всех" - нет такого

http://www.juniper.net/techpubs/en_US/juno...-ex-series.html

Почти в конце странички - "When Not to Enable Unicast RPF"

 

"Note: Do not enable unicast RPF if any switch interfaces are asymmetrically routed because unicast RPF is enabled globally on all interfaces. All switch interfaces must be symmetrically routed for you to enable unicast RPF without the risk of the switch's discarding traffic that you want to forward."

 

RVI на ядре или вообще на бордере
Растягивать L2 до бордера...Как-то не айс. (с учетом того, что все свичи - L3 с OSPF и прочими плюшками).

 

VPN с чем? с соседним филиалом? в 1 влан их

И на все подключаемые железки этого вилана давать по паблик-адресу? Можно ли сделать следующим образом?

 

дать пользователю "транк" на одной "площадке" (дистриб-свич-А) - в нем vpn-vlan и internet-vlan (шлюз для инета на дистриб-свиче-А), а на 2-й

"площадке" (дистриб-свич-Б) - только vpn-vlan. И пусть он сам выпускает свою 2-ю площадку в инет через 1-ю. Но это, опять же получается, растягивать виланы на весь дистриб/ядро =(.

 

Или это тоже геморройный вариант?

1) uRPF на ЕХах включается или глобально на свитч, или для каждого конкретного интерфейса. был неправ, но у меня как-то без глобалистики работает...

2) да, тянуть л2 до бордера, причем это джуниперовски рекомендованная схема, по сути (только там не до бордера, а до браса). Ну и что, что свитчи л3. Зато гораздо проще будет клиентов разделять друг с другом, если надо будет, и VRF на всех свитчах не надо делать.

3) можно

4) л2 на 40 дистрибьюшн-свитчей - не страшно ни разу. Можно клиентов через CCC подключить, если уж очень хочется весь функционал задействовать.

Edited by cmhungry

Share this post


Link to post
Share on other sites
3) можно
Это по поводу чего?

 

Можно клиентов через CCC подключить, если уж очень хочется весь функционал задействовать.

не пинайте....что такое CCC?

 

если circuit cross-connect, то на него вроде бы Advanced License нужен... и как оно работает вообще?

Edited by altair

Share this post


Link to post
Share on other sites
Если коммутаторы доступа умеют L3 интерфейс к SVI привязать, то нет проблем и влан для VPN прокинуть через uplink порт к другому кусту.

не понял...

Имел в виду что L3 интерфейс на коммутаторе доступа можно сделать не на порту а виртуальным, внутри коробки, как это есть у cisco - SVI. В таком случае аплинк порт идущий в ядро можно оставить в транке и прокидывать при надобности вланы нуждающимся в vpn.

Share this post


Link to post
Share on other sites

=) понятно, ну это обычный interface vlan.

Кажется варианты доступны оба - и "SVI" и "no switchport"

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this