Маршрутизация между BRAS - NAS, WEB, MAIL

[NiTr0 583]

Можно. И даже без печалей. - Если статики нет.

Но это не тот случай.

Не спорю, что можно. Только печали будут в любом случае - и неэффективное использование адресного пространства при краше одного из серверов (особенно смешно будет если абонов после краша окажется больше, чем доступных адресов), и принципиальная невозможность выдачи статических ип, и прочие "прелести".

 

Ага... - Фразу похоже расшифровать таки не можете.

Прекрасно все расшифровывается. Ну попутал человек брас и бордюр. Если вам этого не видно из контекста сообщения - пичалька... Или вы просто попридираться к мелочам решили?

 

Однобоко мыслите. - А если квагга ипнется не на бордере?

Дефолт роут (можно даже с большой метрикой, чтобы с дефолтом из квагги не конфликтовал) с кваггой что, уже неприменим? ssh с бордюра что, тоже неприменимо? Не пытайтесь высматривать проблемы там, где их нет.

 

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

И при этом был бы прав - в каких то иных условиях.

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

[galaxy 3]

Привожу схему сети.

Попытался поднять ospf между бордером и NAS-ом

файл конфига с NAS

 

ospfd.conf

hostname ospfd-gw1
password
enable password
log file /var/log/quagga/ospfd.log
log stdout
service password-encryption
!
interface em0
!
interface em1
!
interface lo
!
router ospf
ospf router-id 91.ххх.ххх.3
redistribute connected
redistribute static
network 91.ххх.ххх.0/22 area 0.0.0.0
neighbor 91.ххх.ххх.2
default-information originate
!
!
line vty
!

 

zebra.conf

hostname zebra-gw1
password
enable password
log stdout
log file /var/log/quagga/zebra.log
!
interface em1
ip address 172.16.0.1/22
ip address 10.172.16.1/24
!
interface em0
ip address 91.xxx.xxx.3/22
!
interface lo0
!
!
access-list PPPOE_STATIC_IP permit 91.xxx.xxx.0/22
!
route-map redistribute-connected permit 10
match ip address PPPOE_STATIC_IP
!
ip route 10.0.0.0/8 Null0 254
ip route 172.16.0.0/12 Null0 254
ip route 192.168.0.0/16 Null0 254
!
ip forwarding
!
line vty
exec-timeout 0 0
!

 

конфиг с bordera

ospfd.conf

hostname ospfd-gw0
password
enable password
log file /var/log/quagga/ospfd.log
log stdout
service password-encryption
!
interface em0
!
interface em1
!
interface ale0
!
interface lo
!
router ospf
ospf router-id 91.xxx.xxx.2
redistribute connected
redistribute static
network 91.xxx.xxx.0/22 area 0.0.0.0
neighbor 91.xxx.xxx.3
default-information originate
!
line vty
!

 

zebra.conf

hostname zebra-gw0
password
enable password
log stdout
log file /var/log/quagga/zebra.log
!
interface em1
ip address 91.xxx.xxx.2/22
!
interface em0
ip address 212.xxx.xxx.74/30
!
interface ale0
ip address 195.xxx.xxx.81/30
!
interface lo0
!
!
ip route 10.0.0.0/8 Null0 254
ip route 172.16.0.0/12 Null0 254
ip route 192.168.0.0/16 Null0 254
!
ip forwarding
!
line vty
exec-timeout 0 0
!

 

 

C NAS все пингуется, трасситуется, а с клиентского подключения дальше адресса pppoe-сервера (172.16.12.1) никуда не ходит. Получается не pppoe-сесии на ngX-интерфейсах не получают маршруты. Подскажите где наступил на грабли.

[galaxy 3]

И по поводу BRAS-NAS, прошу прощения у старожылов форума, дабы прекратить возникшую дисксию, действительно, после ночи в церкви, кучи родственников, голова была немножко квадратной формы

Посему действительно нечистая попутала, в первом посте должно было иметь место BORDER - NAS. Еще раз прошу извенить за опечатку.

[Гайджин 574]

Привожу схему сети.

Попытался поднять ospf между бордером и NAS-ом

файл конфига с NAS

У Вас секция

access-list PPPOE_STATIC_IP permit 91.xxx.xxx.0/22

!

route-map redistribute-connected permit 10

match ip address PPPOE_STATIC_IP

не в том файле конфигурации на брасе. Разговор идет о редистрибьюции коннектнутых маршрутов в оспф /32 префиксами? - ну так и описывайте это в ospfd.conf, причем тут зебра.

Ну и опять же, неправильно оформлен роутмап:

access-list PPPOE_STATIC_IP permit 91.xxx.xxx.0/22

!

route-map redistribute-connected permit 10

match ip address PPPOE_STATIC_IP

!

route-map redistribute-connected deny 100

!

и редистрибьют:

redistribute connected route-map redistribute-connected

 

Ну и концептуально - пихать все в одну арию, имхо, грешно.

[NiTr0 583]

ip r в студию. должны быть маршруты типа таких:

 

192.168.123.0/24 via 192.168.255.83 dev vlan1  proto zebra  metric 20

 

ну и конфиги с живого тазика

 

zebra.conf:

hostname testpoint
password <passwd>
enable password <passwd2>
log stdout
!
interface vlan1
bandwidth 1000000
multicast
!
line vty
!

 

ospfd.conf:

 

hostname testpoint
password <passwd>
enable password <passwd2>

log stdout
!
router ospf
auto-cost reference-bandwidth 1000
redistribute connected
redistribute static
network 192.168.255.64/27 area 0.0.0.0
!
line vty
!

 

Соседей принудительно указывать не обязательно (ибо мультикастом общаются). Подсеть указывать обязательно. password/enable password - для конфигурирования через телнет без ребута.

Не забыть на бордюре маршрут на вашу AS завернуть в null.

[Гайджин 574]

Не спорю, что можно. Только печали будут в любом случае - и неэффективное использование адресного пространства при краше одного из серверов (особенно смешно будет если абонов после краша окажется больше, чем доступных адресов), и принципиальная невозможность выдачи статических ип, и прочие "прелести".

Это не "неэффективное использование адресного пространства", а вава в голове у проектировщика - если такое случится.

Но эти все негоразды выходят за рамки обсуждаемой задачи.

 

Дефолт роут (можно даже с большой метрикой, чтобы с дефолтом из квагги не конфликтовал) с кваггой что, уже неприменим?

Ну наконец то - снизошло! - Ну так а я Вам что в 22-м сообщении написал?

 

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

И при этом был бы прав - в каких то иных условиях.

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

Вот он сейчас, по вашему совету в оспф полез - вот Вы теперь и объясняйте как адресное пространство правильно кроить и по ариям рассовывать. Ибо у него теперь все коннектнутые маршруты интра-ареа получаются.

А можно было обойтись тупо статикой.

[NiTr0 583]

Это не "неэффективное использование адресного пространства", а вава в голове у проектировщика - если такое случится.

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

 

Ну наконец то - снизошло! - Ну так а я Вам что в 22-м сообщении написал?

Я вообще-то о дефолт роуте в квагге, либо - параллельно с квагговским, но с большей метрикой. Который будет работать при падении квагги.

 

Вот он сейчас, по вашему совету в оспф полез - вот Вы теперь и объясняйте как адресное пространство правильно кроить и по ариям рассовывать. Ибо у него теперь все коннектнутые маршруты интра-ареа получаются.

А можно было обойтись тупо статикой.

Да что объяснять-то, есть у него подсеть 91.xx.xx.0/27 (/28) между серверами - ее как area 0 объявить, и делов-то. Хотя проще внутри пользовать серую адресацию а на серверах поднимать белые адреса с маской /32, несколько ip сэкономятся.

[Гайджин 574]

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

Любезный, Вы с ветки на ветку не прыгайте. - Разговор был о недопущении исчерпания пула адресов браса, если что. Так вот что бы этого не произошло брас (по производительности) должен склеиться раньше чем исчерпается пулл.

Я вообще-то о дефолт роуте в квагге, либо - параллельно с квагговским, но с большей метрикой. Который будет работать при падении квагги.

Статик роут - он и в Африке статик роут.

Да что объяснять-то, есть у него подсеть 91.xx.xx.0/27 (/28) между серверами - ее как area 0 объявить, и делов-то. Хотя проще внутри пользовать серую адресацию а на серверах поднимать белые адреса с маской /32, несколько ip сэкономятся.

Ну так вперед - подписали чувака, теперь конфиги правьте.

Касаемо /32 префиксов - Вы еще не замечали, что подобное удобство может стать проблемой?

[NiTr0 583]

Любезный, Вы с ветки на ветку не прыгайте. - Разговор был о недопущении исчерпания пула адресов браса, если что. Так вот что бы этого не произошло брас (по производительности) должен склеиться раньше чем исчерпается пулл.

Бред (с). Что, подбирать медленное железо или специально добавлять тупые правила файрвола, чтобы при приближении нагрузки к пиковой брас начало таращить, и абоны начали крыть матом ваш саппорт?

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

А хочется странных извращений со статической маршрутизацией и фиксированными пулами - можете ограничить число коннектов (для пппое). Хотя все равно это еще не значит, что при аварии одного из брасов на всех абонов хватит половины всего диапазона адресов.

 

Касаемо /32 префиксов - Вы еще не замечали, что подобное удобство может стать проблемой?

Ни разу не замечал никаких неудобств от /32 адресов. А вот преимуществ - валом. Простая миграция адреса (в целях резервирования к примеру, или при замене железа), в т.ч. между железками, находящимися в разных подсетях как пример.

[Гайджин 574]

Бред (с).

Любезный, не Вам NEP-а цитировать. - Ибо в таком случае Вас его цитатами можно просто с ног до головы засыпать.

Что, подбирать медленное железо или специально добавлять тупые правила файрвола, чтобы при приближении нагрузки к пиковой брас начало таращить, и абоны начали крыть матом ваш саппорт?

Ух тыж Бл#. - Какое у Вас чудное мышление.

А по другому никак нельзя?

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

А хочется странных извращений со статической маршрутизацией и фиксированными пулами - можете ограничить число коннектов (для пппое). Хотя все равно это еще не значит, что при аварии одного из брасов на всех абонов хватит половины всего диапазона адресов.

Какое отношение это имеет к теме? Т.е. какой прикладной смысл в этих Ваших фантазиях?

Касаемо /32 префиксов - Вы еще не замечали, что подобное удобство может стать проблемой?

Ни разу не замечал никаких неудобств от /32 адресов. А вот преимуществ - валом. Простая миграция адреса (в целях резервирования к примеру, или при замене железа), в т.ч. между железками, находящимися в разных подсетях как пример.

Как сказал бы NEP - "вы плохо воспринимаете информацию..."? Слово "проблема" и слово "неудобство" однокоренные? Вы чего ахинею несете?

Вы не видите проблему в n-килобаксов, когда такие префиксы перестают лезть в таблицу маршрутизации? (применение вычурных схем адресации и маршрутизации, да - в данном случае очень даже динамической, с применением атракторов (по сути статических маршрутов) позволяют истратить эти деньги не сейчас, а через несколько лет.) - В таком случае Вы дальше своего носа не видите. А нос Ваш размером с 2-3К пациентов и это объясняет Ваш подход.

[NiTr0 583]

Ух тыж Бл#. - Какое у Вас чудное мышление.

А по другому никак нельзя?

А как тогда понимать ваше

брас (по производительности) должен склеиться раньше чем исчерпается пулл.

?

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

 

 

Какое отношение это имеет к теме? Т.е. какой прикладной смысл в этих Ваших фантазиях?

Ровно такое же, как и ваше утверждение о том, что более одного браса будет "прекрасно" работать со статической маршрутизацией.

 

Как сказал бы NEP - "вы плохо воспринимаете информацию..."? Слово "проблема" и слово "неудобство" однокоренные? Вы чего ахинею несете?

Вы не видите проблему в n-килобаксов, когда такие префиксы перестают лезть в таблицу маршрутизации? (применение вычурных схем адресации и маршрутизации, да - в данном случае очень даже динамической, с применением атракторов (по сути статических маршрутов) позволяют истратить эти деньги не сейчас, а через несколько лет.) - В таком случае Вы дальше своего носа не видите. А нос Ваш размером с 2-3К пациентов и это объясняет Ваш подход.

1) Как на эту ситуацию повлияют аж 5-10-20 IP для локальных сервисов?

2) Какое отношение это имеет к теме? У ТС есть особо убогая железка, которая не может пережевать 5-10 дополнительных маршрутов?

[KaYot 3 606]

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

 

IMHO ospf для таких вещей применять бессмысленно и даже вредно. Нам пришлось мигрировать с ospf на rip где-то после 2к абонентов онлайн, зебра начинала жрать больше чем все остальные сервисы вместе взятые.. С rip работает как часы, 4 NASa сливают маршруты бордеру.

Конфиг с бордера(циска, но это не принципиально)

router rip
version 2
passive-interface default
network 91.0.0.0

Конфиг с насов

zebra.conf

hostname nas4.xx
password xxx
enable password xxx
service password-encryption
log file /var/log/quagga/zebra.log
!
interface eth0.2
multicast
!
line vty
exec-timeout 30 0
!

ripd.conf

hostname nas4-rip
password xx
enable password xx
log file /var/log/quagga/ripd.log
service password-encryption
!
interface eth0.2
!
router rip
version 2
passive-interface default
no passive-interface eth0.2
network eth0.2
distribute-list private-only in eth0.2
redistribute connected route-map rip-map
!
access-list zeus permit 91.xx/24
access-list zeus permit 91.yy/23
access-list zeus permit 94.zz/19
access-list zeus deny any
!
route-map rip-map permit 1
match ip address zeus
!
access-list private-only deny any
!
line vty
exec-timeout 30 0
!

 

Да и конфиги получаются проще.

[Гайджин 574]

А как тогда понимать ваше

брас (по производительности) должен склеиться раньше чем исчерпается пулл.

?

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

Так и понимать, что размер пула должен быть в балансе с производительностью железа. А уж количество брасов должно быть в балансе с количеством пациентов, с учетом коэффициента резервирования.

Т.е. Вы как то реверсно мыслите - не брас под адреса, а адреса под брас подбираются вообще то.

Какое отношение это имеет к теме? Т.е. какой прикладной смысл в этих Ваших фантазиях?

Ровно такое же, как и ваше утверждение о том, что более одного браса будет "прекрасно" работать со статической маршрутизацией.

Мои утверждения хоть как то, не смотря на то что Вы постоянно в сторону тяните, касаются темы.

1) Как на эту ситуацию повлияют аж 5-10-20 IP для локальных сервисов?

2) Какое отношение это имеет к теме? У ТС есть особо убогая железка, которая не может пережевать 5-10 дополнительных маршрутов?

Молчел, Вы еврей?

[Гайджин 574]

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

Да не, я наверное тоже уже сворачиваться начну - ибо чувак в неадеквате, объясняй не объясняй, бес толку. Да и лениво уже.

IMHO ospf для таких вещей применять бессмысленно и даже вредно.

Воот! Наконец то пришел человек, который прочувствовал это на своей шкуре.

Нам пришлось мигрировать с ospf на rip где-то после 2к абонентов онлайн, зебра начинала жрать больше чем все остальные сервисы вместе взятые...

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

С rip работает как часы, 4 NASa сливают маршруты бордеру.

C rip-ом как то не сложилось - в режиме теста включили rip, все взлетело, а после 15 минут лету у свича оторвало башку и все рухнуло. Да свич конечно несколько неудачный, однако с ospf-ом летает (я пробовал на него сгружать около 4К анонсов по /32), а с rip-ом упал. На этом эксперименты и закончились.

[KaYot 3 606]

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

ospf с >2k активных маршрутов у нас работал только если все NASы разнести по отдельным зонам, но в случае если нужно всего лишь перебросить маршруты с N серверов на 1 маршрутизатор - схема избыточна и не нужна.

Rip 2 посоветовали ребята с НАГа, там у многих оно нормально работает с десятками тысяч абонентов. IS-IS говорят еще лучше для этого подходит, но rip заработал и эксперименты на том закончились.

[Гайджин 574]

ospf с >2k активных маршрутов у нас работал только если все NASы разнести по отдельным зонам, но в случае если нужно всего лишь перебросить маршруты с N серверов на 1 маршрутизатор - схема избыточна и не нужна.

Именно... Разнесено по разным ариям (NSSA) на нескольких маршрутизаторах. - Работает.

 

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

[NiTr0 583]

Так и понимать, что размер пула должен быть в балансе с производительностью железа. А уж количество брасов должно быть в балансе с количеством пациентов, с учетом коэффициента резервирования.

Т.е. Вы как то реверсно мыслите - не брас под адреса, а адреса под брас подбираются вообще то.

В нормальных условиях железо на брасе берется с запасом. Как минимум на 1/N при максимально наблюдаемом трафике, где N - кол-во брасов. Лучше - больше, дабы не было пиковых перегрузок при авариях, и для минимизации задержек и т.п. при загрузке проца порядка 100%. Это во-первых.

Во-вторых - повторюсь, ограничивать входящие коннекты полкой в 100% загрузки проца есть редкий идиотизм. Хотя бы потому, что при этом лаги юзерленда из-за 100% отжирания ресурсов ядром будут налицо - а это и дропы сессий, и т.п. прелести. И компетентность человека, такое рекомендующего - весьма спорный вопрос...

В-третьих, брас скукоживается не от сессий, а от pps. Который с сессиями собссно кореллирует, но с погрешностью +-лапоть, в зависимости от времени суток и времени года, погоды на улице, выхода новой серии популярного сериала, появления нового сетевого червя и т.п. И подгонка в этих условиях пула под мощность браса - бессмысленна и глупа по определению.

Продолжать, или таки осознали, что бред несете?

 

Мои утверждения хоть как то, не смотря на то что Вы постоянно в сторону тяните, касаются темы.

Особенно о прекрасно работающих на статике десятке брасов, ага.

 

Молчел, Вы еврей?

Нет, а вы? Или вам отвечать вопросом на вопрос можно?

[Гайджин 574]

Любезный, оставайтесь с Вашей бурной и бредовой фантазией в одиночестве...

 

p.s. Ось така ось фінгя малята. На добра ніч діти.

[galaxy 3]

Спасибо всем откликнувшимся, временно решение вопроса пришлось отложить.

Второй канал временно дали без BGP, пришлось вместо связки border-> nas,mail,web сотворить связку nas1, web, mail (с статической маршрутизацией и Real-IP) и nas2+pf-nat

Благо теперь можно экспериментировать в рабочее время с quagga, через сетевую, смотрящую на сервера.

После отладки обязательно віложу рабочие конфиги.

Еще ращ всем спасибо.

[KaYot 3 606]

Хотел бы я знать, как связаны каналы, NASы и маршрутизация..

[galaxy 3]

Хотел бы я знать, как связаны каналы, NASы и маршрутизация..

На NAS1 (quagga, bgp) на сетевой, что смотрит на доп сервера (mail,web...) прописал, 91.ххх.ххх.2/27, на mail -91.ххх.ххх.7/27, шлюз-91.ххх.ххх.2, на остальных по аналогии. к второму NAS не подвязывал, так-как все зоны ДНС уже анонсированы на мою АС