modified on 21 lip 2010 at 09:24 ••• 8 211 views

Równoważenie Obciążenia BGP z dwoma interfejsami

Z MikroTik Wiki

Uwaga: Do działania potrzebny jest RouterOS w wersji 3.13 lub wyższej z zainstalowanym pakietem routing-test

W tym przykładzie pokażemy jak równoważyć obciążenie gdy dostępnych jest wiele łączy o równym koszcie pomiędzy dwoma routerami BGP. Sesja BGP jest zestawiona pomiędzy interfejsami loopback; Użyto ustawienia update-source do powiązania połączenia BGP do odpowiedniego interfejsu.


Spis treści

Przykład z iBGP

Diagram Sieci

Image:ibgp_load_bal.png

Konfiguracja

Na routerze A:

# interfejs loopback
/interface bridge add name=lobridge

# adresy
/ip address add address=1.1.1.1/24 interface=ether1
/ip address add address=2.2.2.1/24 interface=ether2
/ip address add address=9.9.9.1/32 interface=lobridge

# trasa ECMP do pętli zwrotnej peera
/ip route add dst-address=9.9.9.2/32 gateway=1.1.1.2,2.2.2.2

# BGP
/routing bgp instance set default as=65000
/routing bgp add name=peer1 remote-address=9.9.9.2 remote-as=65000 update-source=lobridge

Na routerze B:

# interfejs loopback
/interface bridge add name=lobridge

# adresy
/ip address add address=1.1.1.2/24 interface=ether1
/ip address add address=2.2.2.2/24 interface=ether2
/ip address add address=9.9.9.2/32 interface=lobridge

# trasa ECMP do pętli zwrotnej peera
/ip route add dst-address=9.9.9.1/32 gateway=1.1.1.1,2.2.2.1

# BGP
/routing bgp instance set default as=65000
/routing bgp add name=peer1 remote-address=9.9.9.1 remote-as=65000 update-source=lobridge

# rozgłaszana trasa
/routing bgp network add network=4.4.4.0/24

Wyniki

Sprawdź czy zestawiono połączenie BGP:

[admin@B] > /routing bgp peer print status
Flags: X - disabled
0   name="peer1" instance=default remote-address=9.9.9.1 remote-as=65000
    tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m
    ttl=255 in-filter="" out-filter="" address-families=ip
    update-source=lobridge default-originate=no remote-id=1.1.1.1
    local-address=9.9.9.2 uptime=28s prefix-count=0 updates-sent=1
    updates-received=0 withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m
    used-hold-time=3m used-keepalive-time=1m refresh-capability=yes
    as4-capability=yes state=established

Tablica routingu na routerze A:

[admin@A] > /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        G GATEWAY                 DISTANCE INTER...
0 ADC  1.1.1.0/24         1.1.1.1                                   0        ether1
1 ADC  2.2.2.0/24         2.2.2.1                                   0        ether2
2 ADb  4.4.4.0/24                         r 9.9.9.2                 200      ether1
                                                                             ether2
3 ADC  9.9.9.1/32         9.9.9.1                                   0        lobridge
4 A S  9.9.9.2/32                         r 1.1.1.2                 1        ether1
                                          r 2.2.2.2                          ether2
[admin@A] > /ip route print detail
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
0 ADC  dst-address=1.1.1.0/24 pref-src=1.1.1.1 interface=ether1 distance=0 scope=10

1 ADC  dst-address=2.2.2.0/24 pref-src=2.2.2.1 interface=ether2 distance=0 scope=10

2 ADb  dst-address=4.4.4.0/24 gateway=9.9.9.2 interface=ether1,ether2
       gateway-state=recursive distance=200 scope=40 target-scope=30
       bgp-local-pref=100 bgp-origin=igp received-from=9.9.9.2

3 ADC  dst-address=9.9.9.1/32 pref-src=9.9.9.1 interface=lobridge distance=0 scope=10

4 A S  dst-address=9.9.9.2/32 gateway=1.1.1.2,2.2.2.2 interface=ether1,ether2
       gateway-state=reachable,reachable distance=1 scope=30 target-scope=10

Trasa 4.4.4.0/24 została umieszczona w jądrze Linuksa z dwoma następnymi skokami: 1.1.1.2 (na ether1) i 2.2.2.2 (na ether2).

Przykład z eBGP

Diagram sieci

Image:ebgp_load_bal.png

Konfiguracja

Powyższy przykład został rozwinięty o przypadek z eBGP. Domyślnie, peery eBGP muszą być bezpośrednio osiągalne. Jeśli używamy interfejsów loopback, nie są bezpośrednio osiągalne, więc należy ustawić multihop=yes.

Na routerze A:

/routing bgp instance set default as=65000
/routing bgp set peer1 remote-address=9.9.9.2 remote-as=65001 update-source=lobridge multihop=yes

Na routerze B:

/routing bgp instance set default as=65001
/routing bgp set peer1 remote-address=9.9.9.1 remote-as=65000 update-source=lobridge multihop=yes

Wyniki

Jeśli wyświetlimy tablice routingu na routerze A, możemy zobaczyć, że widnieje trasa z routera B, ale nie jest aktywna:

...
2  Db  dst-address=4.4.4.0/24 gateway=9.9.9.2 interface="" gateway-state=unreachable
       distance=20 scope=40 target-scope=10 bgp-as-path="65001" bgp-origin=igp
       received-from=9.9.9.2
...

Dzieje się tak ponieważ trasy eBGP umieszczane są z mniejszym target-scope. Aby to poprawić, ustaw filtr routingu, który ustawia większy target-scope:

/routing filter add chain=bgp-in set-target-scope=30
/routing bgp set peer1 in-filter=bgp-in

Zamiast tego, możesz zmodyfikować atrybut scope trasy statycznej:

/ip route set [find dst-address=9.9.9.2/32] scope=10

W każdym razie, trasa do 4.4.4.0/24 powinna teraz być aktywna:

2 ADb  dst-address=4.4.4.0/24 gateway=9.9.9.2 interface=ether1,ether2
       gateway-state=recursive distance=20 scope=40 target-scope=10
       bgp-as-path="65001" bgp-origin=igp received-from=9.9.9.2

Uwagi

  • BGP nie wspiera tras ECMP. Gdy rekursywnie rozwiązywana trasa BGP jest propagowana przez sieć, może być wybrany tylko jeden następny skok (jak opisano tutaj) i umieszczony w wiadomości BGP UPDATE.