Az előző bejegyzésben leírtam egy problémát, miszerint:
R2 nem látja BGP-ből R8-R14, illetve R9-R10 transit linkjét. R14 nem látja BGP-ből R2-R4, illetve R9-R10 transit linkjét.
A topológia pedig a következő volt:
Mi most ISP1-nél leszünk rendszermérnökök, azaz nem férünk hozzá az ügyfél eszközeihez. A fent leírt problémából egy ticket jött az a supportra, ami szerint már észrevették, hogy nem csak a transit linkek hiányoznak, hanem internal subnetek is:
From: it.team@kuglofasz.hu
To: support@isp1.com
Subject: BGP probléma
Attachment: configs.txt
Helló support,
Teszteljük az Önök által kialakított VPN-t. Sajnos észrevettük, hogy route-k hiányoznak BGP-ből a HQ és a távoli telephelyeink között. Az IGP-ből hirdetett route-kat sem látjuk minden routeren, ráadásul szükségünk lenne a köztünk és az Önök között használt transit linkek hirdetésére is.
Mi a megállapodásnak megfelelően csak IGP->BGP redisztribúciót csináltunk, illetve R10-en lokális subnet behirdetést, kérem minden másról Önök gondoskodjanak!
Csatolmányban találják routereink konfigurációját és BGP tábláit!
Köszönjük!
Üdvözlettel:
Kuglófasz IT Team
A csatolmány a következő információkat tartalmazza:
R2 sh run | s bgp router bgp 100 bgp router-id 2.2.2.2 bgp log-neighbor-changes redistribute eigrp 100 neighbor 192.168.0.1 remote-as 65000 R2# R2#sh ip bgp BGP table version is 15, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 10.1.1.1 1024640 32768 ? *> 2.2.2.2/32 0.0.0.0 0 32768 ? *> 3.3.3.3/32 10.1.1.3 1024640 32768 ? *> 10.1.1.0/24 0.0.0.0 0 32768 ? *> 10.10.10.10/32 192.168.0.1 0 65000 200 i *> 16.16.16.16/32 10.1.1.16 1024640 32768 ? *> 192.168.0.0/30 0.0.0.0 0 32768 ? *> 192.168.100.0 192.168.0.1 0 65000 200 i R2# --------------------------------------------- R10 R10#sh run | s bgp router bgp 200 bgp router-id 10.10.10.10 bgp log-neighbor-changes network 10.10.10.10 mask 255.255.255.255 network 18.18.18.18 mask 255.255.255.255 network 192.168.100.0 neighbor 192.168.0.21 remote-as 65000 R10#sh ip bgp BGP table version is 38, local router ID is 10.10.10.10 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 192.168.0.21 0 65000 100 ? *> 2.2.2.2/32 192.168.0.21 0 65000 100 ? *> 3.3.3.3/32 192.168.0.21 0 65000 100 ? *> 10.1.1.0/24 192.168.0.21 0 65000 100 ? *> 10.10.10.10/32 0.0.0.0 0 32768 i *> 14.14.14.14/32 192.168.0.21 0 65000 300 ? *> 15.15.15.15/32 192.168.0.21 0 65000 300 ? *> 16.16.16.16/32 192.168.0.21 0 65000 100 ? *> 22.22.22.22/32 192.168.0.21 0 65000 300 ? *> 192.168.0.0/30 192.168.0.21 0 65000 100 ? *> 192.168.100.0 0.0.0.0 0 32768 i *> 192.168.101.0 192.168.0.21 0 65000 300 ? R10# --------------------------------------------- R14#sh run | s bgp redistribute bgp 300 metric 1 1 1 1 1 router bgp 300 bgp router-id 14.14.14.14 bgp log-neighbor-changes redistribute eigrp 100 neighbor 192.168.0.13 remote-as 65000 R14#sh ip bgp BGP table version is 15, local router ID is 14.14.14.14 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 10.10.10.10/32 192.168.0.13 0 65000 200 i *> 14.14.14.14/32 0.0.0.0 0 32768 ? *> 15.15.15.15/32 192.168.101.15 409600 32768 ? *> 22.22.22.22/32 192.168.101.22 409600 32768 ? *> 192.168.100.0 192.168.0.13 0 65000 200 i *> 192.168.101.0 0.0.0.0 0 32768 ? R14#
Ennyi információnk van, nézzük, hogy oldjuk meg a problémát.
Mint említettem, mi csak az ISP eszközökhöz férünk hozzá.
Az ügyfél problémája tehát, hogy nem látszódik mindhárom transit link (192.168.0.0/30, 192.168.0.12/20, 192.168.0.20/30), illetve néhány internal subnet is hiányzik a BGP táblából.
R2-n a
- 192.168.0.12/30
- 192.168.0.20/30
- 192.168.101.0/24 hiányzik,
R10-n a
- 192.168.0.12/20
- 192.168.0.20/30,
R14-n pedig egyik transit linket sem látjuk, illetve hiányzik a HQ 10.1.1.0/24 subnete is.
Nézzük először a transit linkek problémáját. Az internal subnetekre vonatkozó hibát később nézzük meg, mert azt látjuk az ügyfél konfigjában, hogy redisztribúcióval vagy network paranccsal azokat behirdette, tehát valami BGP probléma lehet.
Első kérdésünk legyen: hirdeti -e az ügyfél a transit linkeket BGP-be? Azt írta a levélben, hogy IGP->BGP redisztribúciót csinál, illetve R10-en lokális subnet behirdetést. Ez alapján azt sejtjük, hogy a transit linkeket nem hirdetik BGP-be, mert akkor látnunk kellene őket locally injected BGP route-ként. Érdekes módon R2-n látjuk a következőt BGP táblában:
*> 192.168.0.0/30 0.0.0.0 0 32768 ?
Elemezzük ezt picit. Weight 32768, azaz mi hirdettük be. Origin “?”, azaz redisztribúcióból jött. Ez hogy lehet?
Jusson eszünkbe, hogy redisztribúció esetén nemcsak a forrás routing protocol által RIB-ben lévő route-k, hanem a network parancs által engedélyezett connected subnetek is hirdetésre kerülnek (IPv4 esetébenlegalábbis, IPv6-nál már nem, ott kell a “redistribute connected”). Tehát R2 esetében, ha az EIGRP konfig tartalmazza ezt: “network 192.168.0.0 0.0.0.3”, vagy esetleg véletlenül ezt: “network 0.0.0.0”, akkor BGP-ben meg kell jelennie a transit linknek.
Erre rá is kérdeztünk, és egy e-mail váltás után ezt a választ kaptuk:
From: it.team@kuglofasz.hu
To: support@isp1.com
Subject: RE: BGP probléma
Helló support,
Igen, véletlenül a junior kolléga az alábbi parancsot használta az EIGRP konfigurációban:
R2#sh run | s eigrp
router eigrp CISCO
<kivágva>
topology base
redistribute bgp 100 metric 10000 1 255 1 1500
exit-af-topology
network 0.0.0.0
eigrp router-id 2.2.2.2
exit-address-family
R2#
Ezt javítottuk. Köszönjük az észrevételt és további segítségüket!
Üdvözlettel:
Kuglófasz IT Team
Javították, szóval most már sehol semmi nem látszik. Az SLA meg ketyeg ugyebár 🙂 .
Mivel az ügyfél elzárkózott a további konfiguráció módosítástól, nekünk kell gondoskodnunk a teljeskörű megoldásról. El kell érnünk, hogy látszódjanak BGP-ben a transit linkek. Hogy tudjuk ezt megoldani?
- redistribute connected a PE routereken a CUST vrf-ben (ne feledjük, MPLS VPN-t adunk, a customer felé a CUST vrf-et használjuk)
- network <transit link> hirdetése BGP-vel a CUST vrf-ben.
Mivel a kettő között minimális különbség van (redistribute-nál “?” az origin, míg network parancsnál “i”), én most vegyesen fogom alkalmazni a kettőt (való életben persze nem vegyesen csináljuk, de itt most technológiai megoldásokról van szó).
De mielőtt ezt megtennénk, nézzük előbb, hogy mit látunk mi a PE routereken.
R4#sh bgp vpnv4 uni vrf CUST | i 192.168.0.0|192.168.0.12|192.168.0.20 R4# R8#sh bgp vpnv4 uni vrf CUST | i 192.168.0.0|192.168.0.12|192.168.0.20 R8# R9#sh bgp vpnv4 uni vrf CUST | i 192.168.0.0|192.168.0.12|192.168.0.20 *>i 192.168.0.0/30 4.4.4.4 0 100 0 100 ? R9#
Első lépésként tehát hirdessük be a connected subneteket a PE routereken:
R4#conf t Enter configuration commands, one per line. End with CNTL/Z. R4(config)#router bgp 65000 R4(config-router)# address-family ipv4 vrf CUST R4(config-router-af)#redistribute connected R4(config-router-af)#end R4# R8(config)#router bgp 65000 R8(config-router)# address-family ipv4 vrf CUST R8(config-router-af)#network 192.168.0.12 mask 255.255.255.252 R8(config-router-af)#end R8# R9(config)#router bgp 65000 R9(config-router)# address-family ipv4 vrf CUST R9(config-router-af)#redistribute connected R9(config-router-af)#end R9#
Nézzük, mi változott.
R4#sh bgp vpnv4 uni vrf CUST | i 192.168.0.0|192.168.0.12|192.168.0.20 *> 192.168.0.0/30 0.0.0.0 0 32768 ? *>i 192.168.0.20/30 9.9.9.9 0 100 0 ? R4# R8#sh bgp vpnv4 uni vrf CUST | i 192.168.0.0|192.168.0.12|192.168.0.20 *> 192.168.0.12/30 0.0.0.0 0 32768 i *>i 192.168.0.20/30 9.9.9.9 0 100 0 ? R8# R9#sh bgp vpnv4 uni vrf CUST | i 192.168.0.0|192.168.0.12|192.168.0.20 *>i 192.168.0.0/30 4.4.4.4 0 100 0 ? *>i 192.168.0.12/30 8.8.8.8 0 100 0 i *> 192.168.0.20/30 0.0.0.0 0 32768 ? R9#
Egyedül R9 tud minden route-ról (mivel ez a router az MPLS VPN RR), a többiek még mindig nem kapták meg a többi subnetet.
RD/RT értékeket leellenőriztük a PE routereken, ott minden oké, import/export 65000:1, pipa, nem ez a gond.
Nézzük R9-et közelebbről. Ő az RR, azaz R4-R8 által kapott route-kat hirdetnie kellene a másiknak (R4 -> R8, illetve R8 -> R4 irányok).
R9#sh bgp vpnv4 uni all neighbors 4.4.4.4 advertised-routes | i 192.168.0 *> 10.10.10.10/32 192.168.0.22 0 0 200 i *> 192.168.0.20/30 0.0.0.0 0 32768 ? *> 192.168.100.0 192.168.0.22 0 0 200 i R9# R9#sh bgp vpnv4 uni all neighbors 8.8.8.8 advertised-routes | i 192.168.0 *> 10.10.10.10/32 192.168.0.22 0 0 200 i *> 192.168.0.20/30 0.0.0.0 0 32768 ? *> 192.168.100.0 192.168.0.22 0 0 200 i R9#
Azt látjuk, hogy R4/R8 nem is kapja meg a route-kat a route reflectortól. Ez vajon miért lehet?
Hogy működik az RR?
- client -> client — hirdetjük
- client -> non-client — hirdetjük
- non-client -> non-client — NEM hirdetjük.
Nézzük R9 BGP konfigurációját:
R9#sh run | s bgp router bgp 65000 bgp router-id 9.9.9.9 bgp log-neighbor-changes neighbor 4.4.4.4 remote-as 65000 neighbor 4.4.4.4 update-source Loopback0 neighbor 4.4.4.4 route-reflector-client neighbor 8.8.8.8 remote-as 65000 neighbor 8.8.8.8 update-source Loopback0 neighbor 8.8.8.8 route-reflector-client ! address-family vpnv4 neighbor 4.4.4.4 activate neighbor 4.4.4.4 send-community extended neighbor 8.8.8.8 activate neighbor 8.8.8.8 send-community extended exit-address-family ! address-family ipv4 vrf CUST redistribute connected neighbor 192.168.0.22 remote-as 200 neighbor 192.168.0.22 activate exit-address-family R9#
Első ránézésre ez jónak is tűnik, ott vannak a neighborok, R4 és R8 route-reflector client, vpnv4 address family alatt aktiválva R4 és R8 is. De mégsem jó. Miért? A RR konfignak is a vpnv4 address family alá kell kerülnie. Azaz jelenleg R9 nem route-reflector, hanem csak sima iBGP peer R4 és R8 routerekkel, mivel a RR konfig nem az address family alatt került aktiválásra. Ezért nem is hirdeti az iBGP által tanult route-kat a másiknak.
Javítsuk ki gyorsan.
R9(config)#router bgp 65000 R9(config-router)#address-family vpnv4 R9(config-router-af)#neighbor 4.4.4.4 route-reflector-client R9(config-router-af)#neighbor 8.8.8.8 route-reflector-client R9(config-router-af)#end R9# *May 15 10:47:37.961: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Down RR client config change *May 15 10:47:37.961: %BGP_SESSION-5-ADJCHANGE: neighbor 4.4.4.4 VPNv4 Unicast topology base removed from session RR client config change *May 15 10:47:37.961: %BGP_SESSION-5-ADJCHANGE: neighbor 4.4.4.4 IPv4 Unicast topology base removed from session RR client config change *May 15 10:47:38.054: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Up *May 15 10:47:43.159: %BGP-5-ADJCHANGE: neighbor 8.8.8.8 Down RR client config change *May 15 10:47:43.159: %BGP_SESSION-5-ADJCHANGE: neighbor 8.8.8.8 VPNv4 Unicast topology base removed from session RR client config change *May 15 10:47:43.159: %BGP_SESSION-5-ADJCHANGE: neighbor 8.8.8.8 IPv4 Unicast topology base removed from session RR client config change *May 15 10:47:43.191: %BGP-5-ADJCHANGE: neighbor 8.8.8.8 Up R9# *May 15 10:47:44.214: %SYS-5-CONFIG_I: Configured from console by console R9#
Nézzük, mi változott:
R9#sh bgp vpnv4 uni all neighbors 4.4.4.4 advertised-routes | i 192.168.0 *> 10.10.10.10/32 192.168.0.22 0 0 200 i *>i 192.168.0.0/30 4.4.4.4 0 100 0 ? *>i 192.168.0.12/30 8.8.8.8 0 100 0 i *> 192.168.0.20/30 0.0.0.0 0 32768 ? *> 192.168.100.0 192.168.0.22 0 0 200 i R9#sh bgp vpnv4 uni all neighbors 8.8.8.8 advertised-routes | i 192.168.0 *> 10.10.10.10/32 192.168.0.22 0 0 200 i *>i 192.168.0.0/30 4.4.4.4 0 100 0 ? *>i 192.168.0.12/30 8.8.8.8 0 100 0 i *> 192.168.0.20/30 0.0.0.0 0 32768 ? *> 192.168.100.0 192.168.0.22 0 0 200 i R9#
Na ez már mindjárt jobb!
Mivel most már rendben van a route-reflector konfig, ezért az internal subneteket is látnunk kell mindhárom eszközön.
R9#sh bgp vpnv4 uni vrf CUST | i 10.1.1.0|192.168.0.|192.168.10(.) *>i 10.1.1.0/24 4.4.4.4 0 100 0 100 ? *> 10.10.10.10/32 192.168.0.22 0 0 200 i *>i 192.168.0.0/30 4.4.4.4 0 100 0 ? *>i 192.168.0.12/30 8.8.8.8 0 100 0 i *> 192.168.0.20/30 0.0.0.0 0 32768 ? *> 192.168.100.0 192.168.0.22 0 0 200 i *>i 192.168.101.0 8.8.8.8 0 100 0 300 ? R9# R4#sh bgp vpnv4 uni vrf CUST | i 10.1.1.0|192.168.0.|192.168.10(.) *> 1.1.1.1/32 192.168.0.2 1024640 0 100 ? *> 2.2.2.2/32 192.168.0.2 0 0 100 ? *> 3.3.3.3/32 192.168.0.2 1024640 0 100 ? *> 10.1.1.0/24 192.168.0.2 0 0 100 ? *> 16.16.16.16/32 192.168.0.2 1024640 0 100 ? *> 192.168.0.0/30 0.0.0.0 0 32768 ? * 192.168.0.2 0 0 100 ? *>i 192.168.0.12/30 8.8.8.8 0 100 0 i *>i 192.168.0.20/30 9.9.9.9 0 100 0 ? *>i 192.168.100.0 9.9.9.9 0 100 0 200 i *>i 192.168.101.0 8.8.8.8 0 100 0 300 ? R4# R8#sh bgp vpnv4 uni vrf CUST | i 10.1.1.0|192.168.0.|192.168.10(.) *>i 10.1.1.0/24 4.4.4.4 0 100 0 100 ? *> 14.14.14.14/32 192.168.0.14 0 0 300 ? *> 15.15.15.15/32 192.168.0.14 409600 0 300 ? *> 22.22.22.22/32 192.168.0.14 409600 0 300 ? *>i 192.168.0.0/30 4.4.4.4 0 100 0 ? *> 192.168.0.12/30 0.0.0.0 0 32768 i *>i 192.168.0.20/30 9.9.9.9 0 100 0 ? *>i 192.168.100.0 9.9.9.9 0 100 0 200 i *> 192.168.101.0 192.168.0.14 0 0 300 ? R8#
Na erről van szó, ez az elvárt output.
Kérjük meg az ügyfelet a tesztelésre!
From: it.team@kuglofasz.hu
To: support@isp1.com
Subject: RE: BGP probléma – megoldva, tesztre vár
Helló support,
Igen, minden működik, köszönjük szépen a gyors segítséget!
R2#tclsh
R2(tcl)#foreach X {
+>(tcl)#192.168.0.14
+>(tcl)#192.168.0.22
+>(tcl)#192.168.100.2
+>(tcl)#192.168.101.22
+>(tcl)#} { ping $X source e0/1 }
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.14, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.22, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/7 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.2
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/10/38 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.101.22, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms
R2(tcl)#
R2#tclsh
R2(tcl)#foreach X {
+>(tcl)#192.168.0.14
+>(tcl)#192.168.0.22
+>(tcl)#192.168.100.2
+>(tcl)#192.168.101.22
+>(tcl)#} { ping $X source e0/0 }
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.14, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.22, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.101.22, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R2(tcl)#Üdvözlettel:
Kuglófasz IT Team
A CCIE labor TSHOOT részén ez egy 2 pontos ticket szintjének felel meg.