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