uwaga SoO! #1

Czy atrybut EIGRP Site of Origin (SoO) chroni przed pętlami? Okazuje się, że nie!

Usiadłem do reewaluacji mechanizmów unikania pętli w sieci MPLS VPN w tym EIGRP SoO. Rozpisałem sobie kilka scenariuszy i okazało się, że znalazłem potencjalne scenariusze, w których można zapętlić ruch pomimo, że atrybut SoO jest skonfigurowany na urządzeniach PE. Jednym z nich jest scenariusz lokalizacji multihomed z tym samym SoO na routerach PE w stronę CE.

post5-1

Prefiks 100.6.6.6/32 jest rozgłaszany z SoO 3:3 z innej lokalizacji. Choć rysunek pokazuje update poprzez sieć MPLS VPN na PE1, to update jest również poprzez PE2. Niestabilność w sieci wyzwalana jest flapnięciem linku CE1-CE2, a następnie zrestartowania sesji BGP “clear ip bgp *” np. na PE2. Powoduje to ściganie się rozgłoszeń prefiksów (ang. race condition). W efekcie zmian może dojść do pętli, jak ta poniżej:

CE1#trace 100.6.6.6
Type escape sequence to abort.
Tracing the route to 100.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
 1 10.2.14.4 28 msec 24 msec 16 msec
 2 10.2.23.3 [MPLS: Label 30 Exp 0] 40 msec 44 msec 52 msec
 3 10.2.23.2 40 msec 84 msec 72 msec
 4 10.2.12.1 40 msec 40 msec 40 msec
 5 10.2.14.4 60 msec 60 msec 72 msec
 6 10.2.23.3 [MPLS: Label 30 Exp 0] 88 msec 96 msec 84 msec
 7 10.2.23.2 84 msec 128 msec 108 msec
 8 10.2.12.1 92 msec 96 msec 84 msec
 9 10.2.14.4 104 msec 112 msec 116 msec
 10 10.2.23.3 [MPLS: Label 30 Exp 0] 128 msec 128 msec 124 msec
 11 10.2.23.2 132 msec 168 msec 160 msec
 12 10.2.12.1 128 msec 128 msec 124 msec
 13 10.2.14.4 144 msec 152 msec 144 msec
 14 10.2.23.3 [MPLS: Label 30 Exp 0] 176 msec 176 msec 156 msec
 15 10.2.23.2 200 msec 176 msec 204 msec
 16 10.2.12.1 184 msec 168 msec 168 msec
 17 10.2.14.4 188 msec 204 msec 200 msec
 18 10.2.23.3 [MPLS: Label 30 Exp 0] 212 msec 208 msec 212 msec
 19 10.2.23.2 212 msec 252 msec 240 msec
 20 10.2.12.1 228 msec 212 msec 228 msec
 21 10.2.14.4 232 msec 232 msec 236 msec
 22 10.2.23.3 [MPLS: Label 30 Exp 0] 244 msec 252 msec 252 msec
 23 10.2.23.2 288 msec 296 msec 264 msec
 24 10.2.12.1 268 msec 252 msec 256 msec
 25 10.2.14.4 276 msec 300 msec 288 msec
 26 10.2.23.3 [MPLS: Label 30 Exp 0] 300 msec 292 msec 296 msec
 27 10.2.23.2 304 msec 352 msec 316 msec
 28 10.2.12.1 312 msec 300 msec 300 msec
 29 10.2.14.4 312 msec 316 msec 328 msec
 30 10.2.23.3 [MPLS: Label 30 Exp 0] 356 msec 336 msec 332 msec

Co ciekawe można uzyskać pętlę dokładnie w drugą stronę.

CE1#trace 100.6.6.6
Type escape sequence to abort.
Tracing the route to 100.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
 1 10.2.12.2 28 msec 24 msec 20 msec
 2 10.2.23.3 28 msec 64 msec 20 msec
 3 10.2.14.4 [MPLS: Label 284 Exp 0] 40 msec 36 msec 40 msec
 4 10.2.14.1 48 msec 68 msec 24 msec
 5 10.2.12.2 80 msec 64 msec 60 msec
 6 10.2.23.3 64 msec 80 msec 84 msec
 7 10.2.14.4 [MPLS: Label 284 Exp 0] 80 msec 80 msec 84 msec
 8 10.2.14.1 88 msec 84 msec 80 msec
 9 10.2.12.2 120 msec 108 msec 108 msec
 10 10.2.23.3 100 msec 128 msec 124 msec
 11 10.2.14.4 [MPLS: Label 284 Exp 0] 124 msec 128 msec 140 msec
 12 10.2.14.1 116 msec 120 msec 128 msec
 13 10.2.12.2 164 msec 144 msec 148 msec
 14 10.2.23.3 148 msec 168 msec 172 msec
 15 10.2.14.4 [MPLS: Label 284 Exp 0] 164 msec 172 msec 172 msec
 16 10.2.14.1 172 msec 168 msec 168 msec
 17 10.2.12.2 212 msec 192 msec 196 msec
 18 10.2.23.3 192 msec 220 msec 200 msec
 19 10.2.14.4 [MPLS: Label 284 Exp 0] 212 msec 212 msec 220 msec
 20 10.2.14.1 216 msec 216 msec 212 msec
 21 10.2.12.2 252 msec 240 msec 232 msec
 22 10.2.23.3 236 msec 256 msec 252 msec
 23 10.2.14.4 [MPLS: Label 284 Exp 0] 260 msec 260 msec 256 msec
 24 10.2.14.1 260 msec 252 msec 260 msec
 25 10.2.12.2 296 msec 272 msec 276 msec
 26 10.2.23.3 280 msec 296 msec 300 msec
 27 10.2.14.4 [MPLS: Label 284 Exp 0] 300 msec 300 msec 292 msec
 28 10.2.14.1 304 msec 304 msec 300 msec
 29 10.2.12.2 336 msec 316 msec 324 msec
 30 10.2.23.3 320 msec 336 msec 340 msec

Tablice BGP/RIB po zakończeniu rozgłoszeń w tym przypadku są stabilne i wyglądają następująco:

PE1:

PE1#sh ip bgp vpnv4 all 100.6.6.6/32
BGP routing table entry for 1:1:100.6.6.6/32, version 10221
Paths: (2 available, best #1, table aa)
 Advertised to update-groups:
 4 
 Local
 10.2.14.1 from 0.0.0.0 (4.4.4.4)
 Origin incomplete, metric 25601024, localpref 100, weight 32768, valid, sourced, best
 Extended Community: SoO:1:100 RT:1:1
 mpls labels in/out 284/nolabel
 Local, (Received from a RR-client)
 6.6.6.6 (metric 2) from 6.6.6.6 (6.6.6.6)
 Origin incomplete, metric 0, localpref 100, valid, internal
 Extended Community: SoO:3:3 RT:1:1
 mpls labels in/out 284/19

PE1#sh ip route vrf aa 100.6.6.6
Routing Table: aa
Routing entry for 100.6.6.6/32
 Known via "eigrp 200", distance 170, metric 25601024, type external
 Redistributing via eigrp 200, bgp 100
 Advertised by bgp 100
 Last update from 10.2.14.1 on GigabitEthernet1/0, 02:41:25 ago
 Routing Descriptor Blocks:
 * 10.2.14.1, from 10.2.14.1, 02:41:25 ago, via GigabitEthernet1/0
 Route metric is 25601024, traffic share count is 1
 Total delay is 40 microseconds, minimum bandwidth is 100 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 3

PE2:

PE2#sh ip bgp vpnv4 all 100.6.6.6/32
BGP routing table entry for 1:1:100.6.6.6/32, version 396
Paths: (1 available, best #1, table aa)
 Not advertised to any peer
 Local
 4.4.4.4 (metric 2) from 4.4.4.4 (4.4.4.4)
 Origin incomplete, metric 25601024, localpref 100, valid, internal, best
 Extended Community: SoO:1:100 RT:1:1
 mpls labels in/out nolabel/284

PE2#sh ip route vrf aa 100.6.6.6
Routing Table: aa
Routing entry for 100.6.6.6/32
 Known via "bgp 100", distance 200, metric 25601024, type internal
 Redistributing via eigrp 200
 Advertised by eigrp 200 metric 100 1 255 1 1500
 Last update from 4.4.4.4 02:45:11 ago
 Routing Descriptor Blocks:
 * 4.4.4.4 (default), from 4.4.4.4, 02:45:11 ago
 Route metric is 25601024, traffic share count is 1
 AS Hops 0
 MPLS label: 284
 MPLS Flags: MPLS Required

CE1:

CE1#sh ip route 100.6.6.6
Routing entry for 100.6.6.6/32
 Known via "eigrp 200", distance 170, metric 25600768, type external
 Redistributing via eigrp 200
 Last update from 10.2.12.2 on GigabitEthernet1/0, 02:47:04 ago
 Routing Descriptor Blocks:
 * 10.2.12.2, from 10.2.12.2, 02:47:04 ago, via GigabitEthernet1/0
 Route metric is 25600768, traffic share count is 1
 Total delay is 30 microseconds, minimum bandwidth is 100 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2

CE2:

CE2#sh ip route 100.6.6.6
Routing entry for 100.6.6.6/32
 Known via "eigrp 200", distance 170, metric 25600512, type external
 Redistributing via eigrp 200
 Last update from 10.2.23.3 on GigabitEthernet1/0, 02:46:26 ago
 Routing Descriptor Blocks:
 * 10.2.23.3, from 10.2.23.3, 02:46:26 ago, via GigabitEthernet1/0
 Route metric is 25600512, traffic share count is 1
 Total delay is 20 microseconds, minimum bandwidth is 100 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 1

Jest też scenariusz, w którym sieć zachowuje się niestabilnie z ilością rozgłoszeń BGP ~500/min.

Pętla nie pojawi się zawsze i w każdym przypadku. To, co burzy mechanizm EIGRP SoO, to otrzymany prefiks z innym SoO oraz wyścigi rozgłoszeń prefiksów. Racing można ograniczyć poprzez politykę routingu, która preferuje szkielet MPLS VPN nad backdoor link. Rekomendowałbym tym samym, aby do rozwiązania sprawy nie używać wyłącznie atrybutu SoO lub nie używać tego mechanizmu w ogóle. Zamiast tego bezpieczniej posłużyć się klasycznym filtrowaniem prefiksów w oparciu o ACL lub prefix-listy.

Potencjalny problem z pętlą dotyczy wszystkich systemów IOS, IOS XR, IOS XE, NX-OS, gdyż wszystkie używają tych samych reguł znakowania na PE w kierunku wejściowym oraz filtrowania na PE i CE.

Dzisiaj mam spotkanie z developerami od EIGRP. Przedstawię im znaleziska. Są jeszcze inne scenariusze pętlowe. Zobaczymy, co uda się ustalić. Można by rozszerzyć funkcjonalność EIGRP SoO. Mogłoby to być na przykład nadpisywanie SoO w kierunku outbound na PE, a nie tylko inbound tak, jak jest to obecnie zaimplementowane. Przekażę informacje w następnym odcinku, czy faktycznie czegoś brakuje, czy czegoś nie przeoczyłem oraz jaki jest punkt widzenia developerów.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

4 thoughts on “uwaga SoO! #1

    • Cześć,

      Rysunki są wykonane w MS PowerPoint. :)
      Tylko ikonki sobie odpowiednie dobraliśmy.

  • Hej Piotrek,
    jesli skonfiguruje sie SoO uzyty na dwoch PE dodatkowo na linku backdoor pomiedzy CE1 i CE2, to wszystkie routery powinny znac wspolny Site-ID, i tym samym nie powodowac petli, bo update EIGRP zawierajacy SoO sprawdzany jest z wartoscia zdefiniowana na interfejsie backdoor i w przypadku tej samem wartosci taki prefix bedzie odrzucony. Z opisu twojej konfiguracji nie wynika jednoznacznie, czy dodales sitemap definiujacy SoO na interfejsach CE1 – CE2. Pozdruffka! ;)

    • Cześć,

      W tym przykładzie SoO nie ma na CE. Jednak SoO na CE nie uchroni przed pętlą w tym przypadku, gdyż prefiks przychodzi z sieci MPLS VPN. Aby nie było pętli, to PE musiałby odfiltrować rozgłoszenie. Tutaj jest jeszcze jeden szkopuł – SoO jest już ustawione. Obecnie EIGRP ustawia SoO jedynie wówczas, gdy pole jest puste. Zatem, ani CE, ani PE nie może odfiltrować takiego prefiksu z innym SoO.

      Odnośnie SoO na CE, to też zrobiłem pętlę. Czekam na info od deweloperów, czy to bug, czy jakaś inna przypadłość.

Komentarze są niedostępne