Jump to content
Калькуляторы

linux quagga проблема с двумя аплинками

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

 

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

 

Share this post


Link to post
Share on other sites

Удалить дефолт роут где proto kernel (если есть).

Пусть зебра сама его ставит (proto zebra).

Share this post


Link to post
Share on other sites

Чего-то я ернуду написал.

Второй аплинк не пигуется по адресу связки с вами?

Share this post


Link to post
Share on other sites
Чего-то я ернуду написал.

Второй аплинк не пигуется по адресу связки с вами?

именно так, пока живой один линк второй даже не пингуется. при обрыве одного переключается на второй и пинг появляется и трафик бежит по нему. вот такой вот парадокс.

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

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

Edited by victor3000

Share this post


Link to post
Share on other sites

victor3000, сессии multihop? Откуда пингуете (с самого маршрутизтатора / с компьютера за ним)? Вообще хорошо бы посмотреть на конфиг BGP.

 

Share this post


Link to post
Share on other sites

tcpdump -i интерфейс_ на_второго_аплинка -n -p icmp and host адрес_откуда_пингуете_извне

Что там? Видно приходящие icmp? Куда уходят ответы?

Сразу глянуть на первом аплинке также.

 

Share this post


Link to post
Share on other sites

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

хотя достаточно сделать service zebra restart и вуаля, пинги уходят через первый интерфейс, в принципе как и должно быть.

вот что находиться в zebra.cfg что волшебным образом востанавливает работоспособность.

hostname blabla

password gjrf

!enable password gjrf

log file /var/log/zebra.log

interface eth0

multicast

!

interface eth1

multicast

!

interface eth2

multicast

!

interface lo0

!

ip route 0.0.0.0/0 ip связки с провом номер 1

ip route 0.0.0.0/0 ip связки с провом номер 2

!

ip forwarding

line vty

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

что интересно при рестарте зебры при не работающем состоянии я вижу сообщение об ошибке от нее при рестарте:

Starting zebra: Failed to send flush request: Success

Flush terminated

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

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

вроде все.

есть мысли? или переходим к конфигу bgp?

 

Share this post


Link to post
Share on other sites
ip route 0.0.0.0/0 ip связки с провом номер 1

ip route 0.0.0.0/0 ip связки с провом номер 2

!

А это тебе зачем?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Если

ip route get ip_gw_неработающего_аплинка

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

На всяк случай снесите мултихоп, если есть.

Маршруты к пирам лучше добавить статиком в зебру c /32, если сети на стыке бальше чем /30.

 

пс. покажите что выдает

show ip bgp sum

в консоли bgpd когда все не работает

 

Share this post


Link to post
Share on other sites

Оно не просто не нужно, оно вредно.

BGP должен сам добавлять default-ы, сесии к аплинкам поднимаются?

Share this post


Link to post
Share on other sites

А а что у вас по ip route | wc -l ?

Такое ощущение что полную таблицу и не принимаете.

 

Share this post


Link to post
Share on other sites
sh ip bgp sum

BGP router identifier 91.90.19.33, local AS number 51299

RIB entries 607688, using 37 MiB of memory

Peers 2, using 5040 bytes of memory

 

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

91.90.19.61 4 13307 65513 187 0 0 0 01:31:08 327381

95.67.4.129 4 34867 112062 16 0 0 0 00:00:59 327384

 

Total number of neighbors 2

ip route | wc -l

328251

Share this post


Link to post
Share on other sites
sh ip bgp sum

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

91.90.19.61 4 13307 65513 187 0 0 0 01:31:08 327381

95.67.4.129 4 34867 112062 16 0 0 0 00:00:59 327384

Total number of neighbors 2

И один из соседей не пингуется?

Фаерволл отключен?

 

И вот это сделайте:

for i in /proc/sys/net/ipv4/conf/*/rp_filter; do

echo 0 > $i

done

Edited by TiFFolk

Share this post


Link to post
Share on other sites

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

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

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

Edited by victor3000

Share this post


Link to post
Share on other sites

Если убить кваггу, оставить просто 2 аплинка без всякого bgp всё пингуется как надо?

Edited by disappointed

Share this post


Link to post
Share on other sites

ifconfig eth1

ifconfig eth2

 

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

Я бы рекомендовал прибить маршрутизацию AS аплинков через интерфейсы связи гвоздями

Share this post


Link to post
Share on other sites
ifconfig

eth0 Link encap:Ethernet HWaddr 00:23:CD:B4:9A:AC

inet addr:91.90.19.33 Bcast:91.90.19.63 Mask:255.255.255.192

inet6 addr: fe80::223:cdff:feb4:9aac/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:64649225 errors:0 dropped:0 overruns:0 frame:0

TX packets:75048689 errors:0 dropped:0 overruns:3 carrier:0

collisions:0 txqueuelen:1000

RX bytes:3075269535 (2.8 GiB) TX bytes:647171963 (617.1 MiB)

Interrupt:21 Base address:0xac00

 

eth1 Link encap:Ethernet HWaddr 00:07:E9:80:01:3D

inet addr:95.67.4.130 Bcast:95.67.4.131 Mask:255.255.255.252

inet6 addr: fe80::207:e9ff:fe80:13d/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:136096 errors:0 dropped:0 overruns:0 frame:0

TX packets:101132 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:67932139 (64.7 MiB) TX bytes:15490604 (14.7 MiB)

 

eth2 Link encap:Ethernet HWaddr 00:07:E9:80:01:3C

inet addr:195.226.192.254 Bcast:195.226.192.255 Mask:255.255.255.0

inet6 addr: fe80::207:e9ff:fe80:13c/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:75068236 errors:2 dropped:0 overruns:0 frame:1

TX packets:64385885 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:651544404 (621.3 MiB) TX bytes:2987541546 (2.7 GiB)

 

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

inet6 addr: ::1/128 Scope:Host

UP LOOPBACK RUNNING MTU:16436 Metric:1

RX packets:505 errors:0 dropped:0 overruns:0 frame:0

TX packets:505 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:41077 (40.1 KiB) TX bytes:41077 (40.1 KiB)

 

давайте еще раз сфокусируемся на главном.

ip сзязки провов 91.90.19.61 основной и 95.67.4.129

забудем про маршруты получаемые по bgp и т.д.

остановимся на простом, на пингах.

ip связки провов всегда пингуются из нутри и снаружи.

мои ip сзязки которые кстати видны на интерфейсах пингуются из вне только до момента запуска демона bgpd. после его запуска спустя 1 минуту пингуется только один( на второй пакеты приходят, я это видел tcpdumpom, но никуда не уходят, смотрел на первом и втором интерфейсе, нада еще на третьем посмотреть :)). и если основной канал падает и bgp переключается на второй то только тогда он начинает пинговаться. грубо говоря второй аплинк не работает пока работает первый по bgp.

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

Share this post


Link to post
Share on other sites

попробуйте такой конфиг зебры

hostname blabla
password gjrf
!enable password gjrf
log file /var/log/zebra.log
interface eth0
ip address 91.90.19.33/26
!
interface eth1
ip address 95.67.4.130/30
!
interface eth2
ip address 195.226.192.254/24
!
interface lo0
!
ip forwarding
line vty

 

если не поможет, покажите bgpd.conf

Share this post


Link to post
Share on other sites

А зебра первым запускается? А то раз наткнулся на такие грабли. Сначало запускали bgpd а потом zebra. И помню вроде реально ерунда получалась.

Share this post


Link to post
Share on other sites

в том то и дело что если зебру запускать с таким конфигом:

hostname blabla

password gjrf

!enable password gjrf

log file /var/log/zebra.log

interface eth0

multicast

!

interface eth1

multicast

!

interface eth2

multicast

!

interface lo0

!

ip route 0.0.0.0/0 ip связки с провом номер 1

ip route 0.0.0.0/0 ip связки с провом номер 2

!

ip forwarding

line vty

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

Share this post


Link to post
Share on other sites

покажите маршруты на bgp сервера аплинков.

И настройте bgp так, чтобы AS аплинков роутились только напрямую.

Похоже на то, что при подъеме bgp у вас все маршруты строятся через одного аплинка, в том числе и маршруты на as второго аплинка. А второй очень не хочет принимать ваши анонсы от своих аплинков, а не от вас...

Share this post


Link to post
Share on other sites

а как сделать чтобы АС аплинков роутились напрямую? тупо сетки асок роутить статически? как раз тут тоже второй канал организовываю

Share this post


Link to post
Share on other sites

ну лично я делаю так:

router bgp 41709
....
bgp router-id 193.192.36.1
...
network 193.192.36.0/23
network 94.158.32.0/20
! ITEAM
...
neighbor xxx.xxx.xxx.xxx route-map LLUGANET-IN in
...
ip prefix-list LLUGA seq 5 permit 194.146.132.0/22
ip prefix-list LLUGA seq 10 permit 93.157.24.0/21
ip prefix-list LLUGA seq 25 permit 10.16.0.0/12
ip prefix-list LLUGA seq 30 permit 10.32.0.0/11
ip prefix-list LLUGA seq 35 permit 10.64.0.0/10
ip prefix-list LLUGA seq 40 permit 10.128.0.0/9
...
route-map LLUGANET-IN permit 10
match ip address prefix-list LLUGA
set local-preference 165
...
route-map LLUGANET-IN permit 20
set local-preference 100
...

 

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

Как то так

Edited by martin74

Share this post


Link to post
Share on other sites

итак проблема решена с помощью совета на другом форуме, но я думаю не лишним это будет написать и сдесь.

вот что спросил человек:

что в net.ipv4.conf.all.rp_filter?
мой ответ первый:
0 а что должно быть?
и вот мой ответ второй:
ураааааааааааааааааааааа :) огромное вам человеческое спасибо за этот бесценный совет. не смотря на то что в этом файле стоит 0, и якобы оно должно отрабатывать на все интерфейсы, я посмотрел что конкретно стоит на каждом интерфейсе, и конечно там почему-то стояло по умолчанию 1, и это перекрывало значение с файла который в папке all. сменил на 0 на каждом интерфейсе, и все заработало. еще раз спасибо всем кто откликнулся :)
надеюсь ответ понятен.

 

так же хочу всех поблагодарить всех кто откликнулся в этой теме.

спасибо :))))

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this