A BGP hibajegy megoldása lépésről lépésre

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:

bgp

 

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.