iBGP

[rafand76]

Witam,

Połaczylem 2 ruterki po iBGP (fizycznie spiete):

Kod: Zaznacz cały

R1
neighbor 192.168.10.2 remote-as mojAS
neighbor 192.168.10.2 next-hop-self
R2
neighbor 192.168.10.1 remote-as mojAS
neighbor 192.168.10.1 next-hop-self

Sesje sie zestawiaja, ale na R2 mimo działającego łacza w swiat ruch chce "pchac" do R1 przez iBGP, a dodatkowo ruch nie przechodzi. Dlaczego tak sie dzieje?

[horac]

Kod: Zaznacz cały

 show bgp ipv4 unicast x.x.x.x 

i zobacz gdzie masz slowko "best", wtedy zobaczysz dlaczego pakiet pchany jest ta trasa a nie inna, pewnie wiesz o tym ze BGP uzywa NWLLAOMNI -< w skrocie atrybuty, zanim wybierze siec ktora ma trafic do tablicy routingu.

A co do wyjscia w swiat to jak ono jest realizowane ? masz jakas default trase ? jezeli tak powinienes ja co najmniej zredystrybuowac do BGP

Daj jakis diagram, nie bedziemy zgadywali

[rafand76]

Kod: Zaznacz cały

OP1<--->R1
....... |
....... | iBGP
....... |
OP2<--->R2

Zalezy mi na load sharingu. W tej chwili nie mam zadnych polityk dot. ruchu. BGP samo decyduje gdzie leciec. Na R2 po dodaniu sąsiada R1 przestaje dzialac internet i ruch chce isc poprzez iBGP na R1 ale nie idzie. Traceroute zatrzymuje sie na int od iBGP.

[garfield]

daj sh run

[horac]

a ty chcesz miec tranzyt tablic providera ? czy wyfiltrowac co cie interesuje i dodac jakas manipulacje local-preference per Provider, zeby zrobic ten loadsharing ? i

[rafand76]

R2

Kod: Zaznacz cały

interface GigabitEthernet0/1
 descritpion iBGP
 ip address 192.168.10.2 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
interface FastEthernet0/0/0
 description Sesja BGP OP2
 ip address x.x.x.x 255.255.255.252
 ip access-group 110 in
 ip access-group 120 out
 duplex auto
 speed auto
!
interface FastEthernet0/0/1
 desciption moja adresacja RIPE
 ip address x.x.x.x 255.255.255.0
 duplex auto
 speed auto
!
router bgp mojAS
 no synchronization
 bgp log-neighbor-changes
 network x.x.x.x
 network x.x.x.x mask 255.255.255.0
 neighbor x.x.x.x remote-as OP2
 neighbor x.x.x.x soft-reconfiguration inbound
 neighbor x.x.x.x prefix-list OP2 out
 neighbor 192.168.10.1 remote mojAS
 neighbor 192.168.10.1 next-hop-self
 no auto-summary
!
ip forward-protocol nd
ip route x.x.x.x 255.255.255.0 Null0
no ip http server
no ip http secure-server

ip prefix-list OP2 seq 5 permit x.x.x.x/24

chce zeby zaleznie do sciezki wybieral odpowiedniego operatora. Np. jezeli sciezka prowadzaca do celu jest krótsza przez OP1 to niech leci OP1 a jak jak przez OP2 to przez OP2. Po co ma leciec przez np. OP1 skoro blizej bedzie przez OP2.
Jak mialem dwa lacza na jednym routerze to dzialalo to z marszu (bez stosowania polityk).

[horac]

Najlepiej bedzie chyba zmaczowac przychodzace prefixy z roznymi community i w zaleznosci od nich poustawiac local preference route-mapami.

[drim09]

Daj sh ip bgp x.x.x.x, sh ip route x.x.x.x na R2 dla trasy która nie działa. Traceroute bezpośrednio z R2 do tej trasy idzie czy nie ? Rozgłaszasz swoje adresy do obu operatrorów ? A najlepiej to sh run

[bugi]

R2

chce zeby zaleznie do sciezki wybieral odpowiedniego operatora. Np. jezeli sciezka prowadzaca do celu jest krótsza przez OP1 to niech leci OP1 a jak jak przez OP2 to przez OP2. Po co ma leciec przez np. OP1 skoro blizej bedzie przez OP2.
Jak mialem dwa lacza na jednym routerze to dzialalo to z marszu (bez stosowania polityk).

Taka konfiguracja działa by default .
Chcesz ingerować w ruch wychodzacy -> local pref, wchodzący -> as_prepending , med ew. community.

pzdr

[tomiabc]

edited: tutaj były głupoty

poczytaj też o hsrp

[bugi]

to nie jest takie proste. Zakładając, że prefiks jest dostępny od obydwu operatorów, to przy takiej konfiguracji i reszcie domyślnej, ruch po ibgp nie będzie występował, ze względu na dystans administracyjny. Dla ibgp jest on większy niż ebgp. Jeżeli przyjdzie pakiet do rutera A i rutera A będzie miał trasę do sieci docelowej przez operatora A (o dużo gorszej metryce, niż ta od operatora B), to i tak wyśle to do operatora A. Z ibgp ruter A skorzysta w przypadku awarii łącza do operatora A lub gdy bardziej szczegółowy prefiks będzie dostępny od operatora B.

poczytaj też o hsrp

Przecież trasy od operatorów są po EBGP i mają dystans AD 20 a po drugie preferencja iBGP vs EBGP jest daleko z tylu, większy priorytet ma np as path. Może się mylę nie jestem pro z bgp albo miałeś coś innego na myśli :]

[tomiabc]

heeh, tak to jest jak sie piszę posta dłużej niż 2 minuty i kilka razy poprawia ;p oczywiście masz rację, najpierw patrzy na długość AS_PATH.

[inkrementator]

Proces selekcji tras przez BGP to raczej nie ma nic wspólnego z AD. Owszem w pewnym momencie trasy od eBGP są preferowane niż te nauczone od iBGP, ale to jest coś to według mnie nie ma nic wspólnego z AD. Nawet jak się zamieni AD iBGP (da sie 20) a dla eBGP da się 200, to i tak proces selekcji nadal będzie preferował trasy nauczone od eBGP, mimo, że eBGP mają większy AD. Jednak byłoby fajnie, gdyby mógł to ktoś potwierdzić.

AD ma znaczenie dopiero, gdy BGP próbuje umieścić swoją trasę (tą zaznaczoną jako best) w lokalnej tablicy routingu, ale się okazuję, że jest tam już inna trasa z mniejszym AD. Przy takiej trasie show ip bgp pokaże "r", a można je zobaczyć przez "show ip bgp rib-failure"

[rafand76]

Taka konfiguracja działa by default .
Chcesz ingerować w ruch wychodzacy -> local pref, wchodzący -> as_prepending , med ew. community.

pzdr

jasne ze dziala default, a polityki stosuje sie wlasnie po to, żeby nie bylo default.
Nie wyjaśniłeś jednak dlaczego tak sie dzieje w moim przypadku, ze ruch z R2 jest pchany do R1 przez iBGP.

poczytaj też o hsrp

HSRP mam, ale to słuzy zupelnie do czegos innego.

[drim09]

jasne ze dziala default, a polityki stosuje sie wlasnie po to, żeby nie bylo default.
Nie wyjaśniłeś jednak dlaczego tak sie dzieje w moim przypadku, ze ruch z R2 jest pchany do R1 przez iBGP.

Może dlatego, że przez R1 ma lepszą trasę, jeśli jest default to AS_PATH tutaj powinno decydować. Ale póki nie pokażesz wpisu z sh ip bgp x.x.x.x i sh ip route x.x.x.x na r2 i analogicznie dla tej samej trasy na r1 to raczej ciężko coś wróżyć. x.x.x.x mam na myśli ścieżkę która jest trasowana na R1 i która jest nieosiągalna. Podczas wykonywania tracerouta lub pinga zwróć również uwagę co jest Twoim sourcem bo może to mieć spore znaczenie.