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

[galaxy 3]

День добрый, С праздником, Христос Воскрес!!!

 

На данный момент BRAS и NAS - один сервер, в среду получаю еще один канал во внешний мир.

Соответственно разношу на разные сервера.

 

BRAS - ip 91.xxx.xxxx.2 (на сетевой, смотрящей на NAS, WEB, MAIL)

NAS - ip 91.xxx.xxxx.3

WEB - ip 91.xxx.xxxx.7

MAIL - ip 91.xxx.xxxx.8

 

BRAS с bgpd (quagga) за ним NAS, WEB, MAIL.

Конфиг для bgpd возьму отсюда http://local.com.ua/...-2-uplink-full/

Остается вопрос как организовать маршрутизацию для NAS, WEB, MAIL - через ospfd или статику.

 

Статика - на сетевой карте BRAS, которая смотрит во внутрь прописываю адресс 91.ххх.ххх.2 из своей АС и тупо гейтвей на него на NAS (хомяки с реал IP), WEB, MAIL

 

Если через ospfd то подойдет ли конфиг для BRAS:

 

bgp.conf

hostname AS5XXXX
password
enable password
log file /var/log/quagga/bgpd.log
!
router bgp 5XXXX
bgp router-id 91.xxx.xxx.1
bgp log-neighbor-changes
no synchronization
network 91.xxx.xxx.0/22
.
.
.
и далее по сcылке выше
!

 

ospf.conf

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

 

и надо-ли поднимать ospf на NAS, WEB, MAIL?

[NiTr0 584]

Поднимайте оспф везде, приоритеты давайте основным серверам (бордюр, биллинг) - которые наиболее стабильны и наиболее критичны (т.к. падение DR приводит к перестройке таблицы маршрутов, с сопутствующими лагами)

[Гайджин 574]

Поднимайте оспф везде...

А зачем ему динамическая маршрутизация, если всего хостов меньше чем пальцев на руке и из за этих хостов похоже ничего выглядывать не будет?

[KaYot 3 709]

+1, статикой default route прописать на всех серверах да и все. На самом бордюре вообще ничего не нужно.

Да, называть border BRASом как-то нехорошо.

[Гайджин 574]

Да назвать то ладно, а вот исполнять - это да, это сурово.

[NiTr0 584]

Поднимайте оспф везде...

А зачем ему динамическая маршрутизация, если всего хостов меньше чем пальцев на руке и из за этих хостов похоже ничего выглядывать не будет?

1) на будущее 2) выделять реальные ИП хостам удобнее с динамикой, поднял адрес /32 - и пришло счастье. Пока сеть маленькая - оно не заметно, а станет 2 браса, да кучка сервисов на разных IP, да еще виртуализация если где-то, да еще что-то - тут-то оспф и сгодится весьма сильно... Почему бы сразу не настроить и не ознакомиться с возможными граблями?

[Гайджин 574]

Ага... Я понял... - Вы предлагаете жить по принципу "завтрашнее похмелье уже сегодня". Т.е. лучше перебдеть чем недобдеть.

Но вот только беда в том, что по условиям задачи брас-бордер, а соответственно никаких /32 анонсов не намечается, да и остальные сопутствующие сервера многообразием ip не блещут. Так что оптимально, при -данной конфигурации, воспользоваться статической маршрутизацией. Ну, конечно, если надо все же ехать, а не шашечки (подрочить на ospf - кстати почему именно ospf?). Ну а если изменятся условия, то изменятся и оптимальные решения.

[zulu_gluk 23]

я тоже думаю что извращаться с динамикой нет смысла, сделать ДМЗ /26-/27 и туда все сервисы

[prototip 284]

Честно говоря не понятно зачем вы разносите на разные тазики ваши сервисы , вернее мне понятно зачем , просто подключение второго канала на бордере не есть повод разнесения ваших сервисов . По поводу оспф - бред , тут чел не понимает как ему кусок подсети отрезать из блока собственного , а вы ему оспф сватаете ? В уме ли вы товарищи ? Думаю на его "сервисы" после разнесения будет и 28 много , насколько я понял будет бордер , 1 или 2 наса , ну и тазик с биллингомпочтойднсом .... Вы вот лучше позаботьтесь о вашей почте и обратной зоне днс для ваших адресов , ато глядишь почта перестанет ходить .

Просто человек стал насколько я понял перед банальной задачей маршрутизации и деления своего блока адресов на подсети . Во всяком случае я так понял . В этом вопросе очень помогает утилита ipcalc на линухе . Гугл по ипкалькулятору поможет . Стандартный вопросик однако , не зря райп задает вумные вопросы по типу как будете делить ваше адресное пространство . Теперь вы подошли к вопросу какой кусок вы будете выдавать клиентам , а какую подсеть например для служебных целей , а потом глядишь найдется "бизнес" абонент которому нужно быдет дать кроме нета еще и небольшую подсеть . Все ведь зависит сколько вы адресов "напросили" у райпа ...

[Гайджин 574]

Согласно первого поста есть один один сервер доступа, он же пограничник, сетевой сторедж, веб и мэйл - все. Так что все тривиально.

[galaxy 3]

Честно говоря не понятно зачем вы разносите на разные тазики ваши сервисы , вернее мне понятно зачем , просто подключение второго канала на бордере не есть повод разнесения ваших сервисов . По поводу оспф - бред , тут чел не понимает как ему кусок подсети отрезать из блока собственного , а вы ему оспф сватаете ? В уме ли вы товарищи ? Думаю на его "сервисы" после разнесения будет и 28 много , насколько я понял будет бордер , 1 или 2 наса , ну и тазик с биллингомпочтойднсом .... Вы вот лучше позаботьтесь о вашей почте и обратной зоне днс для ваших адресов , ато глядишь почта перестанет ходить .

Просто человек стал насколько я понял перед банальной задачей маршрутизации и деления своего блока адресов на подсети . Во всяком случае я так понял . В этом вопросе очень помогает утилита ipcalc на линухе . Гугл по ипкалькулятору поможет . Стандартный вопросик однако , не зря райп задает вумные вопросы по типу как будете делить ваше адресное пространство . Теперь вы подошли к вопросу какой кусок вы будете выдавать клиентам , а какую подсеть например для служебных целей , а потом глядишь найдется "бизнес" абонент которому нужно быдет дать кроме нета еще и небольшую подсеть . Все ведь зависит сколько вы адресов "напросили" у райпа ...

 

Да нет , разделить то я разделю, выделю, действительно пока после почтовика и веба никого нет, клиенты только после наса. Вот и возникает вопрос, сейчас действительно статикой проще, выделил блок из своей подсети /26 и этого пока с головой хватит.

на бордюре на сетевой в о внутрь прописать 91.ххх.ххх.2/26 на нас 91.ххх.ххх.3/26, мейл - 91.ххх.ххх.7/26, веб - 91.ххх.ххх.8/26 у них у всех шлюзом бордер 91.ххх.ххх.2/26.

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

[galaxy 3]

+1, статикой default route прописать на всех серверах да и все. На самом бордюре вообще ничего не нужно. Да, называть border BRASом как-то нехорошо.

Да действительно, нехорошо получилось, сори.

[Гайджин 574]

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

[KaYot 3 709]

Динамическая маршрутизация вам понадобится только тогда, когда будет >1 NAS'a и клиентам будут выдаваться динамически реальные IP. При любом числе сервисов всякие ospf'ы нафиг не нужны, при использовании NAT и нескольких серверов доступа тоже..

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

[galaxy 3]

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

цитата из моего первого поста (заменю только BRASна бордер) :

На данный момент бордер и NAS - один сервер, в среду получаю еще один канал во внешний мир.
Соответственно разношу на разные сервера.

бордер - ip 91.xxx.xxxx.2 (на сетевой, смотрящей на NAS, WEB, MAIL)
NAS - ip 91.xxx.xxxx.3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - это сейчас одним сервером, их то и разношу
WEB - ip 91.xxx.xxxx.7
MAIL - ip 91.xxx.xxxx.8
бордер с bgpd (quagga) за ним NAS, WEB, MAIL.

ничего ниоткуда не всплывает

[galaxy 3]

Динамическая маршрутизация вам понадобится только тогда, когда будет >1 NAS'a и клиентам будут выдаваться динамически реальные IP. При любом числе сервисов всякие ospf'ы нафиг не нужны, при использовании NAT и нескольких серверов доступа тоже..

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

 

Уже сейчас NAS выдает динамические реальные IP, и готовлю второй, вот поэтому и возник данный вопрос. Из вашего поста получается что ospf необходимо поднимать только между бордером и NAS, а почтовик и веб оставить с статическими маршрутами?

[galaxy 3]

+1, статикой default route прописать на всех серверах да и все. На самом бордюре вообще ничего не нужно. Да, называть border BRASом как-то нехорошо.

Да действительно, нехорошо получилось, сори.

Все-таки Пасха..., немножко притормозил....

[KaYot 3 709]

Уже сейчас NAS выдает динамические реальные IP, и готовлю второй, вот поэтому и возник данный вопрос. Из вашего поста получается что ospf необходимо поднимать только между бордером и NAS, а почтовик и веб оставить с статическими маршрутами?

Конечно. Для серверов ничего менять не нужно, они в одном влане с бордером и будут там жить всегда.

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

[Гайджин 574]

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

А вот если стоит задача выдавать белую статику, то да - без динамической маршрутизации между бордером и серверами доступа не обойтись. Но только не факт, что протоколом динамической маршрутизации должен стать OSPF.

[Гайджин 574]

...

цитата из моего первого поста (заменю только BRASна бордер) :

 

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

...

 

ничего ниоткуда не всплывает

Я конечно дико извиняюсь...

Однако даже если все приколы с терминологией отбросить, то Вы хоть меня убейте, но я всю оставшуюся мне жизнь буду воспринимать выделенное жирным так: "на данный момент бордер и нас это один сервер".

 

p.s. убить нельзя помиловать...

[NiTr0 584]

Ага... Я понял... - Вы предлагаете жить по принципу "завтрашнее похмелье уже сегодня". Т.е. лучше перебдеть чем недобдеть.

Если ospf вводить - почему бы не ввести его везде?

 

Но вот только беда в том, что по условиям задачи брас-бордер, а соответственно никаких /32 анонсов не намечается,

Внимательно читать не пробовали? В первом же посте ТС говорит, что будет разносить брас и бордюр на 2 разные железки. Т.е. статика уже отпадает, по-хорошему.

 

Уже сейчас NAS выдает динамические реальные IP, и готовлю второй, вот поэтому и возник данный вопрос. Из вашего поста получается что ospf необходимо поднимать только между бордером и NAS, а почтовик и веб оставить с статическими маршрутами?

Статика в теории сработает, но надо будет прописывать статикой и на бордере, и дефолт на серверах. + весь локальный трафик при этом будет гулять до серверов через бордер - что есть криво. И это неприменимо в ситуации, когда есть канал на мир и украину отдельно, на разных бордерах, либо если есть 2 бордера (хотя там не через оспф уже а через ibgp надо транслировать маршруты, как минимум - с бордеров, для локальных ip можно и оспф/рип).

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

[Гайджин 574]

Если ospf вводить - почему бы не ввести его везде?

Ну хотя бы потому, что согласно условий задачи "если вводить" - это еще вопрос.

Внимательно читать не пробовали? В первом же посте ТС говорит, что будет разносить брас и бордюр на 2 разные железки. Т.е. статика уже отпадает, по-хорошему.

Пробовал. - А Вы? Прочтите внимательно предыдущее сообщение, а так же найдите в первом посте слово "бордюр". Ну и на закуску расшифруйте что есть "BRAS и NAS - один сервер"

Я понимаю, что "все смешалось в доме Облонских" и мы говорим с ТСом несколько на разных языках - но поймите это и Вы.

Статика в теории сработает, но надо будет прописывать статикой и на бордере, и дефолт на серверах. + весь локальный трафик при этом будет гулять до серверов через бордер - что есть криво.

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

Что же касается локального трафика - нет не будет он ходить через бордер. Ибо по дефолту что?

И это неприменимо в ситуации, когда есть канал на мир и украину отдельно, на разных бордерах, либо если есть 2 бордера (хотя там не через оспф уже а через ibgp надо транслировать маршруты, как минимум - с бордеров, для локальных ip можно и оспф/рип).

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

Все верно. - Печалька только одна, это фантазии которых не было в условиях задачи.

[NiTr0 584]

Ну хотя бы потому, что согласно условий задачи "если вводить" - это еще вопрос.

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

 

Пробовал. - А Вы? Прочтите внимательно предыдущее сообщение, а так же найдите в первом посте слово "бордюр". Ну и на закуску расшифруйте что есть "BRAS и NAS - один сервер"

Я понимаю, что "все смешалось в доме Облонских" и мы говорим с ТСом несколько на разных языках - но поймите это и Вы.

Все там понятно из контекста.

 

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

Если квагга ипанется вдруг, ипанется и bgp, и добраться до серверов можно будет только через ssh с бордюра, и то если на бордюре есть дефолт роут.

 

Что же касается локального трафика - нет не будет он ходить через бордер. Ибо по дефолту что?

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

 

Все верно. - Печалька только одна, это фантазии которых не было в условиях задачи.

А я где-то писал, что это всенепременно должно быть применимо в конкретных условиях?

Неведомо же, куда ТС еще один канал заводить решил.

[Gang 5]

ТС, в чем суть задачи то?

 

Есть у Вас один блок реальников, скажем 111.111.111.0/24. И есть один НАС. Вы с бордера делаете статикой роут для этой подсети на него, а на насе делаете дефолт роут на бордер. У вас появляется еще один нас, но адресация никак не меняется. Тогда - логично вы подминаете OSPF между брасом и двумя насами и на бордере делаете дефолт ориджинейт.

 

P.S. А Вас случайно не Александр зовут?

[Гайджин 574]

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

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

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

Ну и на закуску расшифруйте что есть "BRAS и NAS - один сервер"

Все там понятно из контекста.

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

Если квагга ипанется вдруг, ипанется и bgp, и добраться до серверов можно будет только через ssh с бордюра, и то если на бордюре есть дефолт роут.

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

Что же касается локального трафика - нет не будет он ходить через бордер. Ибо по дефолту что?

По дефолту на вебе и т.п. - бордюр. Т.е. - все через бордюр шурует. Вопрос - накой?

Не правильный ответ - по дефолту icmp redirect включен, со всеми вытекающими последствиями.

 

Все верно. - Печалька только одна, это фантазии которых не было в условиях задачи.

А я где-то писал, что это всенепременно должно быть применимо в конкретных условиях?

Неведомо же, куда ТС еще один канал заводить решил.

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

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