quagga две сессии один вышестоящий

[quagga две сессии один вышестоящий]

Коллеги, ну все получилось, методом тыка :-)

 

bgpd.conf сделали таким:

 

!

! Zebra configuration saved from vty
!   2010/10/09 14:32:09
!
hostname bgpd
password test
enable password test
log file /var/log/quagga/bgpd.log
!
router bgp 65131
 bgp router-id 77.90.160.50
 network 210.130.60.0/24
 neighbor 77.90.160.49 remote-as 4186

!
router bgp 65131
 bgp router-id 77.90.160.40
 network 210.130.60.0/24
 neighbor 77.90.160.39 remote-as 4186
!
line vty
!

 

 

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

 

Вопрос, мы видим что входящий весь ходит через основной канал а исходящий через резервный, на резервном входящий вообще не используется, это нормально? :-)

[quagga две сессии один вышестоящий]

5 часов назад, murano сказал:

 

Чтобы Вам помогли, покажите реальный конфиг, а не «взятый из интернета».

Мы выложили наши конфиги с правкой по IP адресам и AS.

 

Вы меня не совсем поняли, это шаблон взятый из интернета и поправленный под нас.

[quagga две сессии один вышестоящий]

5 часов назад, murano сказал:

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

дак и просим помощи в правке нашего конфига.

 

конфиг наш взятый из примера в интернете.

[quagga две сессии один вышестоящий]

коллеги, приветствую.

 

прошу помощи, задача простая:

 

нужно поднять две bgp сессии на кваге или на бирде (в нашем случае у нас квага)

 

Debian 10

 

enp130s0f0 - интерфейс вышестоящего

enp130s0f1 - наша внутренняя сеть

77.90.160.50 - сеть /30 для стыковки с вышестоящим на интерфейсе вышестоящего

 

приватная AS между нами и вышестоящим 65131
 

bgpd.conf (конфиг по ип адресам и номером AS вышестоящего изменен)

!
! Zebra configuration saved from vty
!   2010/10/09 14:32:09
!
hostname bgpd
password test
enable password test
log file /var/log/quagga/bgpd.log
!
router bgp 65131
 bgp router-id 77.90.160.50
 network 210.130.60.0/24
 neighbor 77.90.160.49 remote-as 4186
!
line vty
!

!
! Zebra configuration saved from vty
! 2010/10/08 17:18:57
!
hostname zebra
password test
enable password test
!
log file /var/log/quagga/zebra.log
!
interface enp130s0f0
interface enp130s0f1
!
ip forwarding
!
line vty

 

 

 

Вышестоящий выделил нам еще одну подсеть на его интерфейсе enp130s0f0- 77.90.160.40/32 для резервного канала, с еще одной bgp сессией

 

Физически канал к вышестоящему один, но трафик ходит по этим двум сетям выше нас уже по разным физическим трассам.

 

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

 

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

 

Спасибо!

 

[airfiber 5u vlan не пробрасывает тэги]

20 часов назад, Xfactor3000 сказал:

В начале у вас релейка не пробрасывает, теперь коммутатор виноват. А может настройка неправильна, не?

 

все перепроверяли по нескольку раз.

 

все решилось просто с переключением в простой медный порт.

 

я думаю, что это странность поведения самого коммутатора.

[airfiber 5u vlan не пробрасывает тэги]

Всем спасибо.

 

Оказалась проблема видимо в DGS-1210-16

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

 

Переставили airfiber в 10 порт - все завелось.

[airfiber 5u vlan не пробрасывает тэги]

привет всем.

 

столкнулись со следующей проблемой.

 

схема такая:

DGS-1210-16 -> Airfiber 5u > DES-3526

 

не пробрасывает виланы с тэгом.

первый нетегированный вилан видит, тэгированные не пробрасывает.

 

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

 

Здесь как я понимаю ситуация иная.

 

Прошу помощи.

[Assymetric NAT на Linux]

приветствую всех. не подскажите, как данный проект нам подзаточить под аутсорминг?

 

например: есть абонент с серым адресом, на которого мы делаем snat с одного белого ip. мы так делаем потому что так нам удобнее.

 

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

[2 канала от одного оператора, сервер доступа на Debian]

13 минут назад, Saab95 сказал:

Лучше решения когда все передается по 10Г порту нет.

Сами ранее с провайдерами мирились, если он по 10Г не мог подключить, но там и провайдеры все же были гибче в плане настроек - все маршрутизировали или по BGP связь была.

А когда начали появляться варианты подключения к другим уже по 10Г, сразу у старых тоже появилась техническая возможность сделать стык на 10Г портах. Главное сказать что через месяц от них отключаемся.

я думал об этом.

[2 канала от одного оператора, сервер доступа на Debian]

10 часов назад, Saab95 сказал:

Можно и так сделать, только после проблемы выискивать. Современные операторы так не делают. Обычно все агрегации на уровне L3 производят.

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

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

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

 

6 часов назад, NiTr0 сказал:

дадада, из говна и веток в виде костылей с балансировкой половинками подсетей и скриптами, перекидывающими маршруты при отвале одного из линков)))

 

вижу у всех мнения расходятся, я как раз думал и о том, и о том :-)

конечно удобней железный вариант, скрипты городить не хотелось бы :-)

 

7 часов назад, rm_ сказал:

Вот над этим советую хорошо подумать, или хотя бы хоть сколько-то подумать, если у вас от коммутатора "10G до сервера", то зачем с сервера "обратно" по ДРУГОМУ порту-то.

 

Можно и на коммутаторе, но это выглядит как "я не умею в линуксе настроить бондинг, лучше натыкаю его же мышкой в веб-интерфейсе коммутатора".

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

 

Буду откровенен, смотря на разделение мнений, сам теперь не знаю к чему совету прислушаться :-)

 

 

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

[2 канала от одного оператора, сервер доступа на Debian]

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

 

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

 

что скажете?

 

в ядре стоит у нас snr s2990g-24fx

[2 канала от одного оператора, сервер доступа на Debian]

18 минут назад, Saab95 сказал:

Видимо оператор даст вам еще один канал на 1г., даст еще один адрес для связи в этом новом канале. После пропишет статическую маршрутизацию уже на 2 адреса, и первый пакет пойдет через первый канал, второй пакет пойдет через второй, третий через первый, четвертый через второй и так далее. Вы со своей стороны так же пропишите второй маршрут на 0.0.0.0/0 в сторону нового шлюза провайдера и всего делов.

 

Не надо тратить время на прочтения всяких глупостей в интернете. По сути у вас будет как бы канал в 2Г общей скорости. Нужно обратить внимание на то, что будет, если один канал потухнет - тогда и интернет полностью перестанет работать - нужно сделать перекрестную проверку пингом обоих каналов. Что бы при отключении одного ваше оборудование, и оборудование оператора исключала этот канал из работы.

вот о том, о чем Вы написали я и думал.

 

Каким образом нам отдают эти адреса,

допустим, у нас 4 пула /24.

42.172.10.0

42.172.11.0

42.172.12.0

42.172.13.0

 

в каждой подсети 254 адрес - адрес шлюза вышестоящего.

мы поднимаем в каждом пуле соответственно для себя 253

 

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

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

[2 канала от одного оператора, сервер доступа на Debian]

Всем привет.

 

Буду краток.

 

Имеем одного аплинка, работаем по схеме аутсорминга,сорм на стороне вышестоящего.

 

Статический ип на каждого своего абонента.

Ип адреса берем так же у вышестоящего.

 

Никакого BGP, просто пробрасывают ип адреса статической маршрутизацией на наш канал в Интернет. Берем у них ип адреса подсетями /24.

 

Берем гигабит, но уже и его стало мало. 10G дать нам не могут. (обещали, но не смогли). Очень обидно, так как мы со своей стороны уже подготовились в переходу, на сервере доступа стоит двухпортовая X520-DA2 и в ядро поставили SNR s2990g-24fx.

 

Сервер с Debianом

 

Работает ipset, accel-ppp, работает proxy-arp

Часть клиентов авторизируются по PPPoE, другая работает по статике.

 

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

 

Прошу сильно не ругаться и не смеяться :-) набираюсь опыта по мере появления каких либо проблем.

 

Прошу помощи и совета!

[managment vlan на коммутаторах]

1 час назад, dvb2000 сказал:

А Traffic Storm Control уже совсем запрещается использовать ? Или он больше не практикуется и считается старомодным?

 

подскажите пожалуйста оптимальное значение Storm Control, у нас почти везде коммутаторы D-Link.

в сети работает и PPPoE сервер и DHCP.

storm control везде с одним параметром использовать? только на коммутаторах доступа или везде?

если можно поподробнее пожалуйста.

[managment vlan на коммутаторах]

в общем, как лучше сделать все же, создать отдельный vlan и перенести туда управление с каждого коммутатора? или все же на каждый коммутатор выделить под управление собственный/отдельный vlan для управления?

[managment vlan на коммутаторах]

Только что, alibek сказал:

vlan 1 использовать не стоит.

как стоит сделать? почему не стоит? интересно ваше мнение.

[managment vlan на коммутаторах]

всем привет.

 

нужен совет.

 

правильно ли мы делаем или нет.

 

используем схему vlan на коммутатор, коммутатор - это какой-то дом или объект. включаем сегментацию на аплинк порт.

 

правильно ли мы делаем оставляя управление в первом vlane на всех коммутаторах ?

в первом vlan нет абонентов, только наши железки.

 

как лучше будет? дайте совет пожалуйста.

 

[Проблема со скоростью]

13 часов назад, Корпич сказал:

На всякий случай MTU проверьте

какое MTU у нас должно быть? стоит по умолчанию все, 1500

[Проблема со скоростью]

9 минут назад, sdy_moscow сказал:

Искать причины потерь. Вангую - 2.4 ГГц эфир засран по самое не балуйся. Переходите на 5 ГГц с узко направленными антеннами.

Вы очень невнимательны. Есть схема. 5 ГГц.

[Проблема со скоростью]

2 часа назад, Saab95 сказал:

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

имеете виду timeout ?

 

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

все ок, потерь нет.

 

посылаем до клиента - видим потери. из 300 пакетов добрались только 282. 4% потерь.

 

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

 

спасибо за наводку конечно! но видимо какое-то есть узкое место где-то...

 

[Проблема со скоростью]

3 часа назад, Saab95 сказал:

У вас по частотам оборудование друг другу не мешает?

Не пробовали делать тест с первой станции моста на адрес БС?

частоты далеко друг от друга, 400 мгц разница.

 

Про тест имеете ввиду первый LHG который идет от центра к какой нибудь из базовых? - если да, то пробовали - 100 мегабит к базе приходит без проблем, а вот уже после базы в два раза падает. В этом весь прикол, и в чем дело непонятно. Если бы к базе не приходило бы нужное количество - само собой разумеющееся меняли бы коммутатор который на базах. а тут до баз приходит, а после баз уже нет, но при этом если тестировать напрямую с базы до абонента -к нему прилетает 100 мегабит в полосе 20 мгц, в полосе 40 - чуть больше 150, эфир не такой шумный. нормальный.

 

3 часа назад, npokypop сказал:

Была похожая схема и ситуация, только у нас вместо DES-1005a стояла другая мыльница, выбросили ее и поставили hex poe, все стало как надо. 

mANTBox 15s как настроен ? Просто bridge или routing ?

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

все настроено в режиме bridge, клиентский LHG в режиме роутера.

[Проблема со скоростью]

привет всем.

 

наблюдаю проблему со скоростью до абонентского устройства LHG5. Скорость режется раза в два.

 

Делаю тест скорости с устройства "Мост LHG5 (1)" до Клиентского LHG5 стандартным тестом на микротике, UDP пакетами. Вижу падение скорости в два раза, то есть в 50 мегабит.

При этом когда делаю тест до базовых станций mANTBox 15s и SXT SA5 - я вижу 100 мегабит.

Когда делаю тест с моста на мост - вижу свыше 100 мегабит (мосты работают в полосе 40 мгц)

Когда делаю тест от Базы к Клиенту - вижу 100 мегабит (полоса 20 мгц)

 

Подскажите что нибудь. Почему теряются эти 50 мегабит.

 

Схему прикрепляю.

[скорость и дуплекс в коммутаторах DGS-1100-08]

1 час назад, Adim сказал:

решилась совсем или как?

да, глюков со скоростью не наблюдаем.

 

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

[скорость и дуплекс в коммутаторах DGS-1100-08]

Включив все же принудительно flow control на ethernet порту приемного моста микротика - проблема решилась.

[скорость и дуплекс в коммутаторах DGS-1100-08]

8 часов назад, jffulcrum сказал:

Если скорость на выходе и на выходе различается - коммутатору нужно буферизировать. Буферизировать у DGS-1100-08  просто нечем - буфер пакетов там 256 кб. Вообще, посмотрите в 

 там полным ходом обсуждение причин и решений. Технически может помочь включение flow-control на всех устройствах и на портах коммутатора - тогда коммутатор будет источнику отправлять сигнал пауза, если приемник уже не может принять или переполнен буфер самого коммутатора. Проблема в том, что этим заниматься будет CPU, а у данной балалайки он тоже символический - неизвестно, что будет хуже работать.

 

Спасибо! включение flow control помогло, по факту выше 150 мегабит через него пролетать не будет, так как магистраль идет с радиомоста. Посмотрим как будет себя вести.

 

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

 

расстроился)