Народ чет не могу понять: 1. Маршрут приходит через OSPF 2. тот же маршрут приходит по eBGP (iBGP нет) *AD дефолтные 3. из OSPF в BGP этот маршрут редистрибутится в итоге в BGP таблице такое: sw1# show ip bgp 123.45.67.0/24 longer-prefixes Network Next Hop Metric LocPrf Weight Path *>r123.45.67.0/24 0.0.0.0 1 100 32768 ? * e 10.20.30.205 0 60894 64901 64762 i sw1# show ip bgp 123.45.67.0/24 BGP routing table entry for 123.45.67.0/24 Paths: (2 available, best #1) Flags: (0x080002) on xmit-list, is not in urib Advertised path-id 1 Path type: redist, path is valid, is best path AS-Path: NONE, path locally originated 0.0.0.0 (metric 0) from 0.0.0.0 (192.168.211.137) Origin incomplete, MED 1, localpref 100, weight 32768 Path type: external, path is valid, received and used, not best reason: Weight AS-Path: 60894 64901 64762 , path sourced external to AS 10.20.30.205 (metric 0) from 10.20.30.205 (5.7.8.158) Origin IGP, MED not set, localpref 100, weight 0 Path-id 1 not advertised to any peer И в таблицу маршрутизации он здесь инсталлится из OSPF а не eBGP

Все логично - если маршрут получен сначала от OSPF потом от BGP получается ваша ситуация: -выполняется редистрибьюция OSPF>BGP -маршрут устанавливается в BGP RIB с weight 32768 -приходит такой же маршрут от eBGP, weitht его дефолтный = 0. В RIB этот маршрут никак не попадет. т.е до AD дело не доходит вообще. >>>Исходное состояние: R8#sh bgp ipv4 u BGP table version is 4, local router ID is 150.1.8.8 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 1.1.1.1/32 155.1.108.10 0 0 200 i *> 155.1.58.5 2 32768 ? *> 155.1.8.0/24 0.0.0.0 0 32768 ? *> 155.1.58.0/24 0.0.0.0 0 32768 ? R8#sh bgp ipv4 u 1.1.1.1/32 BGP routing table entry for 1.1.1.1/32, version 4 Paths: (2 available, best #2, table default) Advertised to update-groups: 1 Refresh Epoch 1 200 155.1.108.10 from 155.1.108.10 (150.1.10.10) Origin IGP, metric 0, localpref 100, valid, external Refresh Epoch 1 Local 155.1.58.5 from 0.0.0.0 (150.1.8.8) Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best R8#cle ip ospf nei R8# >>>Изменяем порядок получения маршрута (сначала eBGP, потом OSPF) >Побеждает eBGP имеющий меньшую AD R8#cle ip ospf process Reset ALL OSPF processes? [no]: yes R8# R8#yes R8#yes *Sep 25 16:22:43.839 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 150.1.5.5 on GigabitEthernet0/0.58 from FULL to DOWN, Neighbor Down: Interface down or detached *Sep 25 16:22:43.987 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 150.1.5.5 on GigabitEthernet0/0.58 from LOADING to FULL, Loading Done R8#sh bgp ipv4 u 1.1.1.1/32 BGP routing table entry for 1.1.1.1/32, version 5 Paths: (1 available, best #1, table default) Not advertised to any peer Refresh Epoch 1 200 155.1.108.10 from 155.1.108.10 (150.1.10.10) Origin IGP, metric 0, localpref 100, valid, external, best R8# R8# R8# >> Еще раз меняем порядок получения R8#cle bgp ipv4 u * R8# *Sep 25 16:39:14.231 UTC: %BGP-5-ADJCHANGE: neighbor 155.1.108.10 Down User reset *Sep 25 16:39:14.231 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor 155.1.108.10 IPv4 Unicast topology base removed from session User reset *Sep 25 16:39:15.095 UTC: %BGP-5-ADJCHANGE: neighbor 155.1.108.10 Up R8# R8#sh bgp ipv4 u 1.1.1.1/32 BGP routing table entry for 1.1.1.1/32, version 2 Paths: (2 available, best #2, table default) Advertised to update-groups: 2 Refresh Epoch 1 200 155.1.108.10 from 155.1.108.10 (150.1.10.10) Origin IGP, metric 0, localpref 100, valid, external Refresh Epoch 1 Local 155.1.58.5 from 0.0.0.0 (150.1.8.8) Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best R8#

Все логично - если маршрут получен сначала от OSPF потом от BGP получается ваша ситуация: -выполняется редистрибьюция OSPF>BGP -маршрут устанавливается в BGP RIB с weight 32768 -приходит такой же маршрут от eBGP, weitht его дефолтный = 0. В RIB этот маршрут никак не попадет. т.е до AD дело не доходит вообще. >>>Исходное состояние: R8#sh bgp ipv4 u BGP table version is 4, local router ID is 150.1.8.8 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 1.1.1.1/32 155.1.108.10 0 0 200 i *> 155.1.58.5 2 32768 ? *> 155.1.8.0/24 0.0.0.0 0 32768 ? *> 155.1.58.0/24 0.0.0.0 0 32768 ? R8#sh bgp ipv4 u 1.1.1.1/32 BGP routing table entry for 1.1.1.1/32, version 4 Paths: (2 available, best #2, table default) Advertised to update-groups: 1 Refresh Epoch 1 200 155.1.108.10 from 155.1.108.10 (150.1.10.10) Origin IGP, metric 0, localpref 100, valid, external Refresh Epoch 1 Local 155.1.58.5 from 0.0.0.0 (150.1.8.8) Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best R8#cle ip ospf nei R8# >>>Изменяем порядок получения маршрута (сначала eBGP, потом OSPF) >Побеждает eBGP имеющий меньшую AD R8#cle ip ospf process Reset ALL OSPF processes? [no]: yes R8# R8#yes R8#yes *Sep 25 16:22:43.839 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 150.1.5.5 on GigabitEthernet0/0.58 from FULL to DOWN, Neighbor Down: Interface down or detached *Sep 25 16:22:43.987 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 150.1.5.5 on GigabitEthernet0/0.58 from LOADING to FULL, Loading Done R8#sh bgp ipv4 u 1.1.1.1/32 BGP routing table entry for 1.1.1.1/32, version 5 Paths: (1 available, best #1, table default) Not advertised to any peer Refresh Epoch 1 200 155.1.108.10 from 155.1.108.10 (150.1.10.10) Origin IGP, metric 0, localpref 100, valid, external, best R8# R8# R8# >> Еще раз меняем порядок получения R8#cle bgp ipv4 u * R8# *Sep 25 16:39:14.231 UTC: %BGP-5-ADJCHANGE: neighbor 155.1.108.10 Down User reset *Sep 25 16:39:14.231 UTC: %BGP_SESSION-5-ADJCHANGE: neighbor 155.1.108.10 IPv4 Unicast topology base removed from session User reset *Sep 25 16:39:15.095 UTC: %BGP-5-ADJCHANGE: neighbor 155.1.108.10 Up R8# R8#sh bgp ipv4 u 1.1.1.1/32 BGP routing table entry for 1.1.1.1/32, version 2 Paths: (2 available, best #2, table default) Advertised to update-groups: 2 Refresh Epoch 1 200 155.1.108.10 from 155.1.108.10 (150.1.10.10) Origin IGP, metric 0, localpref 100, valid, external Refresh Epoch 1 Local 155.1.58.5 from 0.0.0.0 (150.1.8.8) Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best R8#

:) Спасибо большое, на такой детальный ответ не расчитывал)))

Ребята, есть кто живой? Кто может натолкнуть, куда копать при проблеме на миротике?

Смотря что за проблема, лучше всегда с описания начать

Есть два микротика с внутренними сетками 172.16.10.0/24 и 172.16.11.0/24, на них есть интернет. На этом интернете натянут eoip-туннель, на интерфейсах eoip висят 10.0.0.1 and 10.0.0.2 соответственно.

Трафик tool traceroute 172.16.11.10 src-address=172.16.10.1

не ходит

есть соурс не указывать, то ходит, что не так сделал?

tool traceroute 172.16.11.10 # ADDRESS LOSS SENT LAST AVG BEST WORST 1 10.0.0.2 0% 21 2.3ms 2.4 2.2 3 2 172.16.11.10 0% 21 2.5ms 2.4 2.2 2.7

маршруты в тоннели есть?

fuf

ага

вывод скинь на всякий route table и там и там

ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 A S 0.0.0.0/0 46.228.7.89 1 1 ADC 10.0.0.0/30 10.0.0.1 eoip-tunnel-kuz... 0 3 ADC 172.16.10.0/24 172.16.10.1 ether2 0 4 A S 172.16.11.0/24 10.0.0.1 10.0.0.2 1

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

А вот с локального адреса внутренней сети, он уже трафик туда не направляет.

файрвольные правила накручены?

Все что там стояло в дроп, отключал

tool traceroute 172.16.11.10 src-address=10.0.0.1 # ADDRESS LOSS SENT LAST AVG BEST WORST 1 10.0.0.2 0% 3 2.7ms 3.3 2.4 4.8 2 172.16.11.10 0% 3 2.6ms 2.4 2.3 2.6

с интерфейса eoip туннеля пингует.

Такое ощущение, что то ли НАТ надо вешать, только какой и куда...

tool traceroute 172.16.10.1 src-address=10.0.0.2 # ADDRESS LOSS SENT LAST AVG BEST WORST 1 100% 1 timeout 2 100% 1 timeout 3 100% 1 timeout 4 0% 1 0ms

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

ну eoip тунель это в принципе l2 тоннель

я с ними не сталкивался, но почему бы не поднять gre просто

ведь связать надо не l2 сетку а две разных

l3 over l3

ну, у нас по факту в туннеле бегает l2, на концах тоннеля L3 повесил.

связность между точками есть

с интерйеса туннеля он все пингует.

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

может arpы не отрабатывают на тоннельных адресах

сделал немного подругому, создал VLAN забриджевал его с еоип и повесил л3 на него

результата нет(

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

Все дефолтное

в настройках

бридж создан 1, в нем vlan200 интерфейс и еоип

а выходной интерфейс из которого строится eoip не в этом же бридже?

не пойму, это приложение прислало? или фича NX-OS? ip подменил...

n5k1# telnet 1.2.3.4 5678 source 9.8.7.6 Trying 1.2.3.4... Connected to 1.2.3.4. Escape character is '^]'. ^] dcos-telnet> ? Commands may be abbreviated. Commands are: close close current connection logout forcibly logout remote user and close the connection display display operating parameters mode try to enter line or character mode ('mode ?' for more) open connect to a site quit exit telnet send transmit special characters ('send ?' for more) set set operating parameters ('set ?' for more) unset unset operating parameters ('unset ?' for more) status print status information toggle toggle operating parameters ('toggle ?' for more) slc set treatment of special characters z suspend telnet environ change environment variables ('environ ?' for more) dcos-telnet> quit Connection closed.

менюшку такую...

а выходной интерфейс из которого строится eoip не в этом же бридже?

нет, он сам по себе

нет, он сам по себе

А правила nat какие сейчас?

вот такое, экшен, маскарад

только висит

прописать бы в явном виде локальные подсетки в SNATе, по идее виртуальные адреса EOIP не должны натироваться

не уверен насчет packet processing flow в микротике

но я бы сделал ip source nat 172.16.10.0/24 interface eth1 overload

в явном виде

и на обратной стороне тоже

10.0.0.0/30 натировать нам по идее не надо

если я еще здраво мыслю в пол третьего)

прописать бы в явном виде локальные подсетки в SNATе, по идее виртуальные адреса EOIP не должны натироваться

Спасибо, я чутка поторопился и уронил микрот)

доступа теперь нет)

=))

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

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

Если вакансия на сетевика, скажи повысили с админа серверов до админа сетей?

#нукактакто

никогда такого не было, и вот опять

а, да, SAN нинужын

ты мне лучше скажи что упало-то

я сначала подумал сан-фабрика

В душе не представляю. Не, могу конеш спросить, но не думаю, что мне прям в деталях всё расскажут

но это смешно. один комутатор падает и всё, работа встала

я сначала подумал сан-фабрика

там vSAN вроде вмваревский

датацентр my ass

ггг

зато в кедах и с вейпами

Завтра у них как раз техдей будет, где они будут про надёжность облаков рассказывать

Надо обязательно посетить?

:D

вообще страшный день вчера был - вечером начался апокалипсис)) и ночью продолжился ? у нас фильтр для РКН затупил чёт, у партнёров коммутатор какой то корнеувой выгорел… ночью у других партнёров стойку обесточиили и кабель питания куда то перенесли на площадке … не маленькой так скажем ?

наверное магнитные бури...

всё это естественно сопровождается потерями сервисов от этих партнёров…

наверное магнитные бури...

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

но это смешно. один комутатор падает и всё, работа встала

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

а точно такую технологию надо выводить в продакшн и продавать услуги на её основе за деньги?

просто, ладно бы икнуло и дальше побежало, а тут 10 часов даунтайма

а точно такую технологию надо выводить в продакшн и продавать услуги на её основе за деньги?

Cisco vss?)

microsoft vss?

тут разговор не про контректную технологию

а в общем

Ребята тут возник вопрос должен ли подниматься линк на роловер кабеле?

Завтра у них как раз техдей будет, где они будут про надёжность облаков рассказывать

Там по прежнему Малеванов за сеть отвечает?

Да

Он там за всё отвечает

CTO

он вроде давно техдир самый главный

кто там за сеть я хз

За сеть там, тоже Кирилл) забыл, как по фамилии. Но это не точно

За сеть там, тоже Кирилл) забыл, как по фамилии. Но это не точно

Кирилл Малеванов

Это CTO

Это CTO

Нужно больше Кириллов

ага=)