Qagga(rip) - проблема..

[AlKov]

NAS на mpd5, одновременно DHCP сервер.

Два интерфейса: fxp0 - в сторону клиентов и fxp1 - в сторону NAT (отдельная машина на CentOS)

Задача:

1. отдавать на NAT маршруты для PPP соединений (подсеть 172.16.0.0/12).

2. принимать маршруты до абонентских подсетей /25 ("общий" диапазон 10.10.0.0/16), которые отдаёт релей на DGS-3120)

3. НЕ анонсировать на NAT (там тоже rip, который только "слушает") "абонентскую подсеть".

 

Пп. 1-2 выполняются, п. 3 не могу реализовать.. На NAT либо ничего не приходит, либо всё..

Причём, на NAT маршруты до 10.10.0.0/16 приходят "кривые" - т.е. "от имени" IP NAS-а.

Т.е. если реальный маршрут, например, до 10.10.15.0/25 GW 10.254.213.102 на NAT приходит с GW *.*.*.*/29 (белый IP на fxp1).

Конфиг ripd

! -*- rip -*-
!
hostname NAS-9
password ******
log file /var/log/ripd.log
!
service password-encryption
!
interface fxp0
ip rip authentication mode text
ip rip authentication string ******
!
interface fxp1
ip rip authentication mode text
ip rip authentication string ******
!
router rip
version 2
redistribute connected route-map annonce-map
no redistribute static
network fxp1
network fxp0
passive-interface default
no passive-interface fxp1
distribute-list noannonce in fxp1
distribute-list noannonce out fxp0
!
access-list noannonce deny any
access-list usersnet permit 10.10.0.0/16
access-list usersnet permit 192.168.48.0/20
access-list usersnet deny any
access-list vpn permit 172.16.0.0/12
!
route-map annonce-map permit 10
match ip address vpn
!
!
line vty
!

Где-то ошибка, или задача для ripd нереализуема?

[terrible]

1. отдавать на NAT маршруты для PPP соединений (подсеть 172.16.0.0/12).

redistribute connected route-map annonce-map
!
access-list vpn permit 172.16.0.0/12
!
route-map annonce-map permit 10
match ip address vpn
!
!

 

Может быть в этом случае нужно сделать вот так:

 

access-list vpn permit 172.16.0.0/12
access-list vpn deny any

 

?

 

Вопрос: Где в конфиге используется access-list usersnet ?

[AlKov]

 

Может быть в этом случае нужно сделать вот так:

 

access-list vpn permit 172.16.0.0/12
access-list vpn deny any

 

?

Именно так и было. Удалил, когда копипастил.

Вопрос: Где в конфиге используется access-list usersnet ?

В

distribute-list usersnet in fxp0

Тоже не заметил, когда копировал..

Есть предположение, что quagga считает маршруты принятые от соседей, как kernel и отдаёт их по дефолту.

Думаю попробовать

no redistribute kernel

Больше никаких мыслей нет.

 

P.S. Никак не могу нагуглить внятную доку по синтаксису access-list, route-map и проч.

В офф доке очень скудно про это..

[kayot]

Вот конфиг с рабочего PPP linux-NAS'a

hostname nas3-rip
password xxxxxxxx
enable password xxxxxxxx
! log file /var/log/quagga/ripd.log
service password-encryption
!
!debug rip events
!debug rip packet
!
interface bond0.2
!
router rip
version 2
passive-interface default
no passive-interface bond0.2
network bond0.2
timers basic 60 180 120
distribute-list private-only in bond0.2
redistribute connected route-map rip-map
!
access-list zeus permit xxx/24
access-list zeus permit yyy/23
access-list zeus permit zzz/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
!

Отдает только то что прописано в access-list.

[AlKov]

Вот конфиг с рабочего PPP linux-NAS'a

...

Отдает только то что прописано в access-list.

 

Так практически аналогичный...

Я так понимаю, что Ваш rip только отдаёт маршруты ?

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

[snark]

одновременно принимать маршруты и отдавать не все, а только строго определённые

В чем проблема-то?

Вот вам рабочий конфиг

 

!
hostname ripd
password admin
log file /var/log/quagga.log
!
router rip
version 2
redistribute connected
network 1.1.1.0/20
network 172.16.230.0/24
neighbor 1.1.1.33
neighbor 1.1.1.35
neighbor 1.1.1.36
neighbor 1.1.1.37
neighbor 1.1.1.38
neighbor 172.16.230.1
passive-interface default
no passive-interface vlan31
no passive-interface vlan32
distribute-list prefix public  out vlan31
distribute-list prefix private out vlan32
!
ip prefix-list public seq 100 deny 1.1.1.34/32
ip prefix-list public seq 110 deny 1.1.1.35/32
ip prefix-list public seq 120 deny 1.1.1.36/32
ip prefix-list public seq 130 deny 1.1.1.37/32
ip prefix-list public seq 140 deny 1.1.1.38/32
ip prefix-list public seq 150 deny 1.1.1.42/32
ip prefix-list public seq 160 deny 1.1.1.43/32
ip prefix-list public seq 170 deny 1.1.1.44/32
ip prefix-list public seq 180 deny 1.1.1.45/32
ip prefix-list public seq 190 deny 1.1.1.46/32
ip prefix-list public seq 200 permit 1.1.1.0/20 ge 31
ip prefix-list public seq 210 deny 0.0.0.0/0 le 32
!
ip prefix-list private seq 10 permit 172.16.240.0/20 ge 31
ip prefix-list private seq 20 deny 0.0.0.0/0 le 32
!
access-list vty permit 127.0.0.1/32
access-list vty deny any
!
line vty
access-class vty
exec-timeout 0 0
!

public отдает только белые адреса

private отдает только серые адреса

каждый отдает только туда, куда надо

[kayot]

Вот конфиг с рабочего PPP linux-NAS'a

...

Отдает только то что прописано в access-list.

Так практически аналогичный...

Я так понимаю, что Ваш rip только отдаёт маршруты ?

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

Директива 'redistribute connected' говорит что анонсировать нужно только сети непосредственно доступные с NAS'a.

Если у вас при этом анонсирует еще и полученные непрямые маршруты - значит квагга кривая, смените версию.

Этому конфигу уже лет 10 наверное, там были варианты и с принятием мусора от соседей - всегда анонсились только свои PPP-клиенты.

[s.lobanov]

а чем не устраивает банальный ibgp? там всё настолько тривиально с фильтрацией префиксов в обе стороны, что даже думать ничего не надо, в отличии от rip/ospf и прочих igp

[snark]

Директива 'redistribute connected' говорит что анонсировать нужно только сети непосредственно доступные с NAS'a.

Похоже сейчас действительно стало модным не читать, если kayot вынужден объяснять основы :(

 

 

чем не устраивает банальный ibgp?

Возможно у ТС что-то где-то в сети не понимает BGP, вот он и использует RIP.

В принципе RIP-а вполне достаточно для простых задач типа "сказать роутеру А, что адрес В находится за роутером С".

[s.lobanov]

snark

RIP/v2/ng - мутное, немасшатибируемое, ненужное говно. уважайте тех, кто будет работать после вас, когда вы свалите

 

в задаче же чётко описано, что нужно обменяться маршрутами между сервером на linux и сервером на freebsd. с обеих сторон может быть quagga, bird, xorp, всё умеет нормальные протоколы

 

а уж для анонса маршрутов /32 с NAS-ов лучше ibgp вообще ничего не придумать

 

делать вам н***й раз с RIP-ом развлекаетесь

[AlKov]

Директива 'redistribute connected' говорит что анонсировать нужно только сети непосредственно доступные с NAS'a.

Похоже сейчас действительно стало модным не читать, если kayot вынужден объяснять основы :(

Я так понимаю, в мой огород? ;-)

Вынужден защититься. Читал! Триста тридцать три раза, 7 дней подряд! :-)

И читал не в одиночестве, а на пару с весьма продвинутым и более молодым товарищем.

И именно понимание того, что "Директива 'redistribute connected' говорит что анонсировать нужно только сети непосредственно доступные с NAS'a",

вгоняло в ступор, когда NAS (rip на нём) аннонсировал всё подряд..

И на 8-й день ступора решил обратиться за помощью сюда.

Кстати.. snark, спасибо за пример конфига. Нарисовал свой по образу и подобию - всё зажужжало, аки пчёл! :-)

Предполагаю три причины своей неудачи:

1. банальная ошибка (моя).

2. как написал kayot, "кривая" квага. "Обкатку" конфига проводил на машине с относительно "древней" FreeBSD 8.2, соотв. и версия кваги.

3. использование ACL вместо prefix-list

Использование списков распределения обладает определенными недостатками, такими как:

ACL (Access-List, списки управления доступом), используемые в списках распределения, изначально разрабатывались для фильтрации пакетов, а не для фильтрации маршрутов

Невозможность определения совпадения маски маршрута при использовании стандартных ACL

Использование расширенных ACL может оказаться громоздким для конфигурирования

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

пруф.

 

Возможно у ТС что-то где-то в сети не понимает BGP, вот он и использует RIP.

Так оно и есть. DGS-3120 BGP не умеет. Правда, он якобы умеет OSPF, но с ним мне ещё не приходилось работать, да и вроде как не для этой задачи он. ИМХО, конечно..

 

В принципе RIP-а вполне достаточно для простых задач типа "сказать роутеру А, что адрес В находится за роутером С".

Именно такая задача.

 

P.S.

в задаче же чётко описано, что нужно обменяться маршрутами между сервером на linux и сервером на freebsd. с обеих сторон может быть quagga, bird, xorp, всё умеет нормальные протоколы

В задаче есть ещё и "третья сторона" (п.2), которая из "нормальных протоколов" умеет только OSPF. И ещё вопрос - умеет ли...

[vlad11]

 

Кстати.. snark, спасибо за пример конфига. Нарисовал свой по образу и подобию - всё зажужжало, аки пчёл! :-)

 

 

Покажите diff между старым и новым конфигом и будет понятно кто виноват.

[kayot]

Разница в использовании route-map или prefix-list. Первое не работает, второе работает.

Но в любом случае, сама квагга работает некорректно а эти фильтры просто костыль.

[AlKov]

Разница в использовании route-map или prefix-list. Первое не работает, второе работает.

Но в любом случае, сама квагга работает некорректно а эти фильтры просто костыль.

И...? Ваш вердикт?

RIP/v2/ng - мутное, немасшатибируемое, ненужное говно.

Или что-то другое?

[SyJet]

snark

RIP/v2/ng - мутное, немасшатибируемое, ненужное говно.

Не, ну это уже саабом запахло и устаревшими технологиями ;)

А вообще, для этих целей и это уже неоднократно обсуждалось подходят только rip2, ibgp и isis.

И применяется от тех возможностей. Например в моей сети ibgp и isis невозможен. Хотя мне то пофигу, количество маршрутов минимально. А тем, у кого более 2,5тыс маршрутов от браса - тем приходится выбирать, и зачастую это rip2, так как для ibgp ещё и рефлектор скорее всего поднимать придётся, а isis редкий зверь да и квага не держит.

Edited July 4, 2015 by SyJet

[kayot]

AlKov

А какой может быть вердикт? Хочется разобраться - обновите. Не хочется - забейте, работает ведь.

[s.lobanov]

snark

RIP/v2/ng - мутное, немасшатибируемое, ненужное говно.

Не, ну это уже саабом запахло и устаревшими технологиями ;)

А вообще, для этих целей и это уже неоднократно обсуждалось подходят только rip2, ibgp и isis.

И применяется от тех возможностей. Например в моей сети ibgp и isis невозможен. Хотя мне то пофигу, количество маршрутов минимально. А тем, у кого более 2,5тыс маршрутов от браса - тем приходится выбирать, и зачастую это rip2, так как для ibgp ещё и рефлектор скорее всего поднимать придётся, а isis редкий зверь да и квага не держит.

 

в ibgp можно рефлектор, можно fullmesh, это уж как вам нравится. когда речь идёт о 2.5к кастомеров, то это один, максимум 2 сервера(ну или 50 микротиков) и там ibgp без rr нормально.

 

вообще, в случае с софтроутингом и всякими quagga и ospf пойдёт для обмена маршрутами об абонентах в масштабах до примерно 10к(реально и больше можно). это старые железки со слабым control-plane плохо реагировали на ospf с относительно большим кол-вом маршрутов

[SyJet]

Вот честно, +3см не вырастит если автор сменить рип на ибгп :))

[kayot]

s.lobanov

ospf на 3ех NAS'ах в квагге у меня загнулся на ~2k маршрутов суммарно, бегающих между серверами и бордером. После перевода на rip2 я туда уже лет 5 не лазил, работает, маршруты растут, все ок.

[s.lobanov]

SyJet

просто на баги в RIP всем пофиг (повезёт - исправят), а вот ospf и bgp в quagga используют не только на просторах ex-USSR и поэтому им стоит больше доверять

[NiTr0]

ospf на 3ех NAS'ах в квагге у меня загнулся на ~2k маршрутов суммарно, бегающих между серверами и бордером.

Ну у меня пока граблей не было. Разве что квагга порой теряла connected маршруты после того, как на брасах появился fv...