Вопрос по BGP

[vovan-pmr]

Созрел вопрос:

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

Собственно вопрос: можно ли и через этот роутер объявлять наши сети, чтоб в случае падения первого роутера сохранялись наши анонсы в мир??

 

router bgp ASn

address-family ipv4

network x.x.x.x

[Tosha]

Можно.

Только для сохранения работоспособности внутри тоже надо динамическую маршрутизацию делать. Чтобы выбор между двумя внешними роутерами делался автоматически. А еще лучше с распределением исходящего трафика по каналам если оба рабочие.

[JohnPev]

Созрел вопрос:

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

Собственно вопрос: можно ли и через этот роутер объявлять наши сети, чтоб в случае падения первого роутера сохранялись наши анонсы в мир??

 

router bgp ASn

address-family ipv4

network x.x.x.x

А в чем тут проблемма?

В зависимости от того что за тип аплинков (по полосе или помегабайтно) анонстите в разные стороны с разным As-path ем к примеру и всё. Главное понять куда хотите отправлять трафик и откуда принимать (и в каких количествах).

[Tsvetkov]

через IBGP - internal BGP связать оба BGP роутера

[marikoda]

А будет ли жить такая конструкция:

 

ОДИН аплинк по BGP, но по двум каналам.

Задача поднять две BGP сессии между роутером аплинка и своим.

 

UPD. И варианты, когда:

а) один аплинк, два канала, два роутера

б) два аплинка, два канала, два роутера

в) два аплинка, к одному 2 канала, к другому -1, два роутера.

 

Edited October 19, 2010 by marikoda

[UglyAdmin]

Будет. Но могут быть проблемы с балансировкой этих каналов.

[vovan-pmr]

через IBGP не пойдет. если отваливается роутер, который анонсит сети, то через второй анонсы наружу идти уже не будут.

а вот если можно с обоих объявлять сети, тогда другое дело!

 

а распределение трафика по аплинкам эт конечно, эт сделаем

[Tsvetkov]

через IBGP не пойдет. если отваливается роутер, который анонсит сети, то через второй анонсы наружу идти уже не будут.

а вот если можно с обоих объявлять сети, тогда другое дело!

 

а распределение трафика по аплинкам эт конечно, эт сделаем

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

 

[Stak]

если коротко - можно.

связываете их по ibgp и всё.

[Discetta_5_25]

Всем привет! Тема старая вопросы новые...

 

Итак. Проблема сходимости на двух CISCO Nexus 3к в связке OSPF+iBGP на двух параллельных линках.

Имеем:

два Cisco Nexus 3000 c nx-os 9.3

два линка между ними.

loopback в каждом Nexuse видит loopback соседа по OSPF.

BGP Nexusa 1:

 

router bgp 64999
  router-id 10.255.0.1
  address-family ipv4 unicast
    network 0.0.0.0/0
    network 172.111.111.0/24
  neighbor 10.255.1.1 remote-as 64999
    remote-as 64999
    update-source loopback0
    address-family ipv4 unicast

 

BGP Nexusa 2:
 

router bgp 64999
  router-id 10.255.1.1
  address-family ipv4 unicast
  neighbor 10.255.0.1 remote-as 64999
    remote-as 64999
    update-source loopback0
    address-family ipv4 unicast
 

Второй нексус получает по BGP маршруты:

 

# sh ip route bgp
0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.0.1, [200/0], 00:00:07, bgp-64999, internal, tag 64999
172.111.111.0/24, ubest/mbest: 1/0
    *via 10.255.0.1, [200/0], 00:33:01, bgp-64999, internal, tag 64999

 

А теперь вопрос!!!

при обрыве одного линка на втором нексусе теряется дефолтный маршрут.

ну не совсем теряется, просто становится на 60 секунд pending ufdm.

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

Почему? Куда копать?

 

задержка в 60 секунда на такой связке ... это как-то слишком долго!

 

[jffulcrum]

А в консоли, случаем, нет чего-то такого:

"SYSTEM_MSG: TCP: MD5 Hash failed for (IP)

[SpheriX]

С нексусами не работал, но тупой вопрос: а почему анонсируется network 0.0.0.0/0, а не используется  директива default originate на neighbor ?

[Discetta_5_25]

SpheriX-y:

Там есть три способа объявить дефолт. Во всех трех случаях результат один и тот же. Объявляется, но при перестроении таблицы и проверке нехтхопов маршрут на /24 остается, а маршрут на /0 зависает в астрале на минуту.

 

Начитались тут всякого... про баги сисек:

In rare cases, sh ip route is missing static route and /8 prefixes (stuck in pending ufdm)
CSCwk37039  

Description

The static route stuck in pending ufdm Symptom: The default route and /8 prefixes may be missing from 'show ip route'. These routes will be learned via static route where the next hop IP has been changed to an unresolvable address. Verify if the route is present with this state by checking "show ip route detail vrf [name|all]" `show ip route detail vrf all` IP Route Table for VRF "default" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%<string>' in via output denotes VRF <string> 0.0.0.0/32, ubest/mbest: 1/0 *via Null0, [220/0], 2w5d, broadcast, discard 127.0.0.0/8, ubest/mbest: 1/0 *via Null0, [220/0], 2w5d, broadcast, discard 255.255.255.255/32, ubest/mbest: 1/0 *via sup-eth1, [0/0], 2w5d, broadcast 0.0.0.0/0, ubest/mbest: 0/0, pending ufdm <<< static default route stuck in pending ufdm via 10.1.1.1, [1/0], 1w2d, static recursive next hop: 10.1.1.1/32 Conditions: Nexus 9000 switch before fixed code (10.3(6), 10.4(3), and 10.5(1)) Only the default route and /8 prefixes are affected. The next-hop shouldn't be reachable for any reason and the ARP entry for the next-hop should not be in the ARP table. A change in the IP address of the L3 interfaces, through which the next-hop is supposed to be reachable. Workaround: Remove and reconfigure the static route. Further Problem Description: Fixed in 10.3(6), 10.4(3), and 10.5(1)

 

похоже оно.

[Saab95]

В 24.01.2025 в 07:23, Discetta_5_25 сказал:

Там есть три способа объявить дефолт. Во всех трех случаях результат один и тот же.

Так подключите к своим БГП цискам какие-то устройства мелкие, хоть микротик RB750, и пусть они через OSPF анонсируют дефолт от своего имени, тогда при пропаже дефолта от имени циски он все равно останется в сети, и трафик будет идти сквозь циску на микротик. То есть по сети трафик пойдет куда надо.

 

На самих цисках правилами перенаправите весь трафик в сторону интернета. Как костыль очень хорошее решение.