From: |
Eugene Grosbein grosbein.net |
02 Aug 2021 06:04 +0300 |
To: |
Anton Gorlov 2:5059/37@FidoNet |
|
Subject: |
FRR
|
21 июня 2021, понедельник, в 08:57 NOVT, Anton Gorlov написал(а):
AG>>> Аха. Поковырю тога на стенде и если всё ок потащу взамен квагги.
AG>>> Там даже bfd есть.
EG>> Сразу предупреждаю: у frr в настоящее время идёт процесс перехода
EG>> от отдельных конфигов каждого демона - и этот режим глючный,
EG>> например, демон зебра может "не видеть" ACL или route-map,
EG>> определённый в bgpd.conf - к единому конфигу frr.conf,
EG>> но дефолтный режим ещё старый. Чтобы использовать лучше работающий
EG>> общий конфиг, надо в rc.conf прописать frr_vtysh_boot="YES",
EG>> то есть:
AG> Окак. Спасибо за предупреждение.
Попробовал я тут OSPF на frr7 несколько дней назад.
Hадо признать, у мертвой квагги её ospfd гораздо живее,
чем у frr7. Четыре дня назад вышла frr8, но судя по релизнотесам
OSPF там лучше не стал, правда я ещё не тестировал.
Во-первых, два ospfd в случае quagga без проблем вяжутся
в одном сегменте ethernet, если на интерфейсах есть алиасы с маской /32
(например, для CARP, но можно и без него), а в случае quagga+frr7
сам frr7 не желает делать соседства: авторы ospfd умеют только
в линуксовые алиасы (в виде сабинтерфейсов), а фрёвые алиасы
воспринимает не как "secondary-адреса", а только как "unnumbered".
Hу, эту проблему я запатчил достаточно простым самодельным патчем,
отправил его в FROG-лист их, ни одного комментария.
Вторая и более сложная проблема вылезла, когда мне в сетке
с двумя Микротиками в бекбоне и отдельной shortcut-областью
из двух фрях (DR+BDR), каждая из которых имеет по одному p2p-туннелю
к каждому из микротиков, не получилось проанонсировать с frr7
в бекбон областные маршруты (пробовал frr7 и в роли DR своей области,
и в роли BDR - одинаково).
Заменил frr7 на кваггу и всё заработало сразу, как ожидается:
каждый микротик принял по два LSA, по одному от каждой фряхи.
А пока стоял frr7 ровно с тем же конфигом для OSPF
(благо синтаксис совпадает) - у микротиков были LSA только от квагги,
хотя OSPF-соседства с frr7 тоже были.
Дедлайн подошел и пришлось на frr7 забить пока, будет жить квагга.
Eugene
--
Смотри, но не смей трогать
From: |
Sergey Anohin 2:5034/10.1 |
25 Jul 2021 13:35 +0300 |
To: |
Andrey Melnikoff <1187515102@banana.localnet> |
|
Subject: |
InnoDB+UFS+SSD
|
Hello, Andrey!
>> Для фидо пойдет.
AM> туда и sqlite3 пойдет.
Там что угодно пойдет, если ты умеешь на php кодить, чтобы сделать обертку и
прикрутить
какой-нить pdo, хотя как бы сейчас и используется php-mysqli
>> У меня MariaDB, там веб-моpды база кpутится от фидо, хочу унести на SSD под
>> эхотагом.
AM> Я бы понял, если бы ты какой говнозаббикс крутил - там дааа, тюнить надо,
AM> даже под SSD. А для фидо - всё в aria сконвертить и потянет, без тормоза
innodb.
База у меня торчит на ZFS, SSD под кеш ZFS.
Ну некоторые таблицы я перевел на Aria, но самые огромные оставил InnoDB, база
большая ~20гиг.
Вообще кстати, эксперимент с кешем SSD думаю прошел удачно. Раньше первый раз
когда заходило на веб морду,
тупило около минуты наверно, может больше. Через несколько дней работы ZFS плюс
SSD кеш, работает почти моментально.
Это все визуально на глаз, не подтверждено измерениями. Настройки ковырял и в
MariaDB и в ZFS.
Будет веселее на 13м эхотаге, когда кеш ZFS не будет обнуляться при ребуте, но
походу еще рано на 13ую уходить?
Настройки:
# zfs get all zroot/var/db/mysql
NAME PROPERTY VALUE SOURCE
zroot/var/db/mysql type filesystem -
zroot/var/db/mysql creation пт марта 16 22:18 2018 -
zroot/var/db/mysql used 19,9G -
zroot/var/db/mysql available 1,31T -
zroot/var/db/mysql referenced 19,4G -
zroot/var/db/mysql compressratio 1.51x -
zroot/var/db/mysql mounted yes -
zroot/var/db/mysql quota none
default
zroot/var/db/mysql reservation none
default
zroot/var/db/mysql recordsize 16K local
zroot/var/db/mysql mountpoint /var/db/mysql
inherited from zroot/var
zroot/var/db/mysql sharenfs off
default
zroot/var/db/mysql checksum fletcher4
inherited from zroot
zroot/var/db/mysql compression lz4 local
zroot/var/db/mysql atime off local
zroot/var/db/mysql devices on
default
zroot/var/db/mysql exec off
inherited from zroot/var/db
zroot/var/db/mysql setuid off
inherited from zroot/var/db
zroot/var/db/mysql readonly off
default
zroot/var/db/mysql jailed off
default
zroot/var/db/mysql snapdir hidden
default
zroot/var/db/mysql aclmode discard
default
zroot/var/db/mysql aclinherit restricted
default
zroot/var/db/mysql createtxg 11403386 -
zroot/var/db/mysql canmount on
default
zroot/var/db/mysql xattr off
temporary
zroot/var/db/mysql copies 1
default
zroot/var/db/mysql version 5 -
zroot/var/db/mysql utf8only off -
zroot/var/db/mysql normalization none -
zroot/var/db/mysql casesensitivity sensitive -
zroot/var/db/mysql vscan off
default
zroot/var/db/mysql nbmand off
default
zroot/var/db/mysql sharesmb off
default
zroot/var/db/mysql refquota none
default
zroot/var/db/mysql refreservation none
default
zroot/var/db/mysql guid 13227566777127831999 -
zroot/var/db/mysql primarycache metadata local
zroot/var/db/mysql secondarycache all local
zroot/var/db/mysql usedbysnapshots 0 -
zroot/var/db/mysql usedbydataset 19,4G -
zroot/var/db/mysql usedbychildren 478M -
zroot/var/db/mysql usedbyrefreservation 0 -
zroot/var/db/mysql logbias throughput local
zroot/var/db/mysql objsetid 257 -
zroot/var/db/mysql dedup off
default
zroot/var/db/mysql mlslabel -
zroot/var/db/mysql sync disabled local
zroot/var/db/mysql dnodesize legacy
default
zroot/var/db/mysql refcompressratio 1.52x -
zroot/var/db/mysql written 19,4G -
zroot/var/db/mysql logicalused 29,9G -
zroot/var/db/mysql logicalreferenced 29,4G -
zroot/var/db/mysql volmode default
default
zroot/var/db/mysql filesystem_limit none
default
zroot/var/db/mysql snapshot_limit none
default
zroot/var/db/mysql filesystem_count none
default
zroot/var/db/mysql snapshot_count none
default
zroot/var/db/mysql redundant_metadata all
default
zroot/var/db/mysql special_small_blocks 0
default
# zfs get all zroot/var/db/mysql/ibdata
NAME PROPERTY VALUE
SOURCE
zroot/var/db/mysql/ibdata type filesystem
-
zroot/var/db/mysql/ibdata creation пт марта 16 22:20 2018 -
zroot/var/db/mysql/ibdata used 4,89M
-
zroot/var/db/mysql/ibdata available 1,31T
-
zroot/var/db/mysql/ibdata referenced 4,89M
-
zroot/var/db/mysql/ibdata compressratio 3.74x
-
zroot/var/db/mysql/ibdata mounted yes
-
zroot/var/db/mysql/ibdata quota none
default
zroot/var/db/mysql/ibdata reservation none
default
zroot/var/db/mysql/ibdata recordsize 16K
local
zroot/var/db/mysql/ibdata mountpoint /var/db/mysql/ibdata
inherited from zroot/var
zroot/var/db/mysql/ibdata sharenfs off
default
zroot/var/db/mysql/ibdata checksum fletcher4
inherited from zroot
zroot/var/db/mysql/ibdata compression lz4
inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata atime off
inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata devices on
default
zroot/var/db/mysql/ibdata exec off
inherited from zroot/var/db
zroot/var/db/mysql/ibdata setuid off
inherited from zroot/var/db
zroot/var/db/mysql/ibdata readonly off
default
zroot/var/db/mysql/ibdata jailed off
default
zroot/var/db/mysql/ibdata snapdir hidden
default
zroot/var/db/mysql/ibdata aclmode discard
default
zroot/var/db/mysql/ibdata aclinherit restricted
default
zroot/var/db/mysql/ibdata createtxg 11403406
-
zroot/var/db/mysql/ibdata canmount on
default
zroot/var/db/mysql/ibdata xattr off
temporary
zroot/var/db/mysql/ibdata copies 1
default
zroot/var/db/mysql/ibdata version 5
-
zroot/var/db/mysql/ibdata utf8only off
-
zroot/var/db/mysql/ibdata normalization none
-
zroot/var/db/mysql/ibdata casesensitivity sensitive
-
zroot/var/db/mysql/ibdata vscan off
default
zroot/var/db/mysql/ibdata nbmand off
default
zroot/var/db/mysql/ibdata sharesmb off
default
zroot/var/db/mysql/ibdata refquota none
default
zroot/var/db/mysql/ibdata refreservation none
default
zroot/var/db/mysql/ibdata guid 12007562024988368572
-
zroot/var/db/mysql/ibdata primarycache metadata
inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata secondarycache all
inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata usedbysnapshots 0
-
zroot/var/db/mysql/ibdata usedbydataset 4,89M
-
zroot/var/db/mysql/ibdata usedbychildren 0
-
zroot/var/db/mysql/ibdata usedbyrefreservation 0
-
zroot/var/db/mysql/ibdata logbias throughput
inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata objsetid 263
-
zroot/var/db/mysql/ibdata dedup off
default
zroot/var/db/mysql/ibdata mlslabel
-
zroot/var/db/mysql/ibdata sync disabled
local
zroot/var/db/mysql/ibdata dnodesize legacy
default
zroot/var/db/mysql/ibdata refcompressratio 3.74x
-
zroot/var/db/mysql/ibdata written 4,89M
-
zroot/var/db/mysql/ibdata logicalused 17,9M
-
zroot/var/db/mysql/ibdata logicalreferenced 17,9M
-
zroot/var/db/mysql/ibdata volmode default
default
zroot/var/db/mysql/ibdata filesystem_limit none
default
zroot/var/db/mysql/ibdata snapshot_limit none
default
zroot/var/db/mysql/ibdata filesystem_count none
default
zroot/var/db/mysql/ibdata snapshot_count none
default
zroot/var/db/mysql/ibdata redundant_metadata all
default
zroot/var/db/mysql/ibdata special_small_blocks 0
default
# zfs get all zroot/var/db/mysql/iblogs
NAME PROPERTY VALUE
SOURCE
zroot/var/db/mysql/iblogs type filesystem
-
zroot/var/db/mysql/iblogs creation пт марта 16 22:20 2018 -
zroot/var/db/mysql/iblogs used 474M
-
zroot/var/db/mysql/iblogs available 1,31T
-
zroot/var/db/mysql/iblogs referenced 474M
-
zroot/var/db/mysql/iblogs compressratio 1.08x
-
zroot/var/db/mysql/iblogs mounted yes
-
zroot/var/db/mysql/iblogs quota none
default
zroot/var/db/mysql/iblogs reservation none
default
zroot/var/db/mysql/iblogs recordsize 128K
local
zroot/var/db/mysql/iblogs mountpoint /var/db/mysql/iblogs
inherited from zroot/var
zroot/var/db/mysql/iblogs sharenfs off
default
zroot/var/db/mysql/iblogs checksum fletcher4
inherited from zroot
zroot/var/db/mysql/iblogs compression lz4
inherited from zroot/var/db/mysql
zroot/var/db/mysql/iblogs atime off
inherited from zroot/var/db/mysql
zroot/var/db/mysql/iblogs devices on
default
zroot/var/db/mysql/iblogs exec off
inherited from zroot/var/db
zroot/var/db/mysql/iblogs setuid off
inherited from zroot/var/db
zroot/var/db/mysql/iblogs readonly off
default
zroot/var/db/mysql/iblogs jailed off
default
zroot/var/db/mysql/iblogs snapdir hidden
default
zroot/var/db/mysql/iblogs aclmode discard
default
zroot/var/db/mysql/iblogs aclinherit restricted
default
zroot/var/db/mysql/iblogs createtxg 11403407
-
zroot/var/db/mysql/iblogs canmount on
default
zroot/var/db/mysql/iblogs xattr off
temporary
zroot/var/db/mysql/iblogs copies 1
default
zroot/var/db/mysql/iblogs version 5
-
zroot/var/db/mysql/iblogs utf8only off
-
zroot/var/db/mysql/iblogs normalization none
-
zroot/var/db/mysql/iblogs casesensitivity sensitive
-
zroot/var/db/mysql/iblogs vscan off
default
zroot/var/db/mysql/iblogs nbmand off
default
zroot/var/db/mysql/iblogs sharesmb off
default
zroot/var/db/mysql/iblogs refquota none
default
zroot/var/db/mysql/iblogs refreservation none
default
zroot/var/db/mysql/iblogs guid 2433669013503756839
-
zroot/var/db/mysql/iblogs primarycache metadata
inherited from zroot/var/db/mysql
zroot/var/db/mysql/iblogs secondarycache all
inherited from zroot/var/db/mysql
zroot/var/db/mysql/iblogs usedbysnapshots 0
-
zroot/var/db/mysql/iblogs usedbydataset 474M
-
zroot/var/db/mysql/iblogs usedbychildren 0
-
zroot/var/db/mysql/iblogs usedbyrefreservation 0
-
zroot/var/db/mysql/iblogs logbias latency
local
zroot/var/db/mysql/iblogs objsetid 269
-
zroot/var/db/mysql/iblogs dedup off
default
zroot/var/db/mysql/iblogs mlslabel
-
zroot/var/db/mysql/iblogs sync disabled
local
zroot/var/db/mysql/iblogs dnodesize legacy
default
zroot/var/db/mysql/iblogs refcompressratio 1.08x
-
zroot/var/db/mysql/iblogs written 474M
-
zroot/var/db/mysql/iblogs logicalused 512M
-
zroot/var/db/mysql/iblogs logicalreferenced 512M
-
zroot/var/db/mysql/iblogs volmode default
default
zroot/var/db/mysql/iblogs filesystem_limit none
default
zroot/var/db/mysql/iblogs snapshot_limit none
default
zroot/var/db/mysql/iblogs filesystem_count none
default
zroot/var/db/mysql/iblogs snapshot_count none
default
zroot/var/db/mysql/iblogs redundant_metadata all
default
zroot/var/db/mysql/iblogs special_small_blocks 0
default
# cat /usr/local/etc/my.cnf
[mysqld]
#innodb_force_recovery=6
default-time-zone = "+03:00"
performance_schema=OFF
datadir = /var/db/mysql
basedir = /usr/local
port = 3306
socket = /tmp/mysql.sock
skip-external-locking
skip-name-resolve
thread_cache_size = 24
thread_pool_size = 2
query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 4M
max_connections = 80
key_buffer_size = 1M
max_allowed_packet = 128M
table_cache = 4096
innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances = 2
innodb_file_per_table = 1
innodb_log_file_size = 256M
innodb_data_home_dir=/var/db/mysql/ibdata
innodb_log_group_home_dir = /var/db/mysql/iblogs
innodb_flush_method = O_DIRECT
skip-innodb_doublewrite
#ZFS
sync_binlog = 0
innodb_flush_log_at_trx_commit = 0
innodb_doublewrite=0
innodb_log_checksums=OFF
innodb_checksum_algorithm=none
innodb_use_native_aio = 0
innodb_log_write_ahead_size=16384
aria_pagecache_buffer_size = 48M
sort_buffer_size = 4M
join_buffer_size = 2M
tmp_table_size = 256M
max_heap_table_size = 256M
net_buffer_length = 16K
read_buffer_size = 512K
read_rnd_buffer_size = 1M
auto_increment_offset = 1
auto_increment_increment = 1
server-id = 1
character-set-server = utf8
wait_timeout = 28800
skip-character-set-client-handshake
character_set_server=utf8
collation_server = utf8_unicode_ci
init_connect='SET NAMES utf8 collate utf8_unicode_ci
init_connect='SET NAMES utf8'
long_query_time = 10
back_log = 120
slow_query_log=1
slow_query_log_file=/var/log/mysql/slow.log
log_error = /var/log/mysql/error.log
general_log=0
general_log_file = /var/log/mysql/query.log
sql_mode =
[client]
port = 3306
socket = /tmp/mysql.sock
default-character-set=utf8
[mysqldump]
quick
default-character-set = utf8
max_allowed_packet = 1G
[mysql]
no-auto-rehash
default-character-set = utf8
[myisamchk]
key_buffer_size = 30M
sort_buffer_size = 20M
read_buffer_size = 2M
write_buffer_size = 2M
[mysqlhotcopy]
interactive-timeout
[safe_mysqld]
err-log=/var/log/mysql/mysqld.log
С наилучшими пожеланиями, Sergey Anohin.
From: |
Andrey Melnikoff <1187515102@banana.localnet> |
22 Jul 2021 14:48 +0300 |
To: |
Sergey Anohin 2:5034/10.1 |
|
Subject: |
InnoDB+UFS+SSD
|
From: "Andrey Melnikoff"
Sergey Anohin wrote:
> Hello *Alex* *Korchmar*
> SA>> А скажите как в 21 веке тюнят сабж?
> AK> в XXI веке ufs и шитдб давно уже немодны. Ими пpосто не пользуются (кому
> AK> нужен pезультат, а не пpоцесс)
> Для фидо пойдет.
туда и sqlite3 пойдет.
> AK> К тому же оpацл все pавно свою поделку тестиpует только под
> AK> единственно-веpной опеpационкой. Вот там ее и пользуй.
> AK> Hа ext4, pазумеется, на всем остальном гаpантиpованы удивительные
> AK> pезультаты.
> AK> А у тебя все какие-то пpоблемы из XX века, еще пpо myisam какой-то
помнят.
> У меня MariaDB, там веб-моpды база кpутится от фидо, хочу унести на SSD под
> эхотагом.
Я бы понял, если бы ты какой говнозаббикс крутил - там дааа, тюнить надо,
даже под SSD. А для фидо - всё в aria сконвертить и потянет, без тормоза
innodb.
From: |
Anton Gorlov 2:5059/37@FidoNet |
21 Jun 2021 08:57 +0300 |
To: |
Eugene Grosbein grosbein.net |
|
Subject: |
FRR
|
Привет Eugene!
21 июн 21 года (а было тогда 11:37)
Eugene Grosbein в своем письме к Anton Gorlov писал:
AG>> Аха. Поковырю тога на стенде и если всё ок потащу взамен квагги.
AG>> Там даже bfd есть.
EG> Сразу предупреждаю: у frr в настоящее время идёт процесс перехода
EG> от отдельных конфигов каждого демона - и этот режим глючный,
EG> например, демон зебра может "не видеть" ACL или route-map,
EG> определённый в bgpd.conf - к единому конфигу frr.conf,
EG> но дефолтный режим ещё старый. Чтобы использовать лучше работающий
EG> общий конфиг, надо в rc.conf прописать frr_vtysh_boot="YES",
EG> то есть:
Окак. Спасибо за предупреждение.
EG> frr_enable="YES"
EG> frr_vtysh_boot="YES"
EG> frr_daemons="zebra ospfd bgpd"
EG> zebra_flags="-P0"
EG> ospfd_flags="-P0"
EG> bgpd_flags="-P0 -l X.X.X.X -n"
EG> (флаги -l/-n необязательны)
EG> И затем ещё в /usr/local/etc/frr/vtysh.conf прописать единственную
EG> команду service integrated-vtysh-config
EG> Всё остальное писать в /usr/local/etc/frr/frr.conf,
EG> его я как раз и приводил в пример.
С уважением. Anton aka Stalker
Linux Registered User #386476
[#*TEAM:*#] [#_Злой СисОп_#] [*Heavy Metal!*] [*_Усачи_*]
From: |
Anton Gorlov 2:5059/37@FidoNet |
21 Jun 2021 08:48 +0300 |
To: |
Alex Korchmar <1187515007@ddt.demos.su> |
|
Subject: |
FRR
|
Привет Alex!
20 июн 21 года (а было тогда 23:59)
Alex Korchmar в своем письме к Anton Gorlov писал:
AG>> Есть конечно через другие ноги.. но QUAGGA упорно пыталась пихать
AG>> вон в тот вон линк, который не алё. И такая проблема только с
AG>> теми линками, которые
AK> она не знает что он не але. Она видит маршрут на твой ebgp пир, и пока
AK> не протаймаутится bgpшная сессия - ничего не изменится.
Почти 3 часа и продолжала висетьИ не собиралась отваливаться.
AG>> мультихоп. Там где "прямые" стыки - если линк упал то трафик
AG>> спокойно
AK> если _твой_ линк физически упал - логично, что обрывается соединение.
Не... физически соседние линки не падаоли.. У меня линки приходят в одни порты
мангала (caico 6509e) и у ходят в BGP с других портов мангала. Так вот когда у
соседних ног падала физика в сторону мангала или дальше (но не к самому BGP) -
маршруты не мгновенно,но довольно шустро перестраивались. А тут овер 3 часа
висело и не собиралось обновляться. Причём тот шлюз, через который бегал EBGP
уже вылетел даже из ARP. Пришлось квагге рестарт дёрнуть.
AG>> В квагге онного нет судя по всему, поэтому и всплыл вопрос про
AG>> FRR. Hу и до сих
AK> а, пардон, квагга же ж...
AG>> пор с "прямыми" линками подобных проблем не было - если отсох,то
AG>> скачем на
AK> если с падением интерфейса - не будет, а если пакеты перестали ходить
AK> а порт в апе - будет ровно то же самое.
Не... пор у меня вообще не падал ниразу. ИБо приходит с моей коробки в сторону
BGP. И если у пира что-то упало или сам пир упал (как например недавн оему
оптику порвали) - тарфик перетекает в другие ноги без падия физики. Более того у
меня все линки тупо расскиданы по вланам (но приходят на мангал в физические
порты),а на BGP приземляются в LAGG попиленный на нужные VLAN.
AK> настраивай bfd, сейчас уже совсем странно без него работать.
Ну вот переползу на FRR буду..
С уважением. Anton aka Stalker
Linux Registered User #386476
[#*TEAM:*#] [#_Злой СисОп_#] [*Heavy Metal!*] [*_Усачи_*]
From: |
Eugene Grosbein grosbein.net |
21 Jun 2021 10:37 +0300 |
To: |
Anton Gorlov 2:5059/37@FidoNet |
|
Subject: |
FRR
|
20 июня 2021, воскресенье, в 22:39 NOVT, Anton Gorlov написал(а):
AG> Аха. Поковырю тога на стенде и если всё ок потащу взамен квагги. Там даже
bfd
AG> есть.
Сразу предупреждаю: у frr в настоящее время идёт процесс перехода
от отдельных конфигов каждого демона - и этот режим глючный,
например, демон зебра может "не видеть" ACL или route-map,
определённый в bgpd.conf - к единому конфигу frr.conf,
но дефолтный режим ещё старый. Чтобы использовать лучше работающий
общий конфиг, надо в rc.conf прописать frr_vtysh_boot="YES",
то есть:
frr_enable="YES"
frr_vtysh_boot="YES"
frr_daemons="zebra ospfd bgpd"
zebra_flags="-P0"
ospfd_flags="-P0"
bgpd_flags="-P0 -l X.X.X.X -n"
(флаги -l/-n необязательны)
И затем ещё в /usr/local/etc/frr/vtysh.conf прописать единственную команду
service integrated-vtysh-config
Всё остальное писать в /usr/local/etc/frr/frr.conf,
его я как раз и приводил в пример.
Eugene
From: |
Alex Korchmar <1187515007@ddt.demos.su> |
20 Jun 2021 23:59 +0300 |
To: |
Anton Gorlov 2:5059/37@FidoNet |
|
Subject: |
FRR
|
From: Alex Korchmar
Anton Gorlov wrote:
AG> Есть конечно через другие ноги.. но QUAGGA упорно пыталась пихать вон в тот
вон
AG> линк, который не алё. И такая проблема только с теми линками, которые
она не знает что он не але. Она видит маршрут на твой ebgp пир, и пока не
протаймаутится bgpшная сессия - ничего не изменится.
AG> мультихоп. Там где "прямые" стыки - если линк упал то трафик спокойно
если _твой_ линк физически упал - логично, что обрывается соединение.
AG> В квагге онного нет судя по всему, поэтому и всплыл вопрос про FRR. Hу и до
сих
а, пардон, квагга же ж...
AG> пор с "прямыми" линками подобных проблем не было - если отсох,то скачем на
если с падением интерфейса - не будет, а если пакеты перестали ходить а
порт в апе - будет ровно то же самое.
настраивай bfd, сейчас уже совсем странно без него работать.
> Alex
P.S. есть еще вот это китайское недоразумение, но я им не пользовался:
https://github.com/hzchenyuefang/quagga_bfd
From: |
Anton Gorlov 2:5059/37@FidoNet |
20 Jun 2021 22:39 +0300 |
To: |
Eugene Grosbein grosbein.net |
|
Subject: |
FRR
|
Привет Eugene!
20 июн 21 года (а было тогда 20:29)
Eugene Grosbein в своем письме к Anton Gorlov писал:
AG>> All - а кто-нибудь гонял под эхотагом FRR взамен почившей квагги
AG>> под более-менее серьзной нагрузкой (BGP)?
EG> Hу как бы тебе сказать... Hа реальном роутинге с full view у меня
EG> циски сейчас, но есть и FRR7, на который с циски сливается full view с
EG> тем, чтобы отдавать недоверенному пиру, который может и флапинг сессии
EG> устроить.
Аха, значит можно пощупать...ибо квагга увы но уже мумия. У них даже сайт уже
полуживой.
EG> router bgp NNN
....
Аха. Поковырю тога на стенде и если всё ок потащу взамен квагги. Там даже bfd
есть.
С уважением. Anton aka Stalker
Linux Registered User #386476
[#*TEAM:*#] [#_Злой СисОп_#] [*Heavy Metal!*] [*_Усачи_*]
From: |
Anton Gorlov 2:5059/37@FidoNet |
20 Jun 2021 22:34 +0300 |
To: |
Alex Korchmar <1187515003@ddt.demos.su> |
|
Subject: |
FRR
|
Привет Alex!
20 июн 21 года (а было тогда 11:49)
Alex Korchmar в своем письме к Anton Gorlov писал:
AG>> ebgp-multihop. И Вот если по пути упало что-то...то маршрут так и
AG>> остаётся висеть в сторону мёртвого линка, вместо того что бы
AG>> перейти на "живые" ноги.
AK> по пути упало, а путь-то единственный? Может у тебя просто есть еще
AK> какой-то маршрут на этот линк (например через чей-то еще 0/0) и он
AK> вполне себе доступен.
Есть конечно через другие ноги.. но QUAGGA упорно пыталась пихать вон в тот вон
линк, который не алё. И такая проблема только с теми линками, которые
мультихоп. Там где "прямые" стыки - если линк упал то трафик спокойно перетекает
в другие ноги.
AK> Hу и традиционный вопрос - на дворе XXI век, какого ты еще не прочитал
AK> две странички про bfd?
В квагге онного нет судя по всему, поэтому и всплыл вопрос про FRR. Ну и до сих
пор с "прямыми" линками подобных проблем не было - если отсох,то скачем на
других ногах спокойно. А тут же упорно пытались пихать трафик в мёртвую ногу.
С уважением. Anton aka Stalker
Linux Registered User #386476
[#*TEAM:*#] [#_Злой СисОп_#] [*Heavy Metal!*] [*_Усачи_*]
From: |
Eugene Grosbein grosbein.net |
20 Jun 2021 19:29 +0300 |
To: |
Anton Gorlov 2:5059/37@FidoNet |
|
Subject: |
FRR
|
19 июня 2021, суббота, в 23:15 NOVT, Anton Gorlov написал(а):
AG> All - а кто-нибудь гонял под эхотагом FRR взамен почившей квагги под
AG> более-менее серьзной нагрузкой (BGP)?
Hу как бы тебе сказать... Hа реальном роутинге с full view у меня циски
сейчас, но есть и FRR7, на который с циски сливается full view
с тем, чтобы отдавать недоверенному пиру, который может и флапинг сессии
устроить.
router bgp NNN
bgp router-id X.X.X.X
bgp log-neighbor-changes
bgp graceful-restart restart-time 120
bgp graceful-restart stalepath-time 360
bgp graceful-restart
no bgp default ipv4-unicast
neighbor X.X.X.Y remote-as NNN
neighbor X.X.X.Y description "iBGP link"
neighbor X.X.X.Y update-source X.X.X.X
neighbor Z.Z.Z.Z remote-as YYY
neighbor Z.Z.Z.Z passive
neighbor Z.Z.Z.Z ebgp-multihop 10
neighbor Z.Z.Z.Z update-source X.X.X.X
!
address-family ipv4 unicast
neighbor X.X.X.X activate
neighbor Z.Z.Z.Z activate
neighbor Z.Z.Z.Z prefix-list deny-all in
neighbor Z.Z.Z.Z route-map to-yyy out
exit-address-family
!
bgp as-path access-list 400 deny ^.+_.+_.+_.+_.+
bgp as-path access-list 400 deny ^.+_65535$
bgp as-path access-list 400 permit ^.*
!
route-map to-yyy permit 10
match as-path 400
!
Eugene