BGP – Advanced BGP Lab, del 1

Var ett tag sedan jag konfigurerade något nu så fick lite abstinens… 😉 Tänkte göra ett försök på Renée’s “Advanced BGP-Lab” ikväll från www.gns3vault.com.

Topologin ser ut enligt följande:

bgp-advanced-lab

R1 – R2: 192.168.12.X / R1 – R3: 192.168.13.X / R3 – R4: 192.168.34.X (where X = Router number) etc..

Every router has a Loopback0 interface: X.X.X.X (where X = Router number)

  • Configure each Autonomous System (AS) with a different IGP:
    AS100: RIP
    AS300: OSPF
    AS200: EIGRP
    AS400: OSPF
  • Do not configure the IGP on the interfaces connecting to another AS. For example; R3 should not send any RIP routing updates towards R4.
  • Make sure the loopbacks are advertised in the IGP’s.
  • Configure BGP on every router, make sure you have the right IBGP and EBGP configurations. AS300 has to be configured as a confederation.
  • R1 has to be configured as a route-reflector for R2 and R3.
  • Configure on all routers that BGP updates are sourced from the Loopback0 interface.
  • Configure BGP authentication between R7 and R11, use password VAULT
  • Make sure all BGP neighbor relationships are working before you continue with the next steps.
  • Advertise all physical and loopback interfaces in BGP, you are not allowed to use the “network” command to achieve this.
  • Achieve full connectivity, every IP address should be pingable. Use a TCLSH script to do this.
  • When R4 sends a ping to the loopback interface of R1 it should choose the path through R2. You are only allowed to make changes on R3.
  • Create another loopback interface on R1 with ip address 172.16.1.1 /24, advertise this in RIP.
  • When R4 sends a ping to the 172.16.1.1 address it should take the path through R3, you are only allowed to make changes on R4.
  • When R6 sends a ping towards the loopback interface on R11 it should go through AS300.
  • R7 should prefer the path through R11 for all external networks except for 172.16.1.1.
  • Configure AS300 so it is no longer a transit AS for AS200 to reach 172.16.1.1 in AS100. AS400 should not be influenced.

Får se hur långt vi hinner idag, kommer troligtvis att bli (minst) två inlägg istället. Men låt oss börja med basics, sätta upp IGPs inom respektive AS.

IGP Routing

  • Configure each Autonomous System (AS) with a different IGP:
    AS100: RIP
    AS300: OSPF
    AS200: EIGRP
    AS400: OSPF
  • Do not configure the IGP on the interfaces connecting to another AS. For example; R3 should not send any RIP routing updates towards R4.
  • Make sure the loopbacks are advertised in the IGP’s.

Finns inte direkt något speciellt att tänka på här. Använd passive-interface default enligt best practice och kom ihåg att annonsera Loopback för respektive router.

RIP / AS100

R1
router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet1/0
 network 1.0.0.0
 network 192.168.12.0
 network 192.168.13.0
 no auto-summary

R2
 router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 network 2.0.0.0
 network 192.168.12.0
 no auto-summary

R3
 router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 network 3.0.0.0
 network 192.168.13.0
 no auto-summary

OSPF / AS300

R4
 router ospf 300
 router-id 4.4.4.4
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet2/0
 network 4.4.4.0 0.0.0.255 area 0
 network 192.168.45.0 0.0.0.255 area 0

interface Loopback0
 ip ospf network point-to-point

 R5
router ospf 300
 router-id 5.5.5.5
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet1/0
 network 5.5.5.0 0.0.0.255 area 0
 network 192.168.45.0 0.0.0.255 area 0
 network 192.168.58.0 0.0.0.255 area 0

 interface Loopback0
 ip ospf network point-to-point

 R8
 router ospf 300
 router-id 8.8.8.8
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet1/0
 network 8.8.8.0 0.0.0.255 area 0
 network 192.168.58.0 0.0.0.255 area 0
 network 192.168.89.0 0.0.0.255 area 0

 interface Loopback0
 ip ospf network point-to-point

R9
 router ospf 300
 router-id 9.9.9.9
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet1/0
 network 9.9.9.0 0.0.0.255 area 0
 network 192.168.89.0 0.0.0.255 area 0

interface Loopback0
 ip ospf network point-to-point

Anledningen till att jag lagt till “ospf network point-to-point” är för att OSPF per default annars sätter network-type till stub för Loopbacks och endast annonserar våra nät som en /32.

EIGRP / AS200

R6
 router eigrp 200
 passive-interface default
 no passive-interface FastEthernet0/0
 network 7.7.7.0 0.0.0.255
 network 192.168.67.0
 no auto-summary

R7
 router eigrp 200
 passive-interface default
 no passive-interface FastEthernet1/0
 network 6.6.6.0 0.0.0.255
 network 192.168.67.0
 no auto-summary

OSPF / AS400

R10
router ospf 400
 router-id 10.10.10.10
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 network 10.10.10.0 0.0.0.255 area 0
 network 192.168.110.0 0.0.0.255 area 0

interface Loopback0
 ip ospf network point-to-point

R11
router ospf 400
 router-id 11.11.11.11
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet1/0
 network 11.11.11.0 0.0.0.255 area 0
 network 192.168.110.0 0.0.0.255 area 0

interface Loopback0
 ip ospf network point-to-point

BGP

IBGP & Route-reflector

  • Configure BGP on every router
  • Configure on all routers that BGP updates are sourced from the Loopback0 interface.
  • R1 has to be configured as a route-reflector for R2 and R3.

Allt är relativt standard, kom ihåg att ändra update-source när vi använder Loopback-adresser för peering.

R1 – Kom ihåg route-reflector mot R2 & R3!

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 100
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 route-reflector-client
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 route-reflector-client
 no auto-summary

R2

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary

R3

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary

Blir lite tjatigt att ta med i princip identisk konfig för R6, R7, R10 & R11 så hoppar över det.

R4, R5, R8 & R9 tar vi nästa punkt då det ska konfigureras confederations istället.

Confederations

  • AS300 has to be configured as a confederation.

Vi tar och börjar med att sätta upp två confederations inom AS300, Sub-AS 10 & 20. Om du vill läsa mer om confederations har jag ett gammalt inlägg som går igenom detta relativt grundligt här.  Vanligtvis använder man privata AS-nummer för detta men tar och följer labben slaviskt nu.. 🙂

R4

router bgp 10
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 20
 neighbor 5.5.5.5 remote-as 10
 neighbor 5.5.5.5 update-source Loopback0
 no auto-summary

R5

router bgp 10
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 20
 neighbor 4.4.4.4 remote-as 10
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 8.8.8.8 remote-as 20
 neighbor 8.8.8.8 update-source Loopback0
 no auto-summary

R8

router bgp 20
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 10
 neighbor 5.5.5.5 remote-as 10
 neighbor 5.5.5.5 update-source Loopback0
 neighbor 9.9.9.9 remote-as 20
 neighbor 9.9.9.9 update-source Loopback0
 no auto-summary

R9

router bgp 20
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 10
 neighbor 8.8.8.8 remote-as 20
 neighbor 8.8.8.8 update-source Loopback0
 no auto-summary

Det var all konfig.. Men tyvärr fungerade det inte riktigt som önskat. IBGP kom upp utan problem men av någon anledning får jag ej upp någon neighbor mellan R5 <-> R8.

R5#sh ip bgp
 *Mar 1 06:30:59.486: %SYS-5-CONFIG_I: Configured from console by consolesummary
 BGP router identifier 5.5.5.5, local AS number 10
 BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
 4.4.4.4 4 10 27 27 1 0 0 00:23:08 0
 8.8.8.8 4 20 0 0 0 0 0 never Idle

En debug ip bgp events gav inte heller någon vettig information. Tillslut kom jag äntligen på vad felet var: ebgp-multihop! TTL för EBGP är ju per default satt till 1, så när paketet när R5/R8 kastas paketet istället för att vidarebefordras till Loopback. Detta var inte direkt första gången jag åkt dit på den grejjen.. 🙂

R5
 neighbor 8.8.8.8 ebgp-multihop 2
 R8
 neighbor 5.5.5.5 ebgp-multihop 2

Nu ser det bättre ut!

R8#sh ip bgp summary
 BGP router identifier 8.8.8.8, local AS number 20
 BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
 5.5.5.5 4 10 4 4 1 0 0 00:00:29 0
 9.9.9.9 4 20 15 15 1 0 0 00:11:38 0

Detta får räcka för idag, känns som inlägget blir lite väl långt annars. Fortsättning följer!

BGP – Route Reflector II

Detta blir en fortsättning på gårdagens inlägg om Confederations & Route Reflectors.

Genom användandet av Route Reflectors får vi möjligheten att undvika de problem som annars uppstår på grund av iBGP’s Split-Horizon. När vår RR mottager en routing-uppdatering hanterar den informationen enligt följande:

  • Härstammar paketet från en eBGP-peer vidarebefordras paketet till samtliga iBGP & eBGP-peers
  • Härstammar paketet från en iBGP-peer (“Non-Client”) vidarebefordras paketet till samtliga eBGP-peers samt “Clients”
  • Härstammar paketet från en iBGP-peer (“Client”) vidarebefordras paketet till samtliga peers (förutom avsändaren)

Jämför detta med en standard iBGP-peer som per default EJ skickar vidare någon routing-information! Vi konfigurerar om en neighbor är att betrakta som “Client” eller ej under BGP-processen för vår RR, men mer om detta senare.

routereflector-topology

Redan vid en mindre topologi som den ovan blir det nästan löjligt många iBGP-peers vi behöver konfigurera upp för att vi ska få ett full-mesh förhållande. Men genom att istället använda oss av Route Reflectors räcker det att vi peerar mot en (eller flera för redundans) av de centrala routrarna som sedan vidarebefordrar routing-informationen till resterande routrar inom vårat AS.

routereflector-redundant

När vi får in en routing-uppdatering via eBGP vidarebefordrar “klienten” detta till samtliga RR, som i sin tur sprider denna information vidare till sina neighbors. Detta innebär att klienterna får dubbla uppdateringar, vilket dock inte är något problem om vi tänker efter. Våra routingprotokoll är ju vana vid att få flera alternativa vägar att välja på och ta beslut om vilken väg den anser är bäst.

Något som dock kan bli problematiskt är om vi har 3-4+ RR i ett redundant nät.

routereflector-topology2

I det här fallet så vidarebefordrar en “klient” sin uppdatering till sin RR, vilket skickar vidare informationen till alla peers (inkluderat övriga RR). Resterande RR’s gör ju dock samma sak när de mottager paketet vilket vips leder till att vi har en loop i vårat nät.

Vi kan lösa detta via ett iBGP-Attribut som kallas “Cluster-ID“, en RR taggar då alla routing-uppdateringar den vidarebefordrar med just detta cluster-id (samt sitt router-id som originator). Genom att gruppera våra RRs till ett och samma kluster ger det övriga RR’s möjlighet att inspektera BGP Update-paket den mottager, skulle den se sitt eget cluster-id/router-id så ignoreras paketet!   Detta innebär dock som sagt att vi måste konfigurera neighbor-relations till samtliga RRs vi har i vårat nät.

routereflector-topology3

Det går även bra att segmentera vårat AS och ha flera mindre klusters på ungefär samma sätt som vi använder Confederations, vi peerar sedan mellan RR/klustren för att sprida routing-informationen.

Själva konfigurationen är oerhört enkel, det är snarare konceptet hur vi ska implementera detta på bästa sätt som är det svåra.

För att konfigurera en router till RR  lägger vi till följande i våra neighbor-statements för våra “klienter”/övriga RRs:

router bgp n
 neighbor x.x.x.x route-reflector-client
 bgp cluster-id n

Själva klienterna är helt omedvetna om att de faktiskt är en RR-klient och kräver ingen extra konfiguration för att detta skall fungera.

BGP – Confederations & Route Reflectors

Confederations

confederations

På grund av hur Split-Horizon fungerar (se tidigare inlägg om detta här & här) så måste vi sätta upp våra iBGP-neighbors i ett full-mesh förhållande. Detta blir redan vid bara fyra routrar som i ovanstående topologi en väldans massa neighbors att konfigurera (12).

Men genom att använda oss “BGP Confederations” får vi möjligheten att dela upp vårat AS(400) i flera mindre interna AS! I detta exempel delades kontoren upp efter ort, men det går givetvis att bestämma helt och hållet själv efter egna preferenser.

ISP-Telia & Tele2 kommer fortfarande endast peera med AS400 precis som tidigare. Confederations används nämligen endast inom vårat eget AS och confederation-taggen tas bort innan informationen skickas vidare till våra eBGP-neighbors (externa AS).

Genom att dela upp kontoren i Västerås & Stockholm till varsitt AS minskar vi betydligt på antalet iBGP-neighbors vi behöver konfigurera, och gör nätet i allmänhet lättare att administrera. Nu är ju detta ett extremt litet nät, men om du istället tänker dig en ISP-mijö där varje router här kanske i verkligheten motsvarar 200-300 routrar så ser man ganska snabbt hur stökigt det kan bli om vi ej haft någon möjlighet att segmentera näten.

Vilka AS-nummer ska vi då använda oss av för våra Confederation-grupper? Vi kan ju inte gärna bara ta några per random då vi med all sannolikhet kommer ta ett nummer som redan ägs av ett annat företag. Även om vi inte annonserar ut detta på internet så kommer vi själva inte kunna nå prefixen som tillhör det AS vi nu angett. Kom ihåg att BGP undviker routing-loopar genom att inspektera AS_Path – finner den sitt eget AS-nummer i en uppdatering så ignoreras den.

RFC 6996 anger AS 64512 – 65534 som Privata AS, detta fungerar precis på samma sätt som konceptet med privata ip-adresser!  Låt oss därför sätta AS 64512 för Västerås-kontoret och AS 64513 för Stockholm.

Genom att lägga R1-R3 i ett eget AS så innebär det att mellan R3 – R5 kommer upprättas en eBGP-koppling istället för iBGP! Detta innebär även att du nu måste konfigurera ebgp-multihop om du peerar mot loopback-adresser. BGP attribut, som exempelvis”Next Hop” eller “Local Preference”, fungerar dock fortfarande som att de skulle vara iBGP-peers!

Konfigurering

Låt oss börja med R1.

router bgp 64512
bgp confederation identifier 400
 bgp confederation peers 64513 
 neighbor 10.10.12.2 remote-as 64512
 neighbor 172.16.100.2 remote-as 2200

bgp confederation identifier n är det AS vi kommer annonsera till våra eBGP-peers, dvs ISP-Telia & Tele2. bgp confederation peers n listar de confederation as-nummer du vill peera med, i detta fall har vi endast AS64513. Våra neighbor-statements ersätts nu med vårat confederation-as 64512 istället för AS 400. Svårare än så är det inte rent konfigmässigt!

R2

router bgp 64512
bgp confederation identifier 400
 bgp confederation peers 64513 
 neighbor 10.10.12.1 remote-as 64512
 neighbor 10.10.23.3 remote-as 64512
 neighbor 172.32.200.2 remote-as 1500

R3

router bgp 64512
bgp confederation identifier 64512
 bgp confederation peers 64513 
 network 192.168.0.0
 neighbor 10.10.23.2 remote-as 64512
 neighbor 10.10.35.5 remote-as 64513

R5

router bgp 64513
bgp confederation identifier 400
 bgp confederation peers 64512 
 neighbor 10.10.35.3 remote-as 64512

Detta ger oss följande output i R5:

r5

Intressant att notera här är AS_Path – routern känner igen att 64512 är ett “confederation”-AS och skrivs därav inom parentes. Vi saknar dock en hel del routes, kan du se varför utifrån konfigen ovan?

iBGP Split-Horizon! R2 kommer aldrig skickade vidare den routing-information den fått från R1 via iBGP. Vi har här tre möjliga lösningar:

  • Vi skapar ett full-mesh neighbor-relationship inom vår confederation
  • Vi flyttar R3 till AS64513, R2 kommer då vidarebefordra uppdateringarna då länken betraktas som en eBGP-peer
  • Route-Reflectors

Att flytta R3 till AS64513 är givetvis fullt möjligt men samtidigt så har vi ju då inte längre någon indelning efter ort, och tillkommer det fler routrar senare till vår topologi kan det nog vara väldigt lätt att det blir fel förr eller senare.

Att istället skapa en full mesh-lösning känns kanske enklast för oss just nu, främst då det i denna topologi endast innebär ytterligare ett neighbor-relationship mellan R1 & R3.

Vi skulle dock istället kunna använda oss av en funktion kallad “Route-Reflectors”.

Route-Reflectors

Genom att aktivera route-reflection stänger vi indirekt av iBGP’s Split-Horizon, vilket tillåter oss vidarebefordra routing-uppdateringar till andra iBGP-peers.

routereflector

Tar vi en närmare titt på vår topologi i Västerås ser vi att R2 är väl den som bäst skulle kunna fylla denna roll. Konfigurationen är oerhört enkel som mycket annat när det kommer till BGP, det är snarare själva planeringen som är det svåra. Då vi stänger av Split-horizon kan detta leda till enorma problem med routing-loopar om vi inte är väldigt försiktiga! Det gäller därför att verkligen tänka efter var vi implementerar detta.

I detta fall finns det ingen risk att R3 lär sig routes från R1 från någon annan router än just R2, likaså för R1 gällande R3’s routes.

Vi aktiverar detta på R2 via:

router bgp 65435
 neighbor 10.10.12.1 route-reflector-client
 neighbor 10.10.23.3 route-reflector-client

Löjligt enkelt va? 🙂

R1 kan nu se R3/R5’s routes och vice versa:

r1-routereflector

R5

r5-routereflector

Det finns dock betydligt mer att gå över gällande Route-Reflectors, men det får bli i en senare post – troligtvis imorgon!