[altair]

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

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

2 свича ядра;

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

Задача:

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

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

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

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

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

 

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

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

Спуфинг:

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

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

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

QoS:

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

 

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

Изменено 13 июля, 2009 пользователем altair

[chainick]

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

[altair]

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

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

[chainick]

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

 

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

[altair]

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

 

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

[chainick]

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

 

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

[altair]

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

Это точно - много.

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

Изменено 13 июля, 2009 пользователем altair

[cmhungry]

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

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

2 свича ядра;

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

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

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

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

[altair]

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

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

2 свича ядра;

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

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

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

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

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

 

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

[chainick]

По поводу остального - может подкинете ссылку с "примером"?

http://torrents.ru/forum/viewtopic.php?t=1115719

 

Документ называется Cisco.Press.MPLS.Implementing.Cisco.MPLS.v.2.1.Vol.2

[altair]

По поводу остального - может подкинете ссылку с "примером"?

http://torrents.ru/forum/viewtopic.php?t=1115719

 

Документ называется Cisco.Press.MPLS.Implementing.Cisco.MPLS.v.2.1.Vol.2

Спасибо, ща покуримс

[nnm]

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

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

2 свича ядра;

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

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

[altair]

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

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

2 свича ядра;

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

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

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

 

ex4200 - дистриб;

ex8200 - ядро;

m7i - бордеры.

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

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

Все юрики.

Изменено 14 июля, 2009 пользователем altair

[altair]

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

 

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

 

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

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

 

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

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

[cmhungry]

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

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

2 свича ядра;

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

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

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

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

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

 

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

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

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

 

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

[altair]

насчет 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-ю. Но это, опять же получается, растягивать виланы на весь дистриб/ядро =(.

 

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

Изменено 15 июля, 2009 пользователем altair

[rus-p]

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

 

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

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

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

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

 

[altair]

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

не понял...

[cmhungry]

насчет 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 подключить, если уж очень хочется весь функционал задействовать.

Изменено 15 июля, 2009 пользователем cmhungry

[altair]

3) можно

Это по поводу чего?

 

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

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

 

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

Изменено 15 июля, 2009 пользователем altair

[rus-p]

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

не понял...

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

[altair]

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

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