Раскритикуйте схемку - 2: выбор оборудования

[ivan77]

Прошу совета по выбору оборудования для данной схемы. А также ищу поставщика оного… :) Особенно интересует выбор Switch 1-2, и роутера (цифры на схеме около свичей - количество клиентов)

 

 

Есть бизнес-центр. Часть клиентов - реальные IP, часть - NAT.

В настоящее время схема почти та же на меди, только все на неуправляемом оборудовании (VoIP пока нет), выход в мир - через Linux-кластер. Ввиду появления в ближайшем времени VoIP, приближения грозоопасного сезона, а также окончании строительно-ремонтных работ, в ближайшее время планируется Upgrade вплоть до указанной схемы.

 

Пояснения.

Самая частая причина отказов (реально у нас) - обрыв линков и пропадание питания в отдельных местах, поэтому предусмотрены кольца почти для всех зданий. Все указанные линки - оптика, ввиду безумной дороговизны Qbic-модулей, а также успешного применения дешевых конвертеров (+кольца), построенные на конвертерах => оборудование планируется для меди.

Есть несколько клиентов, способных в пИке забить 100 Мбит, поэтому часть - гигабит.

 

Требования к сети:

0) надежность на уровне не менее 99,9%.

1) полноценная поддержка tagged VLAN (для изоляции клиентов друг от друга - в идеале User-per-Vlan, всего клиентов около 100);

2) полноценная поддержка QoS (для VoIP);

3) 802.1w Rapid STP (в отдельном VLAN - для безопасности);

4) поддержка IGMP (планируется вещание);

5) биллинг (куда ж без него);

6) роутер должен поддерживать BGP (2 аплинка).

7) ну и мелочи - шейпинг портов, config по TFTP…

 

Собственно, вопросы.

Первый и главный - как авторизовать и аутентифицировать юзеров?

а) 802.1x - очень широкая поддержка в ОС и роутерах, но нужно, чтобы сетевое оборудование умело с ним работать - типа присвоения VLANа после авторизации… (GVRP?) Очень удобно администрировать, но у кого есть опыт, неясно…

б) Option 82 DHCP . Наиболее реально. Но опять же - нужна поддержка в оборудовании.

в) всякие привязки портов к MAC - адресу. Тяжело администрировать - бизнес пользователи склонны к постоянной смене MAC-адресов… Только крайний случай.

г) PPPoE, VPN и проч. Удобно все (и авторизация, и биллинг), но сложно с поддержкой в клиентских устройствах (клиенты - разнообразные шлюзы от WinXP и D-Link DI-604 до CISCO и BSD).

 

Второй, и тоже важный, - как (чем) считать?

Хотелось бы уйти от Linux, но стоимость NetFlow-модулей впечатляет…

[Дятел]

ввиду безумной дороговизны Qbic-модулей

спорный тезис, вон у Нага они для циски по 120 баксов....

802.1x - очень широкая поддержка в ОС и роутерах, но нужно, чтобы сетевое оборудование умело с ним работать - типа присвоения VLANа после авторизации

я так понимаю, что VLAN назначается на порту, без авторизации. И умеют это делать все железяки с управлением и поддержкой Vlan

стоимость NetFlow-модулей впечатляет…

стоимость модуля к стоимости самих железок, куда он вставляется - ерунда...

[ivan77]

Дятел - переезд из помещения в помещение обычное явление…

Насчет NetFlow уточняю: читать "стоимость NetFlow-модулей и моделей c поддержкой этих модулей".

[Дятел]

ну, перенесёте VLAN на другую железяку в другой порт....

 

а я по картинке не понял, свич1 и свич 2 - в одном помещении?

[Дятел]

NetFlow и BGP умеют весьма старые модели цисок с небольшой ценой.

Вопрос, что считать (по ширине). Если к провайдеру 2 линка по 100М, и считается только внешний интернет-трафик, то всё дёшево.

Обсчитывать локальный трафик на гигабитных каналах - мало не покажется.

[ivan77]

Дятел, именно так. К провайдеру 2 линка по 100М, считается только внешний и-нет трафик. Остальное считается на уровне предоставления сервисов. А откуда там взяться внутреннему трафику в VLAN-per-User? :)

Свич1 и Свич2 в разных помещениях.

[Дятел]

Я б, наверное, свич1 поставил циску 3550 с 2 GBIC под Г, свич 2 - 3750 с 4 SFP под Г, а юзеровские - или 2950, если денег много, или д-линк 3226, если мало.

Если оба интернет-линка к одному провайдеру, то BGP не нужен, достаточно IGRP.

Так что роутер - любая циска от 4700 ценой около 1500.

[ivan77]

Дятел, разумеется линки к разным провайдерам (а мы получаем PI-блок). Без BGP - никак.

Плюс, насколько я понимаю, 3750 как свич2 сможет, если будет надо, роутить виланы.

Спасибо за совет.

[Дятел]

ivan77, получаем или хотим получить? с PI всё не очень просто, хотя возможно.

full bgp - это совсем не дёшево, к сожалению.

 

3550 как и 3750, тоже будет роутить, и она дешевле, и GBIC дешевле SFP.

про ограничения можно почитать тут:

http://forum.nag.ru/viewtopic.php?t=11474

 

первоисточник:

http://www.cisco.com/en/US/products/hw/swi...#switchdatabase

[MaxSavin]

ivan77, получаем или хотим получить? с PI всё не очень просто, хотя возможно.

Это без PI как раз "все не очень просто" :)

 

full bgp -  это совсем не дёшево, к сожалению.

А кто-то говорил про full-view? :) А BGP умеют большинство кошек, даже 800-е.

[ivan77]

Дятел, процесс (почти) запущен, договоренность есть.

А зачем нам full bgp, если из двух интерфейсов второй только лишь резервный?

Т.е. маршрута всего 2. Или я чего не понимаю?!

[Дятел]

Это без PI как раз "все не очень просто" :)  

я про получение блока имел ввиду )

А кто-то говорил про full-view? :) А BGP умеют большинство кошек, даже 800-е.

А зачем нам full bgp, если из двух интерфейсов второй только лишь резервный?  

Т.е. маршрута всего 2. Или я чего не понимаю?!

 

может, я и не прав.

но мне кажется, что так-как PI-блок не агрегетирован с провайдерским, то придётся анонсить маршрут на себя, полная аналогия с автономной системой.

нет?

[ivan77]

Дятел, а что, все провайдеры держат у себя full-view? ;)

есть и бедные провайдеры…

[MaxSavin]

Это без PI как раз "все не очень просто" :)  

я про получение блока имел ввиду )

Ну так это всего лишь вопрос денег. Или "правильных" контактов с LIR'ом, как вариант ;)

 

А зачем нам full bgp, если из двух интерфейсов второй только лишь резервный?  

Т.е. маршрута всего 2. Или я чего не понимаю?!

 

может, я и не прав.

но мне кажется, что так-как PI-блок не агрегетирован с провайдерским, то придётся анонсить маршрут на себя, полная аналогия с автономной системой.

нет?

Ну если аплинк представляет из себя одну AS - то достаточно будет использовать private AS number для анонса своего блока. Если же аплинки с разными AS - то тут без регистрации AS все равно не обойтись. Но в любом случае анонсирование блока можно делать практически на любой кошке, а от пиров по bgp получать только 0/0 (+анонсы внутриоператорских сетей, по вкусу) с выставлением local_pref (или вообще для исходящего прописать дефолт статиком).

 

Full-view, де-факто, для stub-network нужен крайне редко (хотя у себя держим для пущей гибкости).

[Дятел]

провайдеры, у которыйх своя автономная система, и которые LIR, должны держать full.

вторичные провайдеры, получающие PA блоки - не должны, маршруты на их сети являются внутренними.

если я правильно помню, минимальная сетка у LIR - /19 (16 сеток С)

 

в принципе, есть RFC, по которой и с PA-блоком можно иметь два линка к разным провайдерам, и оба будут анонсить маршрут, но на это должна быть добрая воля у резервного аплинка.

[Дятел]

Ну так это всего лишь вопрос денег. Или "правильных" контактов с LIR'ом, как вариант ;)  

угу, если он у LIRа есть....))

 

а автономку получать - это ещё более сложный вопрос, чем PI-блок...с ними совсем плохо по объективным причинам.

[MaxSavin]

провайдеры, у которыйх  своя автономная система, и которые LIR, должны держать full.

???

LIR - это всего лишь статус регистратора. Это дает ПРАВО (не не обязанность) получать AS для себя и переправлять в RIPE (в случае Европы) заявки для других. Так что никакой взаимосвязи с BGP тут нет вообще :)

 

вторичные провайдеры, получающие PA блоки - не должны, маршруты на их сети являются внутренними.

Тех, кого вы так обозвали :) "вторичными провайдерами", могут и сами иметь иои не иметь статус LIR, иметь или не иметь PI-блок, иметь или не иметь AS (и зависимости между этими понятиями только одна: чтобы получить и использовать номер AS - нужно (доп.: фактически) иметь PI-блок).

 

если я правильно помню, минимальная сетка у LIR - /19 (16 сеток С)

Ну получение PI-адресации из блоков RIPE тоже никто не отменял. Причем, любых размеров.

 

в принципе, есть RFC, по которой и с PA-блоком можно иметь два линка к разным провайдерам, и оба будут анонсить маршрут, но на это должна быть добрая воля у резервного аплинка.

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

[MaxSavin]

/19 (16 сеток С)

... не особо принципиально в контексте данной темы, на /19 - это, все же, 32 тех самых C :)

[Дятел]

LIR - это всего лишь статус регистратора. Это дает ПРАВО (не не обязанность) получать AS для себя и переправлять в RIPE (в случае Европы) заявки для других. Так что никакой взаимосвязи с BGP тут нет вообще  

LIR получает блок /19 и из него раздаёт блоки по удовлетворённым заявкам.

А теперь расскажите мне, кто будет маршрутизировать эти сетки, если LIR не будет иметь своей автономки? Ведь этот блок /19 направляют именно ему...

Ну получение PI-адресации из блоков RIPE тоже никто не отменял. Причем, любых размеров.  

Есть прямая рекомендация не выдавать PI для уменьшения full bgp.

Блоки меньше /19 не должны ходить, в идеале.

[Дятел]

/19 (16 сеток С)

... не особо принципиально в контексте данной темы, на /19 - это, все же, 32 тех самых C :)

виноват, исправлюсь )))

[ivan77]

Есть прямая рекомендация не выдавать PI  для уменьшения full bgp.

Блоки меньше /19 не должны ходить, в идеале.

А фактически есть всего два варианта организации линка с двумя провайдерами БЕЗ получения статуса LIR (что весьма часто нужно).

Либо тебе выделяют PA-блок, и ставят ему "more specific route" (на что провайдеры ни разу не слышал, чтобы шли), либо ты получаешь PI блок и "лишние" записи в full view (но во втором случае RIPE пишет, что не все держат full view, и все провайдеры имеют право игнорировать маршруты PI, т.е. получателя сразу предупреждают, что части/из части интернета его система не получит доступа, однако фактически у всех основных full view есть). А вот какой метод RIPE рекомендует в КОНКРЕТНЫЙ МОМЕНТ времени, зависит от текущей политики и конкретно лица, принимающего решение. Сначала давали PI, потом не давали, потом опять давали... Однако по прежнему оба решения реально получить. Вот как - это уже вопрос... :)

[Дятел]

тебе выделяют PA-блок, и ставят ему "more specific route" (на что провайдеры ни разу не слышал, чтобы шли)

 

у меня ощущение, что со своим я бы договорился.

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

[MaxSavin]

LIR - это всего лишь статус регистратора. Это дает ПРАВО (не не обязанность) получать AS для себя и переправлять в RIPE (в случае Европы) заявки для других. Так что никакой взаимосвязи с BGP тут нет вообще  

LIR получает блок /19 и из него раздаёт блоки по удовлетворённым заявкам.

А теперь расскажите мне, кто будет маршрутизировать эти сетки, если LIR не будет иметь своей автономки? Ведь этот блок /19 направляют именно ему...

см.:

1. http://www.nic.ru/ip-reg/service/FAQ/as.html, п.7

2. http://ripe.net/ripe/docs/ir-policies-proc...ures.html#pa_pi

3. объект "route:".

 

Ну получение PI-адресации из блоков RIPE тоже никто не отменял. Причем, любых размеров.  

Есть прямая рекомендация не выдавать PI для уменьшения full bgp.

Блоки меньше /19 не должны ходить, в идеале.

Именно рекомендация :) По факту - память дешевая, и прецедентов зарезания анонсов /24 я уже давноооо не встречал.

[ivan77]

И все-таки, хотелось бы уточнить про Киски...

Как там с биллингом (у нас, например, счас апача поднята и через mySQL постоянно юзерам текущий баланс кажет...)?

 

А NAT, что, на отдельном серваке делать?

 

И в чем принципиальное отличие 3550EI от 3750EI?

[Дятел]

Цитаты про PI:

 

Следует настоятельно рекомендовать выбор в пользу PA адресов.

 

При заключении договора на PI сети необходимо давать такое пояснение:

Использование адресов возможно до тех пор, пока в них есть необходимость. Использование данных адресов не означает, что любые хосты Интернета будут доступны из Вашей сети, а Ваша сеть будет доступна для них. Очевидно, что маршрутизация PI-сети потребует дополнительных затрат, в отличие от PA-сети. Также существует вероятность, что постепенно станет невозможно маршрутизировать относительно малое количество PI-адресов по большей части Интернета. Рекомендуем обратиться за консультацией по использованию адресного пространства данного типа к какому-нибудь опытному сервис-провайдеру.

 

Этот тип адресов распределяется крайне редко, и только после тщательного изучения запроса. Подблоки (sub-allocations) не могут быть выделены из блоков этого типа.

 

RIPE NCC больше не распределяет PI блоками. У большинства LIR не имеется блоков, чтобы выделить пользователям PI адреса. Если кто-нибудь из клиентов пожелает получить сеть таких адресов, LIR может переслать заявку в RIPE NCC. Поддержка со стороны LIR заключается также в помощи при оформлении заявки и регистрации объектов в базе. RIPE NCC выделит сети, если найдет это необходимым.