Jump to content

Маршрутизация при 2х NASах

kirush
 Share

Recommended Posts

kirush

kirush

Posted
Posted (edited)

Добрый день!

Возникла потребность добавления второго NASа, но что то "туплю".

Схема организации узла:

свитч #1 - DMZ

свитч #2 - смотрит в локалку

—— инет ——— [eth0 real_ip —— router ——— eth1 192.168.0.254 ] ———— свитч #1

——свитч #1 ——[ eth0 192.168.0.252 ——nas1 —— eth1 10.1.255.254] ———свитч #2

решил добавить 2ой NAS c l2tp:

—- свитч #1 —— [eth0 192.168.0.251 —— nas2 ——— eth1 10.1.255.252] —— свитч #2

Но если при одном NASе маршрутизация на роутере выглядела так:

route add 172.16.0.0/16 192.168.0.252

NASы терминируют pptp/l2tp

то как она должна выглядеть в случае 2х NASов? Подскажите.

Не уж то надо городить еще один шлюз.

Edited by kirush
Alex/AT

Alex/AT

Posted
Posted (edited)

Можно, например, раскидать пулы адресов - на один NAS 172.16.0.0, на другой - 172.17.0.0.

Если ряду клиентов даете реальники - это не совсем вариант, и попутно придётся на NAS'ах поднять BIRD, и раздавать маршруты по OSPF либо iBGP.

Мы для такой раздачи (NAS'ов более двух, все клиенты с реальниками) используем iBGP+RR (NAS'ы смотрят на RR, RR - в ядро), работает, не жужжит.

Edited by Alex/AT
kirush

kirush

Posted
  • Author
Posted (edited)

Клиенты как с 172.16.0.0/16 так и реальники.

Хотел сделать так чтобы, клиенты ничего не видели, те как подключались к vpn.xxx.ru так и будут подключаться.

DNSом распределять нагрузку между 2мя, а в последствии и большем количество NASов.

Т.е. на какой NAS подцепится клиент известно одному DNSу.

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

Edited by kirush
Alex/AT

Alex/AT

Posted
Posted (edited)

Тогда для вас (как и для нас) единственный выход - динамическая маршрутизация.

Edited by Alex/AT
Saab95

Saab95

Posted
Posted

Ага. У нас правда PPPoE.

 

Но на сервере доступа достаточно включить PPPoE сервер и OSPF. Больше делать ничего не надо. После этого ставить еще такие же стопками и радоваться высокой производительности и отказоустойчивости.

Alex/AT

Alex/AT

Posted
Posted (edited)

Кстати. Можно тогда пару вопросов:

OSPF не сильно проц грузит?

Много юзеров (одновременных)?

 

Мы от OSPF отказались из-за высокой нагрузки, нагрузку от BGP через RR почти не заметно.

Edited by Alex/AT
Saab95

Saab95

Posted
Posted

Да сервера на i3 пользователей около 1000 на каждом серваке, загрузка проца около 40-70%. И то наверно больше отъедает правила шейперов и ограничение количества пакетов, чем OSPF.

config

config

Posted
Posted

Балансировка статикой.

ip route 172.16.0.0 255.255.0.0 192.168.0.252 metric 2

ip route 172.16.0.0 255.255.0.0 192.168.0.251 metric 4

Ip route 172.16.0.0 255.255.128.0 192.168.0.252

Ip route 172.16.128.0 255.255.128.0 192.168.0.251

 

Главное что бы маршруты были не permanent

 

При необходимости так же можно сделать с обратной стороны.

kayot

kayot

Posted
Posted (edited)

Я бы правда посоветовал сразу делать на RIP2 или вообще на BGP, с ospf у нас вылезали грабли с большой загрузкой БРАСов.

ospfd.conf:

interface vlan222
!
router ospf
ospf router-id 10.1.1.1

redistribute connected route-map ospf
passive-interface default
no passive-interface vlan222
network xx.xx.xx.xx/16 area 0.0.0.1
!
access-list 10 permit xx.xx.xx.0 0.0.0.255
access-list 10 deny any
!
route-map ospf permit 1
match ip address 10

zebra.conf

!
interface vlan222
multicast
!

Роут-мап с акцесс листом это наша специфика, да и надежнее. У клиентов раньше(когда был актуален этот конфиг) были серые и белые адреса, серые НАТились тут же на БРАСе, а белые отдавались на бордер. Если у вас схема адресации одна - фильтры не нужны.

Конфиг для rip, в нем дополнительно запрет обмена маршрутами между БРАСами

ripd.conf

interface vlan222
!
router rip
version 2
passive-interface default
no passive-interface vlan222
network vlan222
distribute-list private-only in vlan222
redistribute connected route-map rip-map
!
access-list z permit xx.xx.xx.xx/xx
access-list z deny any
!
route-map rip-map permit 1
match ip address z
!
access-list private-only deny any

На принимающей стороне все тоже самое, кроме ненужного redistribute. Ну и фильтровать там в принципе уже нечего, роутмапы не нужны.

Edited by kayot
kirush

kirush

Posted
  • Author
Posted (edited)

kayot, спасибо большое. Но к часу ночи допер до всего своими руками.

На NASe:

 

ospfd.conf:

hostname vpn2
enable password XXX
password XXX
service advanced-vty
log file /var/log/quagga.log
!
router ospf
ospf router-id 192.168.0.251
network 192.168.0.0/24 area 0.0.0.0
neighbor 192.168.0.254
default-information originate
log-adjacency-changes
redistribute connected
no redistribute kernel
passive-interface default
no passive-interface em1 #em1 смотрит на роутер
area 0.0.0.0 authentication message-digest
area 0.0.0.0 export-list VPNs
distribute-list VPNs out connected
access-list VPNs permit 172.16.0.0/16
access-list VPNs permit ПУЛ.РЕАЛЬНИКОВ/23 
access-list VPNs deny any
log stdout 
!
line vty
!

 

ospfd.conf на роутере:

hostname router
password XXX
log file /var/log/quagga.log
!
router ospf
ospf router-id 192.168.0.254
network 192.168.0.0/24 area 0.0.0.0
neighbor 192.168.0.251
neighbor 192.168.0.252
!
line vty
!

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

192.168.0.0/24 - зона DMZ в моем случае.

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

Что в итоге получили:

При поднятии сессии на NAS №2 (10.1.255.252) через MPD, получаем маршрут 172.16.x.x/32 gw 192.168.0.251

При поднятии сессии на NAS №1 (10.1.255.254) через MPD, получаем маршрут 172.16.x.x/32 gw 192.168.0.252

 

P.S. только сейчас заметил, что тему создал не в ПО :( попрошу модератора - перенести тему.

Edited by kirush
kayot

kayot

Posted
Posted

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

 

distribute-list у меня не работали, проверьте что оно действительно что-то делает.

dignity

dignity

Posted
Posted

хм, а proxy arp там нету чтоль? Сам NAS не может ответить в чьей ведомости находится клиент?

Надо всего-то NAS-ам и гейту выдать IP из ваших сетей, которые обслуживаются...

У нас на PPTP было именно так и два NAS работали на ура.

Alex/AT

Alex/AT

Posted
Posted (edited)

Обещанный конфиг для BIRD:

# general config

router id 1.2.3.4;
log "/var/log/bird.log" all;

# routing tables

table t_kernel;

# filters

filter export_devices
{
   if source = RTS_DEVICE then {
       accept;
   }
   reject;
}

# main protocols

protocol kernel {
   table t_kernel;
   device routes;
   import none;
   export all;
};

protocol device {
   scan time 60;
};

protocol direct {
   table t_kernel;
   interface "ppp*";
   import all;
};

# BGP peers

protocol bgp {
   table t_kernel;
   local as 12345;
   neighbor 5.6.7.8 as 12345;
   route limit 500000;
   export filter export_devices;
   import all;
};

 

1.2.3.4 - наш IP (Router ID)

5.6.7.8 - наш BGP peer (вообще секций protocol bgp может быть несколько)

12345 - наша AS

 

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

Edited by Alex/AT
Ivan Rostovikov

Ivan Rostovikov

Posted
Posted

У меня такой опыт:

Такая же схема - несколько насов.

При общем кол-ве онлайн абонентов до 5-6 тысяч прекрасно справлялся RIP.

После 6-ти тысяч, нагрузка на ЦПУ от пересчета (каждые 30 сек) всех RIP маршрутов - стала напрягать.

Классически RIP ругают за повышенную нагрузку на сеть. Но по факту вышло, что сеть нагружается не очень, а вот проц - да.

Анализ показал, что OSPF должен более гладко нагружать проц.

Так и вышло на практике.

YuryD

YuryD

Posted
Posted

Работает связка из mpd, cisco7206 и тройка accel-pptp + nat-овский комп по bgp c кваггой. Просто Ip клиенту биллинг раздает, для упрощения шейперов...

IMPERATOR

IMPERATOR

Posted
Posted (edited)

Добрый день всем .

Хотим организовать резервный бордер . Система Freebsd 8.2 используем Bgp\zebra (Quagga) , есть своя AS , получаем full view

Есть второй сервер с тем же самым

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

Подскажите где можно почитать именно про настройку Quagga на двух серверах для резервирования канала

Сейчес вот так выглядит

............[uPlink]..............

...................|................

............[L2_switch].............

.......................|............

..................[GW1]..........

...................|..............

..............[L2_swich]

..................|...............

............[L3_switch]............

В результате должно получится вот так

............[uPlink]..............

...................|................

..........[L2_switch].............

.......................|....................

[GW1]-------..........---------[GW2]

..|....................................|

..----------[L2_swich]-----------

..................|...............

............[L3_switch]............

Edited by IMPERATOR
  • 2 weeks later...
kirush

kirush

Posted
  • Author
Posted (edited)

Прокомментируйте плз ошибки:

 

На роутере где маршруты создаются:

2011/12/28 11:54:40 OSPF: Link State Update[Type5,id(172.16.4.248),ar(192.168.0.252)]: LS age is equal to MaxAge.

 

А на втором NASе - не подымается нормально OSPF

2011/12/28 12:01:42 OSPF: Link State Update: Neighbor[192.168.0.252] state Init is less than Exchange

 

vpn> show ip ospf neighbor

 

Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL

192.168.0.252 1 Init/DROther 39.749s 192.168.0.252 em0:192.168.0.251 0 0 0

192.168.0.254 1 Full/DR 38.384s 192.168.0.254 em0:192.168.0.251 0 0 0

 

в логах на master (на том где должны создаваться маршруты):

 

2011/12/28 12:23:26 OSPF: Link State Update[Type5,id(172.16.3.210),ar(192.168.0.252)]: LS age is equal to MaxAge.

2011/12/28 12:24:17 OSPF: nsm_change_state(192.168.0.251, Full -> Init): scheduling new router-LSA origination

2011/12/28 12:24:17 OSPF: DR-Election[1st]: Backup 192.168.0.254

2011/12/28 12:24:17 OSPF: DR-Election[1st]: DR 192.168.0.252

2011/12/28 12:24:23 OSPF: DR-Election[1st]: Backup 192.168.0.254

2011/12/28 12:24:23 OSPF: DR-Election[1st]: DR 192.168.0.252

2011/12/28 12:24:23 OSPF: Packet[DD]: Neighbor 192.168.0.251: Initial DBD from Slave, ignoring.

2011/12/28 12:24:23 OSPF: Packet[DD]: Neighbor 192.168.0.251 Negotiation done (Master).

2011/12/28 12:24:23 OSPF: nsm_change_state(192.168.0.251, Exchange -> Full): scheduling new router-LSA origination

Edited by kirush

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.