Feb 16, 2024

1610

Ruckus ICX eBGP

Hallo,

bisschen eine Premiere bei mir tatsächlich, wir verwenden zum ersten Mal BGP das zwischen zwei L3-Switches hergestellt wird. Vorher hatten wir diesen Luxus nicht. Da wurden Krücken entweder aus L3-Switch und FRR oder alles statisch gemacht.

Jetzt habe ich hier die Konstellation das ich über einen Layer2-Link eines Providers die Möglichkeit habe jeweils zwei Ruckus ICX Switches miteinander zu verbinden. Auf der einen Seite ein ICX7850 und auf der anderen Seite ICX7550. Beide mit L3-Premium. In Betrieb genommen habe ich bereits iBGP und das funktionierte bis auf paar kleinere Anpassungen ganz hervorragend.

Vorab hatte ich in einem Testsystem diesen Fall nachgestellt mit einen ICX7450 und einem Linux-Router mit FRR. Die Standard-Config waren vielleicht drei Zeilen und danach funktionierte es. Aber jetzt zwischen dem 7850 und 7550 funktioniert das irgendwie nicht oder ich übersehe etwas.

Auf beiden Seiten sind dedizierte ganz plumpe physische Schnittstellen im Einsatz.

sh ip route

7850

14      10.1.129.3/32      10.1.255.1      e 1/1/33      1/1           S    15h21m
16      10.1.255.0/24      DIRECT          e 1/1/33      0/0           D    15h21m

7550

14      10.1.255.0/24      DIRECT          e 1/1/17      0/0           D    15h57m
17      10.255.129.3/32    10.1.255.254    e 1/1/17      1/1           S    15h53m

BGP-Configuration

7850

!
!
router bgp
 local-as 65255
 neighbor 10.1.129.3 remote-as 65101
 neighbor 10.1.129.3 update-source 10.255.129.3

 address-family ipv4 unicast
 multipath ibgp
 network 10.255.129.3/32
 redistribute connected
 redistribute static
 exit-address-family

 address-family ipv6 unicast
 exit-address-family
!
!

7550

!
!
router bgp
 local-as 65101
 neighbor 10.1.129.1 remote-as 65101
 neighbor 10.1.129.1 next-hop-self
 neighbor 10.1.129.1 update-source 10.1.129.3

 address-family ipv4 unicast
 maximum-paths 2
 network 10.1.129.3/32
 exit-address-family

 address-family ipv6 unicast
 exit-address-family
!
!

Ausgabe von "sh ip bgp neighbors 10.1.129.3" auf dem ICX7850...

State: CONNECT, Time: 15h33m27s, KeepAliveTime: 60, HoldTime: 180
    Minimal Route Advertisement Interval: 0 seconds
       UpdateSource: Address 10.255.129.3
    Messages:    Open    Update  KeepAlive Notification Refresh-Req
       Sent    : 0       0       0         0            0
       Received: 0       0       0         0            0
    Last Connection Reset Reason:Unknown
    Notification Sent:     Unspecified
    Notification Received: Unspecified
    Neighbor NLRI Negotiation:
      Peer configured for IPV4 unicast  Routes
    Neighbor AS4 Capability Negotiation:
    Outbound Policy Group:
       ID: 2, Use Count: 3
       Last update time was 55994 sec ago
    BFD:  No Configuration
Error: TCP status not available

Er bleibt auf Connect. Die jeweiligen Interfaces kann ich vom jeweils anderen Router anpingen.

Dann frage ich mich wie das mit dem debugging mit BGP funktionieren soll? Aktiviert habe ich es mit "debug ip bgp", aber wo findet die Ausgabe statt?

Sieht jemand einen Fehler? Jemand eine Idee?

Grüße

Please also mark the comments that contributed to the solution of the article

Content-Key: 22107897883

Url: https://administrator.de/contentid/22107897883

Printed on: April 27, 2024 at 23:04 o'clock

13 Comments

Latest comment

Du hast das neighbor 10.1.129.1 activate vergessen! Ebenso auf der anderen Seite.

Was sagt ein sh ip bgp neig ?

aber wo findet die Ausgabe statt?

Immer auf der seriellen Konsole. Wenn du per Telnet/SSH drauf bist musst du die Terminal Messages umleiten.

Das ist komisch. Ich konnte es lösen, indem ich es andersherum gemacht habe. Also neighbor jeweils die Interface-Adressen genommen habe. Da ging es dann auch ohne activate. Da kommt bei mir unweigerlich die Frage auf, warum es bei einem nötig ist und beim anderen nicht.

Gibt es keine Möglichkeit das über SSH zu sehen? Oder es geht es vielleicht mit externen Syslog-Server?

Also neighbor jeweils die Interface-Adressen genommen habe

Du meinst hoffentlich die jeweils gegenüberliegenden, oder? Welche hast du denn sonst genommen?? 🤔
Normalerweise nimmt man Loopback Interfaces mit /32er Hostadressen. Die müssen aber routingtechnisch immer ohne BGP erreichbar sein. Klar, denn sonst könnten die Peers sich schon nicht erreichen.
Wenn du noch Provider L2 Equipment dazwischen hast solltest du zusätzlich UDLD oder BFD verwenden um auch einen Link Loss auf der Providerseit zu erkennen.

So sieht es jetzt aus. Im Endeffekt habe ich statt der Loopback-Adresse und dann eine statische Route, so wie ich es kenne, die Adresse direkt auf den Interfaces als neighbor verwendet. Damit funktionierte es. Aber das ist, wie ich finde, nicht ganz sauber. Normalerweise müsste der neighbor die Loopback Adresse sein. Damit hat es nicht funktioniert. Wenn es wirklich nur an dem activate gescheitert ist... kann ich es ja wieder umstellen.

In diesem Fall ICX7850 mit 10.1.255.254 und ICX7550 10.1.255.1...

router bgp
 local-as 65255
 neighbor 10.1.255.1 remote-as 65101
 
 address-family ipv4 unicast
 multipath ibgp
 network 10.255.129.3/32
 redistribute connected
 redistribute static
 exit-address-family
end

router bgp
 local-as 65101
 neighbor 10.1.255.254 remote-as 65255

 address-family ipv4 unicast
 maximum-paths 2
 multipath ibgp
 network 10.1.129.3/32
 network 10.2.0.0/16
 network 10.1.200.0/24
 exit-address-family
end

So hier hat es auch ohne activate auf Anhieb geklappt.

Die Loopback /32 Adressen gibt man aber niemals in der BGP v4 Network Deklaration an. Hast' ja auch eh "connected" drin. Die sind nur fürs Peering relevant und da reicht eine statische Route oder ein andere Routing Protokoll.
Die Loopback Variante ist aber die professionellere, da stabilere Lösung. da sind deine Kenntnisse korrekt.

Zitat von @aqui:

Die Loopback /32 Adressen gibt man aber niemals in der BGP v4 Network Deklaration an. Hast' ja auch eh "connected" drin. Die sind nur fürs Peering relevant und da reicht eine statische Route oder ein andere Routing Protokoll.
Die Loopback Variante ist aber die professionellere, da stabilere Lösung. da sind deine Kenntnisse korrekt.

Wenn ich die Art und Weise mit dem "activate" mache, dann meckert er:

Error: IPv6 unicast-routing must be enabled before bgp ipv6 peer can be activated

Will ja kein IPv6.

Also per Loopback funktioniert es nicht. Ich kann es auch nicht aktivieren. Selbst wenn ich es so hier angebe...

router bgp
 local-as 65255
 neighbor 10.1.129.3 remote-as 65101
 neighbor 10.1.129.3 update-source loopback 1
 
 address-family ipv4 unicast
 multipath ibgp
 redistribute connected
 redistribute static
 exit-address-family
end

...funktioniert es nicht. Wenn ich wieder die Adresse des physischen Interface als Neighbor angebe, geht es wieder ohne Probleme.

Lösung:

neighbor 10.1.129.3 ebgp-multihop 20

Damit geht es jetzt auch mit dem Loopback.

Ein sh ip rou zeigt die Erreichbarkeit der gegenseitigen Loopbacks? Wenn ja wäre das etwas ungewöhnlich. 🤔

Zitat von @aqui:

Ein sh ip rou zeigt die Erreichbarkeit der gegenseitigen Loopbacks? Wenn ja wäre das etwas ungewöhnlich. 🤔

Verstehe ich nicht was du meinst. Muss es ja, weil ich eine statische Route setzen muss.

Wenn ich wieder die Adresse des physischen Interface als Neighbor angebe, geht es wieder ohne Probleme.

Das ist normales und erwartbares Verhalten 😉. eBGP Peers haben bekanntlich standardkonform immer eine feste TTL von 1. iBGP Peers haben dies Limit nicht mit einem TTL=255. (Siehe auch hier und hier)
Da du aber jetzt die Loopback Adresse nutzt die 2 Hops weg ist scheitert erwartungsgemäß der Verbindungsaufbau bzw. bleibt im Idle State hängen (sh ip bgp summary). Der Debugger sagt dann auch "no route to peer".

Du musst dem eBGP Peer also sagen das er mehr als der TTL=1 Default Hop entfernt ist. Das machst du immer mit dem "ebgp-multihop" Kommando!

router bgp
 local-as 65255
 neighbor 10.1.129.3 remote-as 65101
 neighbor 10.1.129.3 ebgp-multihop 2
 neighbor 10.1.129.3 update-source loopback 1 

Und schon klappt es auch mit dem Loopback Interface! 😉

Beispiel:

==================== Router-1 ======================
!
interface Loopback0
 ip address 10.22.22.35 255.255.255.255
 
router bgp 65530
 bgp log-neighbor-changes
 neighbor 10.22.22.11 remote-as 64714
 neighbor 10.22.22.11 description Router-2
 neighbor 10.22.22.11 ebgp-multihop 2
 neighbor 10.22.22.11 password 7 13061E010803
 neighbor 10.22.22.11 update-source Loopback0
 !
Router-1#sh ip bgp nei
BGP neighbor is 10.22.22.11,  remote AS 64714, external link
 Description: Router-2
  BGP version 4, remote router ID 10.22.22.11
  BGP state = Established, up for 00:05:00
  Last read 00:00:59, last write 00:00:18, hold time is 180, keepalive interval is 60 seconds
 
 ==================== Router-2 ======================
 !
 interface Loopback0
 ip address 10.22.22.11 255.255.255.255
 !
 router bgp 64714
 bgp log-neighbor-changes
 neighbor 10.22.22.35 remote-as 65530
 neighbor 10.22.22.35 description Router-1
 neighbor 10.22.22.35 ebgp-multihop 2
 neighbor 10.22.22.35 password 7 13061E010803
 neighbor 10.22.22.35 update-source Loopback0
 !
Router-2#sh ip bgp nei
BGP neighbor is 10.22.22.35,  remote AS 65530, external link
 Description: Router-1
  BGP version 4, remote router ID 10.22.22.35
  BGP state = Established, up for 00:03:57
  Last read 00:00:15, hold time is 180, keepalive interval is 60 seconds 

Works as designed! 👍 😉

Ja, im Endeffekt gibt es paar Implementierungs-Unterschiede. Komischerweise brauche ich das bei FRR nicht, wenn ich es zwischen zwei Debian-Kisten mache. Richtiger-/Logischerweise muss das ebgp-multihop mit rein. War mir so halt nicht bewusst. Jetzt läuft es.

Mmmhhh, das würde aber bedeutetn das sich FRR NICHT ganz standardkonform verhält was eigentlich verwunderlich ist, denn FRR wird sehr häufig als Route Reflector verwendet. Müsste man glatt mal mitsniffern. Sucht man im Internet mal danach gibt es aber einige Threads die mit FRR in den gleichen Fehler gelaufen sind.

Jetzt läuft es.

Das ist die Hauptsache! 👍

German solved Question Routers, Routing Switches, Hubs

Hotly discussed

End of availability for classic Teams clientDani