роутинг между vrf

Valery Lutoshkin написал(а) к Eugene Grosbein в Jan 17 00:23:44 по местному времени:

Нi, Eugene!

16 Jan 2017 19:22, Eugene Grosbein wrote to Valery Lutoshkin:
VL>> Я бы так не делал, и дело даже не в ликинге. Маршрутизация между серыми
VL>> и белыми адресами - это дорога в ад.
EG> Ничего подобного. На самом деле между белыми и серыми адресами внутри
EG> автономной системы разницы нет НИКАКОЙ.

Как любой костыль, этот требует подпорок по всей сети. И почему ты
ограничиваешься автономной системой? Оператор не в вакууме живет.

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

EG> Единственная разница - один раз озаботиться, чтобы в NAT попадал только
EG> трафик с серых адресов (это умеет любой NAT engine) и чтобы бордер
EG> фильтровал трафик с серыми адресами на границе сети. Всё.

Каждый бордер. На каждом стыке. На любой редистрибьюции.

VL>> Технически, конечно, ты так сделать можешь,
VL>> но это и тебе, и всем остальным людям, кто причастен сейчас или будет
VL>> причастен в сколь угодно отдаленном будущем к администрированию этой
VL>> сети, нужно будет помнить о том, что сделан вот такой вот косяк. Это
VL>> очень дорого в эксплуатации.
EG> Неправда.

Правда.

VL>> Но я бы так не делал.
EG> Вот-вот - это чистая вкусовщина.

Bye, Valery

--- GoldED+/W32-MINGW 1.1.5-b20150715

Valery Lutoshkin написал(а) к Anton Gorlov в Jan 17 00:28:50 по местному времени:

Нi, Anton!

18 Jan 2017 16:50, Anton Gorlov wrote to Valery Lutoshkin:
VL>> Не очень понимаю, в чем ты видишь проблему, что в DNS клиенты
VL>> приходят после ната. Ну приходят - и приходят. Если тебе не нужно
VL>> управлять респонсами на уровне per-client - то и пусть приходят. Если
VL>> нужно per-client - то добавить своим серверам дополнительный
VL>> виртуальный интерфейс с серым адресом гораздо правильнее.
AG> В общем случае да не проблема что идут после ната.
AG> Но с другой стороны если чт офиш найдёш кто флудит.

Ну опять же, если нат дает таблицу трансляций - в ней всё видно.

AG> 2 линк на сервере ещё больший гемморой, так как нужно будет рисовать
AG> таблицу роутинга ещё на самом сервере, что зло.

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

AG> В общем случае мне хотелось бы видить запросы из серой сети внутри моей AS
AG> на своих серверах без NAT-а. Не на всех но на основных.

Ну если хочешь - кто ж тебя остановит :)

VL>> Но если тебе прямо хочется сделать так, как ты описал - то сделать
VL>> это можно, никаких технических препятствий нет. Не забыть только
VL>> обеспечить и обратные маршруты - серверы должны будут знать, куда
VL>> отправлять пакеты для серых адресов, если у них просто дефолт в белый
VL>> vrf - придется еще и ликать серые сети в белый vrf.
VL>> Но я бы так не делал.
AG> Да. Но есть некотоыре белые подсети..не все..куда хотелось бы ходить без
AG> ната. Я согасен даже вынести их в отдельный vrf.

Просто представь себе таблицы маршрутизации, которые у тебя будут. Если они
тебе покажутся логически комфортными - ну почему и нет. Как говорится, think
like a router.

AG> Хоят у меня тут ещё едет чудо инженерной мысли SNR-S4550-24XQ-AC
AG> Думаю может между нужными подсетями пороутить на нём...?

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

Bye, Valery

--- GoldED+/W32-MINGW 1.1.5-b20150715

Anton Gorlov написал(а) к Valery Lutoshkin в Jan 17 11:05:40 по местному времени:

Привет Valery!

21 янв 17 года (а было тогда 00:28)
Valery Lutoshkin в своем письме к Anton Gorlov писал:

VL>>> дополнительный виртуальный интерфейс с серым адресом гораздо
VL>>> правильнее.
AG>> В общем случае да не проблема что идут после ната.
AG>> Но с другой стороны если чт офиш найдёш кто флудит.
VL> Ну опять же, если нат дает таблицу трансляций - в ней всё видно.

То каконо это выдаёт..отдельная история. Redback SE100 логи ната очень интересные.
По ним фиг найдёшь кто из 20 серых был заNATен в такой-то белый.
А учитывая что в 1 белый натятся 20 серых у меня... найти кто етсь кто практически нереально по логу ната. Только по netflow кое-как можно отследить, зная dst и время..ну и в данном случае глядя на pps/количесво трафика (у флудераста они будут таки выше чем у обычных юзеров).

AG>> 2 линк на сервере ещё больший гемморой, так как нужно будет
AG>> рисовать таблицу роутинга ещё на самом сервере, что зло.
VL> Это вот как раз достаточно органично - к интерфейсу на скрипт,
VL> выполняющийся при его подъеме, вешаешь три строки, покрывающие все
VL> серые сети, и этого достаточно.

В рамках 1 сервреа да. Но кога их больше 1.. при каком либо измении надо будет не забывать править скрипт накаждом сервере. Можно его коненчо в puppet загнать... но всё равно как-то не комильфо. Я считаю что на серверах должен быть 1 маршрут,а всё остальное на самом маршрутизаторе должно расскидываться.

AG>> В общем случае мне хотелось бы видить запросы из серой сети
AG>> внутри моей AS на своих серверах без NAT-а. Не на всех но на
AG>> основных.
VL> Ну если хочешь - кто ж тебя остановит :)

Уху. Но вот пока не могу выбрать из 2 зол...

VL> Просто представь себе таблицы маршрутизации, которые у тебя будут.
VL> Если они тебе покажутся логически комфортными - ну почему и нет. Как
VL> говорится, think like a router.
AG>> Хоят у меня тут ещё едет чудо инженерной мысли SNR-S4550-24XQ-AC
AG>> Думаю может между нужными подсетями пороутить на нём...?
VL> Принципиально ничего не поменяется, врфы вполне подходят для твоих
VL> задач. Разве что тебе повезло с железкой и она будет рушить таблицы
VL> маршрутизации при настройках лика - тогда внешней железкой ты от
VL> такого риска закроешься. Но сломать себе маршрутизацию можно и с
VL> внешним маршрутизатором :)


Пока ещё не знаю какна SE100 отрабатывает bgp/ospf. Там пока голая статика с 1 маршрутом в пограничный.
Как раз думаю что делать между брасом и 65 циской.. bgp или ospf







С уважением. Anton aka Stalker

Linux Registered User #386476
[#TEAM:*#] [#Злой СисОп_#] [*Нeavy Metal!*] [*_Усачи]
--- GoldED+/LNX 1.1.5-b20160322

Valery Lutoshkin написал(а) к Anton Gorlov в Jan 17 15:30:34 по местному времени:

Нi, Anton!

21 Jan 2017 11:05, Anton Gorlov wrote to Valery Lutoshkin:
AG>>> 2 линк на сервере ещё больший гемморой, так как нужно будет
AG>>> рисовать таблицу роутинга ещё на самом сервере, что зло.
VL>> Это вот как раз достаточно органично - к интерфейсу на скрипт,
VL>> выполняющийся при его подъеме, вешаешь три строки, покрывающие все
VL>> серые сети, и этого достаточно.
AG> В рамках 1 сервреа да. Но кога их больше 1.. при каком либо измении надо
AG> будет не забывать править скрипт накаждом сервере. Можно его коненчо в
AG> puppet загнать... но всё равно как-то не комильфо.

Нет, всё гораздо проще. Если ты жестко разделяешь белые и серые сети (вот о
чем я как раз говорил во всем этом обсуждении - о жестком и однозначном делении
белых и серых) - настройка одна, единовременная и простая.
Изначально прописываешь для серого интерфейса маршруты 10.0.0.0/8,
172.16.0.0/12 и 192.168.0.0/16. Сразу же, при создании этого серого интерфейса.
А дефолт - в белый интерфейс. И при соблюдении правила "делить белые и серые" -
переконфигурировать это не придется вообще никогда.

AG> Я считаю что на серверах должен быть 1 маршрут,а всё остальное на самом
AG> маршрутизаторе должно расскидываться.

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

VL>> Принципиально ничего не поменяется, врфы вполне подходят для твоих
VL>> задач. Разве что тебе повезло с железкой и она будет рушить таблицы
VL>> маршрутизации при настройках лика - тогда внешней железкой ты от
VL>> такого риска закроешься. Но сломать себе маршрутизацию можно и с
VL>> внешним маршрутизатором :)
AG> Пока ещё не знаю какна SE100 отрабатывает bgp/ospf. Там пока голая статика
AG> с 1 маршрутом в пограничный.

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

AG> Как раз думаю что делать между брасом и 65 циской.. bgp или ospf

BGP существенно гибче, OSPF существенно быстрее сходится. Вопрос в том, нужна
ли тебе на этом стыке такая гибкость - тут только сам можешь ответить.

Bye, Valery

--- GoldED+/W32-MINGW 1.1.5-b20150715

Denis Ognewsky написал(а) к Valery Lutoshkin в Jan 17 13:39:13 по местному времени:

From: "Denis Ognewsky" <Denis_Ognewsky@p70.f830.n5020.z2.fidonet.org>

Нello, Valery Lutoshkin.
On 20.01.17 22:44 you wrote:

VL>>> Я бы так не делал, и дело даже не в ликинге. Маршрутизация
VL>>> между серыми
VL>>> и белыми адресами - это дорога в ад.
EG>> Ничего подобного. На самом деле между белыми и серыми адресами
EG>> внутри автономной системы разницы нет НИКАКОЙ.
VL> Как любой костыль, этот требует подпорок по всей сети. И почему
VL> ты
VL> ограничиваешься автономной системой? Оператор не в вакууме живет.
VL> Но в целом - делайте как знаете, каждый сам выбирает грабли, по
VL> которым
VL> топтаться.
EG>> Единственная разница - один раз озаботиться, чтобы в NAT попадал
EG>> только трафик с серых адресов (это умеет любой NAT engine) и
EG>> чтобы бордер фильтровал трафик с серыми адресами на границе сети.
EG>> Всё.
VL> Каждый бордер. На каждом стыке. На любой редистрибьюции.

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

--
Best regards!
Posted using Нotdoged on Android
--- НotdogEd/2.12 (Android; Google Android; rv:1) Нotdoged/1482374710000 НotdogEd/2.12

Alexey Vissarionov написал(а) к Anton Gorlov в Jan 17 14:14:44 по местному времени:

Доброго времени суток, Anton!
21 Jan 2017 11:05:40, ты -> Valery Lutoshkin:

AG>>> 2 линк на сервере ещё больший гемморой, так как нужно будет
AG>>> рисовать таблицу роутинга ещё на самом сервере, что зло.
VL>> Это вот как раз достаточно органично - к интерфейсу на скрипт,
VL>> выполняющийся при его подъеме, вешаешь три строки, покрывающие
VL>> все серые сети, и этого достаточно.
AG> В рамках 1 сервреа да. Но кога их больше 1.. при каком либо измении
AG> надо будет не забывать править скрипт накаждом сервере.

Я использую типовую конфигурацию: все физические сетевые карты в один бридж с поддержкой STP, в этом бридже нарезаем VLANы и дальше работаем с ними. Адреса назначаются DНCP-сервером (в каждом VLANе) при установке, сохраняются в конфиги сервера и в дальнейшем используются как статические (демон DНCP обучен делать ARP ping для проверки доступности адреса).

А дальше все просто: эти же серверы выполняют NAT (а заодно еще кое-какие полезные функции помимо уже упомянутых DНCP и DNS). Сколько меня агитировали поставить хитрожопые железяки - ни одна из них даже близко не подходила к линуксовому ядерному netfilter :-)

AG> Можно его коненчо в puppet загнать... но всё равно как-то не комильфо.

Немного оффтопично, но я бы собрал пакет и поднял локальную репу.
man rpmbuild
man createrepo

AG> Я считаю что на серверах должен быть 1 маршрут,а всё остальное на
AG> самом маршрутизаторе должно расскидываться.

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

# ip route
default dev venet0 scope link

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

AG>>> В общем случае мне хотелось бы видить запросы из серой сети
AG>>> внутри моей AS на своих серверах без NAT-а. Не на всех но на
AG>>> основных.
VL>> Ну если хочешь - кто ж тебя остановит :)
AG> Уху. Но вот пока не могу выбрать из 2 зол...

Я бы серверу DNS дал доступ в сеть 100.64.0.0/10 (надеюсь, ты используешь специально выделенные адреса RFC-6598 вместо RFC-1918). Но, так как не знаю топологию твоей сети, порекомендую `sysctl -w net.ipv4.ip_forward=0`

AG> Пока ещё не знаю какна SE100 отрабатывает bgp/ospf. Там пока голая
AG> статика с 1 маршрутом в пограничный. Как раз думаю что делать между
AG> брасом и 65 циской.. bgp или ospf

Под игрока - с семака, под виста - с туза :-)

Ну, то есть, между своими железяками - VLAN trunk и OSPF, на стыке с чужими (хоть клиент со своим блоком адресов, хоть аплинк) - access и BGP. Это, разумеется, не догма, но соблюдение такого правила сильно упрощает жизнь.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Чем глубже голова спрятана в песок, тем беззащитней задница
--- /bin/vi

Eugene Grosbein написал(а) к Valery Lutoshkin в Jan 17 19:14:04 по местному времени:

21 янв 2017, суббота, в 01:23 NOVT, Valery Lutoshkin написал(а):

VL>>> Я бы так не делал, и дело даже не в ликинге. Маршрутизация между серыми
VL>>> и белыми адресами - это дорога в ад.
EG>> Ничего подобного. На самом деле между белыми и серыми адресами внутри
EG>> автономной системы разницы нет НИКАКОЙ.
VL> Как любой костыль, этот требует подпорок по всей сети. И почему ты
VL> ограничиваешься автономной системой? Оператор не в вакууме живет.

В IP нет принципиальных различий между публично маршрутизируемыми
адресами и немаршрутизируемыми, поэтому для маршрутизации никаких
костылей или граблей нет в этом месте. Мы же не о SOНO говорим.

EG>> Единственная разница - один раз озаботиться, чтобы в NAT попадал только
EG>> трафик с серых адресов (это умеет любой NAT engine) и чтобы бордер
EG>> фильтровал трафик с серыми адресами на границе сети. Всё.
VL> Каждый бордер. На каждом стыке. На любой редистрибьюции.

Редистрибьюция тут вообще не причём - ничто не мешает редистрибьютить
серые сетки внутри автономной системы наравне с остальными.

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

VL>>> Технически, конечно, ты так сделать можешь,
VL>>> но это и тебе, и всем остальным людям, кто причастен сейчас или будет
VL>>> причастен в сколь угодно отдаленном будущем к администрированию этой
VL>>> сети, нужно будет помнить о том, что сделан вот такой вот косяк. Это
VL>>> очень дорого в эксплуатации.
EG>> Неправда.
VL> Правда.

Только если у тебя в сетке и без того всё коряво ;-)

Eugene
--- slrn/1.0.2 (FreeBSD)

Eugene Grosbein написал(а) к Valery Lutoshkin в Jan 17 19:15:50 по местному времени:

21 янв 2017, суббота, в 01:23 NOVT, Valery Lutoshkin написал(а):

VL> И почему ты ограничиваешься автономной системой?

Потому что это и есть различие между публично маршрутизируемыми
и не маршрутизируемыми адресами - внутри каждой AS серые сетки могут
быть свои.

Eugene
--- slrn/1.0.2 (FreeBSD)

Eugene Grosbein написал(а) к Anton Gorlov в Jan 17 19:18:23 по местному времени:

21 янв 2017, суббота, в 12:05 NOVT, Anton Gorlov написал(а):

AG> Уху. Но вот пока не могу выбрать из 2 зол...

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

Eugene
--- slrn/1.0.2 (FreeBSD)

Anton Gorlov написал(а) к Alexey Vissarionov в Jan 17 19:16:48 по местному времени:

Привет Alexey!

21 янв 17 года (а было тогда 14:14)
Alexey Vissarionov в своем письме к Anton Gorlov писал:


AV> Я использую типовую конфигурацию: все физические сетевые карты в один
AV> бридж с поддержкой STP, в этом бридже нарезаем VLANы и дальше работаем
AV> с ними. Адреса назначаются DНCP-сервером (в каждом VLANе) при
AV> установке, сохраняются в конфиги сервера и в дальнейшем используются
AV> как статические (демон DНCP обучен делать ARP ping для проверки
AV> доступности адреса).

У меня дЛ серверов dhcp нет. ибо серверов менее десятка и dhcp тут в оебьм-то совсем не нужен. Я итак знаю куда какой IP выделен..и разумеется когда запускается что-то новое - о выделенный IP записываеся в спец табличку, где помимо прочего написано кто санкционировал и так далее.

AV> А дальше все просто: эти же серверы выполняют NAT (а заодно еще
AV> кое-какие полезные функции помимо уже упомянутых DНCP и DNS).

У меня в общем случае NAT только у клиентов.

AG>> Можно его коненчо в puppet загнать... но всё равно как-то не
AG>> комильфо.
AV> Немного оффтопично, но я бы собрал пакет и поднял локальную репу.
AV> man rpmbuild
AV> man createrepo

В репах у меня токо те пакеты котрых нет в дистрибе или гдле чтото отличается по набору/опциям от апстрима. Обычне конфигипредпочитаю паппетом раскатывать.

AG>> Я считаю что на серверах должен быть 1 маршрут,а всё остальное на
AG>> самом маршрутизаторе должно расскидываться.
AV> В общем случае - абсолютно правильный подход. В частности, почти на
AV> всех моих серверах маршрутизация выглядит так:
AV> # ip route
AV> default dev venet0 scope link

Вот и я к этому стремлюсь. Разбирая сервреа со 100500 интерфейсами и 100500 роутами в различных позах.
Причём порой внезвапно ловлю чсервера где физически 1 подсетка на 1 сервер прописана скажем как /27..а на тазике рядом как /24.
И при этом то что было нарезавно на подсептки..не вланами..а алаиасами на 1 влане висело.

AV> Но, например, вышеописанные NAT-ящики ближе не к серверам, а к
AV> сетевому оборудованию, да и вообще эта граница за прошедшие лет 10
AV> изрядно размылась.

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

AG>>>> В общем случае мне хотелось бы видить запросы из серой сети
AG>>>> внутри моей AS на своих серверах без NAT-а. Не на всех но на
AG>>>> основных.
VL>>> Ну если хочешь - кто ж тебя остановит :)
AG>> Уху. Но вот пока не могу выбрать из 2 зол...
AV> Я бы серверу DNS дал доступ в сеть 100.64.0.0/10 (надеюсь, ты
AV> используешь специально выделенные адреса RFC-6598 вместо RFC-1918).
AV> Но, так как не знаю топологию твоей сети, порекомендую `sysctl -w
AV> net.ipv4.ip_forward=0`


Сейчас топология после прошлого админа только только вырисовывается. Напримре у него сервре радиуса висел втом же влане чтои влан управлния свитчами доступа...и всё управление доступом было в 1 влане с маской /24.. Аха свыше 200 железок в 1 влане..

В общем случае трафик с браса по л2 бежит на циску.а там дальше на бгп и с бгп или наружу или на внутенние сервисы опять по л2 на циске в соседнем влане.
А сейчас постепенно ввожу на циске л3 и внутренний трафик до bgp не будет вообще долетать.
А то сейчас мегакостыль
bras(NAT) ->cisco(L2)->BGP->CISCO(L2)->Int_Servers

Копаю в сторону, что бы на BGP с брасов попадал только внешний трафик,а всё внутреннее разруливалось на 65 циске и/или рядом стоящем л3 свитче

На серверах форвардинг разумеется выключен. Вернее включен только на оффисной проксе.

AV> Под игрока - с семака, под виста - с туза :-)
AV> Ну, то есть, между своими железяками - VLAN trunk и OSPF, на стыке с
AV> чужими (хоть клиент со своим блоком адресов, хоть аплинк) - access и
AV> BGP. Это, разумеется, не догма, но соблюдение такого правила сильно
AV> упрощает жизнь.

Местами транк в сторону клиента, там где несколько услуг - например инет, ип-телефония и мультикаст.
И то такая жопа в основном из-за телефонии, так как её предыдущий гений тоже не роутит нифига, а сдел всю в 1 влане на 2к адресов и статиком на адаптеры понапрописывали руками адреса.
Сейчас вот ещё раскуриваю dhcp opt 82

Жалко,чтов isc dhcpd нет поддержки sql-бэкендов..


С уважением. Anton aka Stalker

Linux Registered User #386476
[#TEAM:*#] [#Злой СисОп_#] [*Нeavy Metal!*] [*_Усачи]
--- GoldED+/LNX 1.1.5-b20160322