LINUX.ORG.RU
ФорумAdmin

quagga два аплинка


0

1

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

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

1. Работают ли обе сессии одновременно ?
2. На неработающем канале трафика нет в обе стороны, или только в одну ?
3. Если обе сессии работают, какова таблица анонсов по каждому из каналов ?
4. пинг - это странно. Там direct, должно работать всегда. Нет ли какой фигни, что там не с тем src ip какие-то пакеты уходят к какому-то из пиров ? Хотя, по идее, в таком случае вообще работать не должно. Мультихопа, кстати, нет ?
5. Я тоже не особенно представляю, чего там может не быть в ядре.
6. Что за дистрибутив, какая версия Квагги ?

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

AS ★★★★★ ()
Ответ на: комментарий от AS

> 6. Что за дистрибутив

Это увидел. :-)

AS ★★★★★ ()
Ответ на: комментарий от AS

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

victor3000 ()
Ответ на: комментарий от victor3000

А что tcpdump показывает ? icpm-пакеты до неработающего пира в нужный канал уходят ? С правильным src ip ? Есть ещё www.traceroute.org. Тоже можно посмотреть... Линки, кстати, на своих IP, или IP соседей ? Хотя последнее не должно быть важно.

В общем, при работающем канале, надо смотреть tcpdump-ом, куда уходит icmp echo до IP неработающего канала. Если уходит куда надо, трясти оператора на тему, куда девается ответ. Пиры, кстати, на /30 сетях сделаны, или как ?

AS ★★★★★ ()
Ответ на: комментарий от vladislav

итак 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?

ip связяк принадлежат провайдерам и прописаны на интерфейсах.

victor3000 ()
Ответ на: комментарий от victor3000

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

vladislav ★★ ()
Ответ на: комментарий от victor3000

Кто первый, кто второй ? :-) Первый - который работает, второй - который лежит ?

Если пингается IP второго провайдера, то это непонятно, как. Свой диапазон есть ? Вот только он и должен анонсироваться. Соответственно трафик на этот IP никак не должен попадать через первый канал.

И, вообще, я просил _изнутри_, а не снаружи. Зачем усложнять раньше времени ?

хотя я так понимаю если пакеты приходят на второй интерфейс, ответы

должны уходить через первый. то что пакеты приходят



Они должны уходить в соответствии с таблицей маршрутизации, которая получается на основе обработки BGP-таблиц(ы).

Конфиг читается плохо... Зачем там мультикаст и зачем там два маршрута по-умолчанию ?

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

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


Пока рано. И какая версия квагги в Федоре ? Я Федорой не пользуюсь, искать не хочется.

ip связяк принадлежат провайдерам и прописаны на интерфейсах.


Я ещё про используемые маски спросил. ТАм ethernet читый ? pppoe нет никаких ?

AS ★★★★★ ()
Ответ на: комментарий от vladislav

> В Вашем случае зебра вообще не нужна. По крайней мере убрать все дефолтные маршруты, и добавить, если необходимо,

маршрут до следующего хопа. Дефолт Вам должны отдать через BGP.


Как ему отдадут что-то по BGP без зебры ? :-)

AS ★★★★★ ()
Ответ на: комментарий от AS

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

А в этом случае - в таблице минимум два равнозначных дефолта. Вот их лучше все таки разруливать через BGP.

vladislav ★★ ()
Ответ на: комментарий от vladislav

> Насколько я понял у него два провайдерских айпи, т.е. маршруты на провайдеров

прописаны на интерфейсах.


Если речь зашла про BGP, то, видимо, у него своя автономная система со своим диапазоном IP. Вопрос по пренадлежность IP я задавал только с целью понять, как должен идти трейс снаружи до IP каждого из пиров при лежащем втором.

Если пиры находятся в этих подсетях - зачем зебра? Если нет, достаточно маршрута до пира.


Зебра затем, что Quagga - это комплекс демонов. Есть демоны, обрабатывающие тинамические таблицы, а есть zebra, которая обеспечивает их связь с ядром. bgpd без zebrad будет сферическим конём.

Что касается двух дефолтов, это не есть хорошо: без полной таблицы невозможно условно нормально балансировать исходяший трафик. Если у него есть возможность использовать full view, это лучше делать.

AS ★★★★★ ()
Ответ на: комментарий от AS

Quagga (version 0.99.17) изнутри пингуются связки в сторону провайдеров всегда. маска на первого прова /26 на второго /30 с мультикастами, без них, без маршрутов в зебре, одновременно два канала работать по bgp не хотят, хотя оба в эстаблишь. один из двоих работает без проблем в любой комбинации. и последние, езернет чистый в оба направления.

victor3000 ()
Ответ на: комментарий от victor3000

> Quagga (version 0.99.17)

Ух ты, я обновление пропустил...

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

хотя оба в эстаблишь.



Это хорошо. Без мультикастов они тоже в эстаблишь ?
Вообще я не очень понимаю, при чём тут мультикасты. Откуда такой конфиг взялся вообще ?

без маршрутов в зебре, одновременно два канала работать по bgp не хотят


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

Давай попробуй сначала. Из zebra.conf убирай всё лишнее. Пусть останется что-то вроде

hostname router
! default password is 'zebra'
password 8 LrjDz/a2KALVQ
enable password 8 LrjDz/a2KALVQ
log file /var/log/quagga/zebra.log informational
service password-encryption
no banner motd
!
interface lo
description loopback
!
access-list localhost permit 127.0.0.1/32
access-list localhost deny any
!
!
line vty
access-class localhost
!

Только, сначала, покажи конфиг bgpd на всякий случай. И «user line breaks» выбери, чтобы конфиг не поехал.

AS ★★★★★ ()
Ответ на: комментарий от AS

вот такая дополнительная инфа №1 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 №2 ip route | wc -l 328251

victor3000 ()
Ответ на: комментарий от victor3000

> 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



И, при этом, трафик идёт только через один канал ? И входящий, и исходящий ?

bgpd рабочего у меня нет, буду по Циске ориентироваться. Может быть, каких-то команд у Квгги не окажется.

Если сказать «clear ip bgp <Neighbor's IP>», что происходит ? Для неработающего пира.

Ещё интересно для него же (тут много должно быть, всё смотреть не обязательно, важен принципиальный момент):
sho ip bgp neighbors <Neighbor's IP> received-routes
sho ip bgp neighbors <Neighbor's IP> routes

Здесь должна быть только своя сеть:
sho ip bgp neighbors <Neighbor's IP> advertised-routes

Total number of neighbors 2 №2 ip route | wc -l 328251


Это не понял. Попавшие в ядро маршруты со второго пира ? В теории, конечно, возможно, если первый пир тебе маршруты даёт с большим количеством as path prepend. В этом случае вот оно и пожалуйста.

И выбирай «user line breaks» под окошком ввода на LOR. Ну читать же конфиги/копипасты невозможно.

AS ★★★★★ ()
Ответ на: комментарий от victor3000

> 95.67.4.129 4 34867

Не работает вот этот, как я понимаю ? По крайней мере через 13307 я сеть вижу.

AS ★★★★★ ()
Ответ на: комментарий от victor3000
ip route | wc -l 
328251

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

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Понятно, что маршрутов в ядре должно быть сопостовимое с full view количество с очень маленькой погрешностью. Просто не сильно понятно с его форматированием, что там у него где выводится. Вряд ли проблема в связности, раз там количество принятых префиксов нормальное. Другой вопрос, какой там as path получается. Возможно, надо подровнять через as path prepend. Это, как раз, должен показать вывод

sho ip bgp neighbors <IP> received-routes

И с анонсом, возможно, та же проблема, это можно c какого-нибудь из ресурсов с traceroute.org посмотреть, отключая каналы по очереди.

AS ★★★★★ ()
Ответ на: комментарий от AS

Это я и имел ввиду под связностью - если провайдер1 покупает канал у провайдера2 к примеру, а ТС подключен к обоим. То провайдер1 будет отдавать ему заведомо больший as path, и весь трафик полетит через провайдера2. Препендов можно конечно наставить, и локалпреф.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

> если провайдер1 покупает канал у провайдера2

Да, возможный вариант. Но это уже можно сейчас проверить. Данные он дал: AS13307 и AS34867

И таки у кого-то их них косячок:

$ whois AS13307|grep AS34867
$ whois AS34867|grep AS13307
import: from AS13307 action pref=90; accept AS-SKIF
export: to AS13307 announce AS-COSMONOVA

То ли в AS13307 добавить забыли, то ли в AS34867 убрать. Кстати, есть ещё... Но на то, что кто-то у кого-то покупает, не похоже. Просто пиринг, видимо.

В общем, с обоих его видно, как говорят:
http://www.ris.ripe.net/dashboard/51299

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

AS ★★★★★ ()
Ответ на: комментарий от AS

если второй падает, обрыв провода, просто down и т.д. , то красиво подымается другой, при востановлении первого все возращается назад

когда один канал не работает то судя по истории все ходит нормально через другой. А когда все первый поднимается - все возвращается назад - сильно похоже что as-path для большинства префиксов через AS13307 всегда короче.

AS34867 в ua-ix его не анонсит. Райп говорит так же что в анонсе в AS34867 еще три препенда всунуто, вот и не идет туда трафик.

Какие коммюнити он ставит тоже покрыто мраком, whois AS34867 довольно много описывает вариантов. Неплохо бы конфиг

ventilator ★★★ ()
Ответ на: комментарий от ventilator

> когда один канал не работает то судя по истории все ходит нормально через другой. А когда все первый поднимается - все возвращается назад - сильно похоже что as-path для большинства префиксов через AS13307 всегда короче.

BGP в этом случае не причем. У него два дефолта - вот «красиво» и подымается

vladislav ★★ ()
Ответ на: комментарий от ventilator

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

возвращается назад - сильно похоже что as-path для большинства префиксов через AS13307 всегда короче.


Только это не объясняет, почему всё начинает работать как надо после рестарта зебры. Либо victor3000, всё-таки, не совсем точно ситуацию описывает. Так бы на проблемы с препендами было похоже...

AS ★★★★★ ()
Ответ на: комментарий от AS

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

victor3000 ()
Ответ на: комментарий от victor3000

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)

victor3000 ()
Ответ на: комментарий от victor3000

> думаю решим с ним

Без обид, но ещё надо решить с запятыми и прочими знаками препинания: с трудом понимаю. :-(

ip сзязки провов 91.90.19.61 основной и 95.67.4.129 забудем про маршруты получаемые по bgp и т.д.


То есть, 91.90.19.61 - основной, 95.67.4.129 - это который поднимается только тогда, когда лежит основной ?

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


То есть, ip провов 91.90.19.61 и 95.67.4.129 снаружи всегда пингуются ?

мои ip сзязки пингуются из вне только до момента запуска демона bgpd


То есть, 91.90.19.33 и 95.67.4.130 снаружи доступны, пока не запущен bgpd. Так ?

пингуется только один( на второй пакеты приходят, я это видел tcpdumpom, но никуда не уходят, смотрел на первом

и втором интерфейсе,



Те, которые уходят, уходят через тот же интерфейс ? А те, которые для второго интерфейса, через какой интерфейс приходят ? Через свой, или через чужой ?

Если приходят через чужой, то
1. глупый вопрос. А что показывает cat /proc/sys/net/ipv4/ip_forward ?
2. Я же говорил, надо смотреть таблицу анонсов. Судя по всему, туда попадают ненужные чужие сети, а на той стороне, наверное, фильтры не сделаны.

нада еще на третьем посмотреть :)).


Это точно лучше не надо, надо с двумя разобраться. :-)

AS ★★★★★ ()
Ответ на: комментарий от ventilator

> у нас тут прямо сеанс телепатической диагностики)

Да уж... ;-)

AS ★★★★★ ()
Ответ на: комментарий от AS

>То есть, 91.90.19.61 - основной, 95.67.4.129 - это который >поднимается только тогда, когда лежит основной ?

да

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


То есть, ip провов 91.90.19.61 и 95.67.4.129 снаружи всегда >пингуются ?


да

мои ip сзязки пингуются из вне только до момента запуска демона bgpd


То есть, 91.90.19.33 и 95.67.4.130 снаружи доступны, пока не запущен >bgpd. Так ?


да

Те, которые уходят, уходят через тот же интерфейс ? А те, которые >для второго интерфейса, через какой интерфейс приходят ? Через свой, >или через чужой ?


пакеты приходят на второй интерфейс. и никуда не уходят.

Если приходят через чужой, то

1. глупый вопрос. А что показывает cat /proc/sys/net/ipv4/ip_forward ?
2. Я же говорил, надо смотреть таблицу анонсов. Судя по всему, туда попадают ненужные чужие сети, а на той стороне, наверное, фильтры не >сделаны.
конечно 1 ;)

victor3000 ()
Ответ на: комментарий от victor3000

>> Те, которые уходят, уходят через тот же интерфейс ? А те, которые для второго интерфейса, через какой интерфейс

приходят ?Через свой, или через чужой ?


пакеты приходят на второй интерфейс. и никуда не уходят.


То есть, на свой. Если «ip r|grep 95.67.4.129» сделать, пусто получается (или только дефолт - не важно) ? То есть, согласно таблице маршрутизации, reply-пакеты должны через другой интерфейс уходить ?

Если так, то, всё-таки, дело в как-то перекрытом форвардинге.

AS ★★★★★ ()
Ответ на: комментарий от AS

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

victor3000 ()
Ответ на: комментарий от victor3000

> я первый раз строю bgp, по этому куда они должны уходить незнаю.

bgp тут виновен только в изменении таблицы маршрутизации, то есть совсем косвенно совсем. Кстати, это легко проверить. Надо оставить только один default gw, который в сторону работающего канала. Кваггу просто положить, чтобы не думалось, и начать пингать снаружи свой IP другого канала. В этом случае, точно так же, приходить пакет должен будет одним каналом, а уходить другим. Подозреваю, что уходить пакет точно так же не будет.

AS ★★★★★ ()
Ответ на: комментарий от AS

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

что в net.ipv4.conf.all.rp_filter?

ventilator ★★★ ()
Ответ на: комментарий от ventilator

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

victor3000 ()
Ответ на: комментарий от ventilator

> Ну ответ на пинг будет уходить другим каналом и его провайдер с большой долей вероятности дропнет, потому

что src ip там из автономки другого прова.


Это был следующий момент. :-) Тут же получалось, что пакета просто нет на исходящем интерфейсе. Кроме того, учитывая, что у них там пиринг возможно, может и не дропнет.

что в net.ipv4.conf.all.rp_filter?


А вот про это я что-то не подумал. :-)

AS ★★★★★ ()
Ответ на: комментарий от victor3000

> и все заработало.

А вот это странно. То есть, не работало только из-за rp_filter ? Но, в этом случае, хоть какой-то трафик должен был уходить через тот же интерфейс, полного отсутствия трафика не должно было быть. Ещё момент. C src ip внешних интерфейсов лучше бы только BGP-трафик гнать. Трафик обычных приложений лучше уже со своим src ip пускать, как раз по причине фильтрации марсианских пакетов (да-да, это термин такой :-) )

AS ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.