Kategori: BGP

VRF-Lite & BGP

Jonas CollénBGP

Tänkte skriva ett kortare inlägg om ett rätt intressant problem jag stötte på tidigare vilket löstes med hjälp av VRF-Lite och lite trixande med BGP. Topologin som önskades var enligt följande:

lightvrf

Länken mot ISP-1 önskades vara primär pga bättre serviceavtal & bandbredd samtidigt som länken till ISP-2 endast skulle användas som backup. Både ISP-1 & 2 genererar en default-route samt annonserar varsitt 10.x.0.0/23-nät. Det fanns även önskemål att AS #666 skulle agera transit mellan ISP-1 & 2.

lightvrfigp

Som IGP användes EIGRP inom AS #666 samt mellan R1 – ISP-1 och OSPF mellan R3 – ISP-2 där respektive länknät redistributas. Detta är egentligen helt onödigt men användes för att göra uppgiften lite mer komplicerad bara. 🙂

Problematiken var dock att ISP-1 & ISP-2 består av en och samma router! Den fysiska topologin ser nämligen ut enligt följande:

lightvrftopologi

Med andra ord behöver vi dela upp R1 till två virtuella routrar med separata routing tables & bgp-adjacencys. Detta löser vi med hjälp av VRF-Lite! 🙂

Låt oss ta och kika lite närmare på konfigen för respektive router.

R2

interface Serial1/0
 ip address 12.0.0.2 255.255.255.252
 description Primary uplink to ISP-1
 no shut
interface Loopback3
 description For testing
 ip address 172.32.0.1 255.255.255.0
 no shut
interface Loopback4
 description For testing
 ip address 172.32.1.1 255.255.255.0
 no shut

interface FastEthernet0/0
 description to MLS1
 ip address 172.16.11.11 255.255.255.0
 ip hello-interval eigrp 101 2
 ip hold-time eigrp 101 6
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 s3cr3t
 ip summary-address eigrp 101 172.32.0.0 255.255.254.0 5
 duplex full
 speed 100
 no shut

IGP-konfig

Då vi endast vill redistributa in länknätet mellan R1 & ISP-1 till EIGRP 101 använde jag en en route-map, passade även på att tagga route’sen om vi skulle behöva utföra någon filtrering senare.

!Internal IGP-routing
router eigrp 101
 redistribute eigrp 666 route-map EIGRP666-EIGRP101
 passive-interface default
 no passive-interface FastEthernet0/1
 network 172.16.0.0
 network 172.32.0.0 0.0.0.255
 network 172.32.1.0 0.0.0.255
 no auto-summary
 eigrp router-id 172.16.99.11

ip prefix-list EIGRP666-EIGRP101 seq 5 permit 12.0.0.0/30

route-map EIGRP666-EIGRP101 permit 10
 match ip address prefix-list EIGRP666-EIGRP101
 set metric 100000 100 255 1 1500
 set tag 1666

route-map EIGRP666-EIGRP101 deny 20

!External IGP routing ISP-1
router eigrp 666
 passive-interface default
 no passive-interface Serial1/0
 network 12.0.0.0 0.0.0.3
 no auto-summary

BGP

Inga konstigheter här, peer-groups för lite mer “kompakt” konfig.

router bgp 666
 no synchronization
 bgp log-neighbor-changes
 network 172.16.0.0
 network 172.32.0.0 mask 255.255.254.0
 redistribute eigrp 666

 neighbor 12.0.0.1 remote-as 65001
 neighbor 12.0.0.1 description ISP-1

 neighbor IBGP peer-group
 neighbor IBGP remote-as 666
 neighbor IBGP next-hop-self
 neigbhor IBGP password s3cr3t

 neighbor 172.16.11.1 peer-group IBGP
 neighbor 172.16.11.1 description MLS1
 neighbor 172.16.13.3 peer-group IBGP
 neighbor 172.16.13.3 description MLS2
 neighbor 172.16.33.33 peer-group IBGP
 neighbor 172.16.33.33 description R3
 no auto-summary

Konfigen är mer eller mindre identisk för R3.

Default-route

Som nämndes tidigare önskades företaget att vi använda denna länk som primär, både ISP-1 & 2 genererade varsin default-route. Att ändra local pref för samtliga routes vi lär oss från ISP-1 hade inte varit något hit då det även skulle påverka trafik vi är transit för. Tänkte istället använda en route-map som sätter en högre local pref endast för default-routen. Vi behöver även se till så att vi ej annonserar default-routen vidare utanför vårat AS.

R2

router bgp 666
 neighbor 12.0.0.1 prefix-list DEFAULT-ROUTE-BLOCK out
 neighbor 12.0.0.1 route-map ISP1-routes in

ip prefix-list DEFAULT-ROUTE-BLOCK seq 5 deny 0.0.0.0/0
ip prefix-list DEFAULT-ROUTE-BLOCK seq 10 permit 0.0.0.0/0 le 32

ip prefix-list default-route seq 5 permit 0.0.0.0/0

route-map ISP1-routes permit 10
 match ip address prefix-list default-route
 set local-preference 150

route-map ISP1-routes permit 20

R3

router bgp 666
 neighbor 13.0.0.1 prefix-list DEFAULT-ROUTE-BLOCK out
 neighbor 13.0.0.1 route-map ISP2-routes in

ip prefix-list DEFAULT-ROUTE-BLOCK seq 5 deny 0.0.0.0/0
ip prefix-list DEFAULT-ROUTE-BLOCK seq 10 permit 0.0.0.0/0 le 32

ip prefix-list default-route seq 5 permit 0.0.0.0/0

route-map ISP2-routes permit 10
 match ip address prefix-list default-route
 set local-preference 110

route-map ISP2-routes permit 20

Vilket ger följande resultat:

R3#sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 4
Paths: (2 available, best #1, table Default-IP-Routing-Table)
 Not advertised to any peer
 65001
  172.16.11.11 (metric 30720) from 172.16.11.11 (172.32.1.1)
   Origin IGP, metric 0, localpref 150, valid, internal, best
 65002
  13.0.0.1 from 13.0.0.1 (2.2.2.2)
   Origin IGP, metric 0, localpref 100, valid, external

VRF-Lite / R1

Nu över till det lite roligare. 🙂 VRF:er har vi ju redan konfat i flera tidigare inlägg, så detta är väl inte direkt något nytt men själva användningsområdet  är något jag aldrig stött på tidigare.

interface Loopback1
 ip vrf forwarding ISP-1
 ip address 10.1.0.1 255.255.255.0

interface Loopback2
 ip vrf forwarding ISP-1
 ip address 10.1.1.1 255.255.255.0

interface Loopback3
 ip vrf forwarding ISP-2
 ip address 10.2.0.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0

interface Loopback4
 ip vrf forwarding ISP-2
 ip address 10.2.1.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0

interface Loopback5
 ip vrf forwarding Shared
 ip address 1.1.1.1 255.255.255.255

interface Loopback6
 ip vrf forwarding Shared
 ip address 2.2.2.2 255.255.255.255

interface Loopback11
description Management - RID
ip address 11.11.11.11 255.255.255.255

interface Serial0/0/0
 description ISP-1 to CustomerA-R1
 ip vrf forwarding ISP-1
 ip address 12.0.0.1 255.255.255.252
 ip summary-address eigrp 666 10.1.0.0 255.255.254.0 5

interface Serial0/0/1
 description ISP-2 to CustomerA-R3
 ip vrf forwarding ISP-2
 ip address 13.0.0.1 255.255.255.252
 ip ospf 1 area 666

Vi konfar först upp några VRF-instanser, shared simulerar i detta fallet externa routes/internet. La även till en export-map för att endast exportera 1.1.1.1/32 och 2.2.2.2/32 från Shared till ISP-1 & ISP-2 vrf:erna.

ip vrf ISP-1
 rd 65000:1
 route-target export 65000:1
 route-target import 65000:1

ip vrf ISP-2
 rd 65000:2
 route-target export 65000:2
 route-target import 65000:2

ip vrf Shared
 rd 65000:3
 export map ISP-Loopback-Inject
 route-target export 65000:3
 route-target import 65000:3
 route-target import 65000:1
 route-target import 65000:2

route-map ISP-Loopback-Inject permit 10
 match ip address prefix-list ISP-1
 set extcommunity rt 65000:1 additive

route-map ISP-Loopback-Inject permit 20
 match ip address prefix-list ISP-2
 set extcommunity rt 65000:2 additive

route-map ISP-Loopback-Inject deny 30

IGP

Då vi använder oss av vrf:er måste vi även justera våra IGP-instanser precis som tidigare.

router eigrp 666
 passive-interface default
 no passive-interface Serial0/0/0
 no auto-summary

 address-family ipv4 vrf ISP-1
  network 10.1.0.0 0.0.0.255
  network 10.1.1.0 0.0.0.255
  network 12.0.0.0 0.0.0.3
  no auto-summary
  autonomous-system 666
  exit-address-family
 eigrp router-id 1.1.1.1

router ospf 1 vrf ISP-2
 router-id 2.2.2.2
 log-adjacency-changes
 area 0 range 10.2.0.0 255.255.254.0
 passive-interface default
 no passive-interface Serial0/0/1

BGP

Här stöter vi på ett litet problem då vi endast kan ha en aktiv BGP-instans, dvs skriver vi “router bgp 65001” kan vi ej konfa upp “router bgp 65002” för ISP-2 efteråt.

BGP har ju dock som bekant en hel del roliga funktioner vi kan använda oss av, och i detta fall kan vi lösa problemet med hjälp av “local-as“, “no-prepend” & “replace-as“. Klicka på respektive för mer info, Lostintransit.se har även en läsvärd artikel om detta här!

router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 no auto-summary

 address-family ipv4 vrf Shared
  redistribute connected
  no synchronization
  exit-address-family

 address-family ipv4 vrf ISP-2
  neighbor 13.0.0.2 remote-as 666
  neighbor 13.0.0.2 local-as 65002 no-prepend replace-as
  neighbor 13.0.0.2 activate
  neighbor 13.0.0.2 default-originate
  no synchronization
  bgp router-id 2.2.2.2
  network 10.2.0.0 mask 255.255.255.0
  network 10.2.1.0 mask 255.255.255.0
  aggregate-address 10.2.0.0 255.255.254.0 summary-only
  exit-address-family

 address-family ipv4 vrf ISP-1
  neighbor 12.0.0.2 remote-as 666
  neighbor 12.0.0.2 local-as 65001 no-prepend replace-as
  neighbor 12.0.0.2 activate
  neighbor 12.0.0.2 default-originate
  no synchronization
  bgp router-id 1.1.1.1
  network 10.1.0.0 mask 255.255.255.0
  network 10.1.1.0 mask 255.255.255.0
  aggregate-address 10.1.0.0 255.255.254.0 summary-only
  exit-address-family

Vilket ger följande resultat:

R1#sh ip bgp neighbors 12.0.0.1
 BGP neighbor is 12.0.0.1, remote AS 65001, external link
 BGP version 4, remote router ID 1.1.1.1
 BGP state = Established, up for 00:45:25
 Last read 00:00:16, last write 00:00:31, hold time is 180, keepalive interval is 60 seconds

R3#sh ip bgp neighbors 13.0.0.1
 BGP neighbor is 13.0.0.1, remote AS 65002, external link
 BGP version 4, remote router ID 2.2.2.2
 BGP state = Established, up for 00:46:18
 Last read 00:00:05, last write 00:00:21, hold time is 180, keepalive interval is 60 seconds

R2#sh ip bgp vpnv4 vrf ISP-1
 BGP table version is 60, local router ID is 1.1.1.1
 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
 Origin codes: i - IGP, e - EGP, ? - incomplete
 Network Next Hop Metric LocPrf Weight Path
 Route Distinguisher: 65000:1 (default for vrf ISP-1) VRF Router ID 1.1.1.1
 *> 1.1.1.1/32 0.0.0.0 0 32768 ?
 *> 2.2.2.2/32 12.0.0.2 0 666 65002 ?
 s> 10.1.0.0/24 0.0.0.0 0 32768 i
 r> 10.1.0.0/23 0.0.0.0 32768 i
 s> 10.1.1.0/24 0.0.0.0 0 32768 i
 *> 10.2.0.0/23 12.0.0.2 0 666 65002 i
 *> 13.37.0.0/16 0.0.0.0 0 32768 ?
 *> 172.16.0.0 12.0.0.2 28416 0 666 i
 *> 172.32.0.0/23 12.0.0.2 128256 0 666 i

R2#sh ip bgp vpnv4 vrf ISP-1
 BGP table version is 60, local router ID is 1.1.1.1
 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
 Origin codes: i - IGP, e - EGP, ? - incomplete
 Network Next Hop Metric LocPrf Weight Path
 Route Distinguisher: 65000:1 (default for vrf ISP-1) VRF Router ID 1.1.1.1
 *> 1.1.1.1/32 0.0.0.0 0 32768 ?
 *> 2.2.2.2/32 12.0.0.2 0 666 65002 ?
 s> 10.1.0.0/24 0.0.0.0 0 32768 i
 r> 10.1.0.0/23 0.0.0.0 32768 i
 s> 10.1.1.0/24 0.0.0.0 0 32768 i
 *> 10.2.0.0/23 12.0.0.2 0 666 65002 i
 *> 13.37.0.0/16 0.0.0.0 0 32768 ?
 *> 172.16.0.0 12.0.0.2 28416 0 666 i
 *> 172.32.0.0/23 12.0.0.2 128256 0 666 i

Vi kan även verifiera att vår transit fungerar som önskat, ISP-1 har följande information för 2.2.2.2/32 som ligger på samma router men under ISP-2s VRF.

R2#sh ip bgp vpnv4 vrf ISP-1 2.2.2.2/32
 BGP routing table entry for 65000:1:2.2.2.2/32, version 50
 Paths: (1 available, best #1, table ISP-1)
 Not advertised to any peer
 666 65002
 12.0.0.2 from 12.0.0.2 (172.16.99.11)
 Origin incomplete, localpref 100, valid, external, best
 Extended Community: RT:65000:1
 mpls labels in/out 31/nolabel

Vackert! VRF-Lite ger oss ett enkelt sätt att segmentera upp en router om vi exempelvis måste separera två avdelningar från varandra som ansluter till en och samma router. Fler läsvärda artiklar om detta finns här:

http://packetlife.net/blog/2009/apr/30/intro-vrf-lite/

Inter-VRF routing using VRF-lite

MPLS & MP-BGP Del 2

Jonas CollénBGP

Tänkte fortsätta på det tidigare inlägget där vi satte upp ett core-nät med MPLS & MP-BGP, och visa ett simplet exempel på hur vi installerar två kundsiter som kopplas samman via VPN (VRF) för att utbyta dynamisk routing.

Customer-MPLS

Företaget använder sig av OSPF internt där varje regionalkontor placeras i en egen area (i detta fall 461), och upplänken mot PE/Core i area 0.

NL PE KistaRed

Vi skapar först en VRF-instans som är unik för kunden, i detta fall vrf LIGHT med “route distinguisher” till 300:10. Routes märkta med just 300:10 importeras till denna routers vrf-instans (LIGHT) samtidigt som vi exporterar lokala vrf-routes till samma instans för annonsering vidare till övriga PEs.

ip vrf LIGHT
 rd 300:10
 route-target both 300:10

Konfigurera upp lämpligt interface med tillhörande VRF:

interface s0/3
 description LIGHT-Internal Kista
 ip vrf forwarding LIGHT
 ip address 37.46.2.1 255.255.255.252

Då PE-routern ska peera med kundens OSPF-instans krävs lite av en specialare, tänk på att vi redan kör OSPF som IGP inom core-nätet och där vill vi absolut ej ha in några routes från denna kund. Vi kan däremot köra flera samtidiga OSPF-instanser som vi sedan placerar i olika vrf:er, i detta fall en för vrf LIGHT. Redistribution krävs mellan OSPF & MP-BGP instansen för att KistaRed ska annonsera andra vrf LIGHT OSPF-routes den lär sig via just MP-BGP från andra PEs.

router ospf 310 vrf LIGHT 
 router-id 37.46.2.1
 auto-cost reference-bandwidth 20000000
 redistribute bgp 46 subnets
 network 37.46.2.0 0.0.0.3 area 0

Vi skapar sedan en MP-BGP instans för kunden, samma sak här – använd redistribution:

router bgp 46
 address-family ipv4 vrf LIGHT
  redistribute ospf 310 vrf LIGHT
  no synchronization
  exit-address-family

NL PE KistaRed

ip vrf LIGHT
 rd 300:10
 route-target both 300:10

interface s0/3
 description LIGHT-Internal Kiruna
 ip vrf forwarding LIGHT
 ip address 37.46.2.5 255.255.255.252

router ospf 310 vrf LIGHT
 router-id 37.46.2.5
 auto-cost reference-bandwidth 20000000
 redistribute bgp 46 subnets
 network 37.46.2.4 0.0.0.3 area 0

router bgp 46
 address-family ipv4 vrf LIGHT
  redistribute ospf 310 vrf LIGHT
  no synchronization
  exit-address-family

NLKista-Edge

Edge-routern behöver sedan endast konfigureras med OSPF-instansen för att det ska hoppa igång.

!Downlink to CustomerLAN, demo with Loopback
interface Loopback0
 description to CustomerLAN Kista
 ip address 10.46.0.1 255.255.254.0
 ip ospf network point-to-point

interface Serial1/3
 description to ISP-NL-KistaRed
 ip address 37.46.2.2 255.255.255.252

interface Serial1/2
 description to ISP-NL-KistaBlue
 ip address 37.46.2.6 255.255.255.252

router ospf 310
 router-id 37.46.128.1
 auto-cost reference-bandwidth 20000000
 network 37.46.2.0 0.0.0.3 area 0 
 network 37.46.2.4 0.0.0.3 area 0
 network 10.46.0.0 0.0.63.255 area 461

Verifikation Customer-MPLSKiruna Ett till kontor sattes upp i Kiruna med identisk konfig för att kunna köra lite tester. Ping från Kista- till Kiruna-kontoret:

NL-Office-Kista#ping 10.46.64.1 source lo0
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/43/60 ms

Traceroute mellan Kista- & Kiruna-kontoret:

NL-Office-Kista#traceroute 10.46.64.1 source lo0
Type escape sequence to abort.
Tracing the route to 10.46.64.1
1 37.46.2.5 36 msec
37.46.2.1 20 msec
37.46.2.5 28 msec
2 37.46.2.9 44 msec
37.46.2.13 48 msec
37.46.2.9 60 msec
3 37.46.2.14 100 msec
37.46.2.10 72 msec
37.46.2.14 24 msec

Routing-tabellen för Kista-kontoret:

NL-Office-Kista#sh ip route | beg Gateway
37.0.0.0/30 is subnetted, 4 subnets
O IA 37.46.2.8 [110/65] via 37.46.2.5, 00:02:54, Serial1/2
[110/65] via 37.46.2.1, 00:02:54, Serial1/3
O IA 37.46.2.12 [110/65] via 37.46.2.5, 00:02:54, Serial1/2
[110/65] via 37.46.2.1, 00:02:54, Serial1/3
C 37.46.2.0 is directly connected, Serial1/3
C 37.46.2.4 is directly connected, Serial1/2
10.0.0.0/18 is subnetted, 2 subnets
C 10.46.0.0 is directly connected, Loopback0
O IA 10.46.64.0 [110/129] via 37.46.2.5, 00:01:56, Serial1/2
[110/129] via 37.46.2.1, 00:01:56, Serial1/3

PE

KistaBlue#sh ip bgp vpnv4 vrf LIGHT
BGP table version is 15, local router ID is 37.46.255.102
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 300:10 (default for vrf LIGHT)
* i10.46.0.0/23 37.46.255.101 65 100 0 ?
*> 37.46.2.6 65 32768 ?
* i10.46.2.0/23 37.46.255.103 65 100 0 ?
*>i 37.46.255.104 65 100 0 ?
* i37.46.2.0/30 37.46.255.101 0 100 0 ?
*> 37.46.2.6 128 32768 ?
* i37.46.2.4/30 37.46.255.101 128 100 0 ?
*> 0.0.0.0 0 32768 ?
*>i37.46.2.8/30 37.46.255.103 0 100 0 ?
* i 37.46.255.104 128 100 0 ?
* i37.46.2.12/30 37.46.255.103 128 100 0 ?
*>i 37.46.255.104 0 100 0 ?

KistaBlue#sh ip route vrf LIGHT | beg Gateway
Gateway of last resort is not set
37.0.0.0/30 is subnetted, 4 subnets
B 37.46.2.8 [200/0] via 37.46.255.103, 00:22:17
B 37.46.2.12 [200/0] via 37.46.255.104, 00:22:32
O 37.46.2.0 [110/128] via 37.46.2.6, 00:22:59, Serial0/3
C 37.46.2.4 is directly connected, Serial0/3
 10.0.0.0/23 is subnetted, 2 subnets
O IA 10.46.0.0 [110/65] via 37.46.2.6, 00:22:59, Serial0/3
B 10.46.2.0 [200/65] via 37.46.255.104, 00:22:32

Svårare än så är det faktiskt inte. 🙂

CCDP – MPLS & MP-BGP

Jonas CollénBGP

Är mitt uppe i tentavecka så finns inte direkt någon tid att posta här just nu tyvärr, räknar med att vara “back on track” till nästa vecka igen. Tänkte hur som helst ta och skriva ett kortare inlägg om implementeringen av MPLS & MP-BGP för en mindre ISP i projektet som nämndes i gårdagens inlägg.

projekt-light

Mitt uppdrag var att föreslå förbättringar och ta fram detaljerade designförslag för både core-nät och internkontor utifrån ovanstående topologi samt följande information:

  • Agerar ISP åt börsnoterade företag
  • IPv4 37.0.0.0/8
  • IPv6 2001:beef::/16
  • 1000st anställda
    • Prag 500st (Huvudkontor)
    • Brno 300st
    • Plzeñ 50st
    • Cern (Schweiz) 25st
    • Amsterdam 25st
    • Birmingham 25st
    • Kista 25st
    • Santa Cruz de Tenerife 25st
    • Kiruna 25st
  • Består av dotterbolagen:
    • NetherLight
    • CanarieLight
    • NorthernLight
    • UKLight
  • Önskar informativa övervakningsmöjligheter för kundens länkar
  • Önskar erbjuda en kostnadseffektiv tjänst med QoS
  • Kontoren i Plzeñ & Brno erbjuder även Datacenter & Storage-lösningar

IGP

igp

Då det befintliga core-nätet helt saknar redundans (exempelvis endast en switch utplacerad i Amsterdam) föreslogs istället  ovanstående uppgradering av nätet. Core-nätet byggs upp i par för respektive land/ort (rött & blått), där varje nod förutom en direktlänk till sin överliggande motsvarighet även har en länk till sin ”core-partner”.

Som underliggande IGP-protokoll till BGP användes OSPF #300 inom core-nätet. Detta då både OSPF & BGP tillskillnad från EIGRP är en öppen standard och tillåter företaget att använda en mixed-vendor lösning.

OSPF låter oss även segmentera nätet i enlighet med de confederations som tagits fram för BGP, med undantaget att CERN här flyttades till en egen area för att hålla Area 0 så liten som möjligt.

Summering utförs i varje ABR, vilket blir väldigt enkelt tack vare att ip-adresseringen följer samma numrering som confederations & area-nummer (ex. NorthernLight 37.46.x.x/16). Reference-bandwith har även justerats till 2 Terabit då OSPF per default ej ser skillnad på länkar över 100Mbit.

Konfigurationsexempel – NorthernLight KistaBlue

router ospf 300
 router-id 37.46.255.102
 log-adjacency-changes
 passive-interface default
 no passive interface Serial0/1
 no passive interface Serial0/2
 no passive interface FastEthernet0/0
 no passive interface FastEthernet0/1
 auto-cost reference-bandwidth 20000000
 area 46 range 37.46.0.0 255.255.0.0
 network 37.31.46.4 0.0.0.3 area 0
 network 37.46.0.0 0.0.255.255 area 46

BGP

BGP Confederations används för att segmentera nätet och minska antalet IBGP neighbor-relationer som annars skulle behövas, detta då IBGP kräver en full-mesh relation för att utbyta routinguppdateringar (förutsatt att de ej använder sig av route-reflectors). Nedan följer ett konfigurationsexempel för confederations i NetherLights PEs, exempelvis AmsterdamRed.

router bgp 31
 bgp confederation identifier 300
 bgp confederation peers 34 42 44 46

Inom varje confederation används sedan full-mesh IBGP peering, förutom i Czechlight där antalet BGP Speakers var något fler än övriga länder och nätet kompletterades därför även med Route-Reflectors.  

czechlights-bgp

PE PragRed

router bgp 42
 no synchronization
 bgp router-id 37.42.63.101
 bgp cluster-id 1
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 31 
 neighbor czechlight peer-group
 neighbor czechlight remote-as 42
 neighbor czechlight update-source Loopback0
 neighbor czechlight route-reflector-client
 neighbor 37.31.42.1 remote-as 31
 neighbor 37.31.42.1 description AmsterdamRed
 neighbor 37.42.63.102 peer-group czechlight
 neighbor 37.42.63.102 description PragBlue
 neighbor 37.42.127.101 peer-group czechlight
 neighbor 37.42.127.101 description PlzenRed
 neighbor 37.42.127.102 peer-group czechlight
 neighbor 37.42.127.102 description PlzenBlue
 neighbor 37.42.191.101 peer-group czechlight
 neighbor 37.42.191.101 description BrnoRed
 neighbor 37.42.191.102 peer-group czechlight
 neighbor 37.42.191.102 description BrnoBlue
 no auto-summary

MPLS

För att sätta upp MPLS användes följande konfig, vi behöver endast peera mot andra PEs över vpnv4 (vilket dock i detta nät blir varje core-router).

PE AmsterdamRed
mpls label protocol ldp
interface FastEthernet0/0
 description to AmsterdamBlue
 ip address 37.31.255.1 255.255.255.252
 mpls ip

interface Serial0/0
 description to PragRed
 ip address 37.31.42.1 255.255.255.252 
 mpls ip

interface FastEthernet0/1
 description to ISP-Peer

  interface FastEthernet0/1.10
   encapsulation dot1Q 1 native
   ip vrf forwarding Internet_Access
   ip address 37.31.255.5 255.255.255.252

interface Serial0/1
 description to KistaRed
 ip address 37.31.46.1 255.255.255.252
 mpls ip

ip bgp-community new-format

router bgp 31
 no synchronization
 bgp router-id 37.31.255.1
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 32 42 44 46 
 neighbor 37.31.42.2 remote-as 42
 neighbor 37.31.42.2 description PragRed
 neighbor 37.31.46.2 remote-as 46
 neighbor 37.31.46.2 description KistaRed
 neighbor 37.31.255.102 remote-as 31
 neighbor 37.31.255.102 description AmsterdamBlue
 neighbor 37.31.255.102 update-source Loopback0
 no auto-summary

  address-family vpnv4
   neighbor 37.31.42.2 activate
   neighbor 37.31.42.2 send-community both
   neighbor 37.31.46.2 activate
   neighbor 37.31.46.2 send-community both
   neighbor 37.31.255.102 activate
   neighbor 37.31.255.102 send-community both
   exit-address-family

mpls ldp router-id Loopback0 force

VRFs

Följande VRFs sattes upp tillsvidare:

  • 300:10 Light-Internal  
  • 300:20 Light-Datacenter 
  • 300:30 Light-Storage  
  • 300:300 Internet_Access 
    • Här importeras samtliga kund-VRF:er som önskar Internet-access och innehåller full BGP routing-table, kräver att kunden har en publik ip-adress och annonseras till andra peering-partners
  • 300:301 Internet_Defaultroute 
    • Innehåller endast en default-route ut mot internet (till VRF Internet_Access). Används för kunder som ej använder BGP och importeras in i kundens VRF (vi vill inte exportera full bgp-table till varje VRF-instans)

Konfigexempel:

ip vrf Internet_Access
 rd 300:300
 export map DEFAULT-INJECT
 route-target import 300:300
 route-target import 300:310
ip vrf Internet_Defaultroute
 rd 300:301
 route-target export 300:301
 route-target import 300:301
ip vrf LIGHT
 rd 300:10
 route-target export 300:10
 route-target import 300:10

För att exportera default-routen från Internet_Access till VRF: 300:301 användes en export-map (route-map).

ip prefix-list DEFAULT-ROUTE seq 5 permit 0.0.0.0/0
route-map DEFAULT-INJECT permit 10
 match ip address prefix-list DEFAULT-ROUTE
 set extcommunity rt 300:301
route-map DEFAULT-INJECT permit 20
 set extcommunity rt 300:300

Vill vi sedan ge en kund internetaccess exporterar vi deras VRF till 300:300 och importerar 300:301 enligt följande:

ip vrf Cust-FortiAB
 rd 300:1001
 route-target export 300:1001
 route-target export 300:300
 route-target import 300:1001
 route-target import 300:301

För att få in full bgp-table till VRF: Internet_Access behöver vi endast peera mot andra ISPs över den specifika VRF:en. För att säkerställa att varken våra peering-partner eller Lightkoncernen och dess externa kunder av misstag skulle börja annonsera privata adresser används prefixlistor för att filtrera routing-uppdateringar både in & ut.

interface FastEthernet0/1.10
 description to ISP-1
 encapsulation dot1Q 1 native
 ip vrf forwarding Internet_Access
 ip address 37.31.255.5 255.255.255.252

ip prefix-list rfc1918 deny 0.0.0.0/8 le 32
ip prefix-list rfc1918 deny 10.0.0.0/8 le 32
ip prefix-list rfc1918 deny 127.0.0.0/8 le 32
ip prefix-list rfc1918 deny 169.254.0.0/16 le 32
ip prefix-list rfc1918 deny 172.16.0.0/12 le 32
ip prefix-list rfc1918 deny 192.0.2.0.0/24 le 32
ip prefix-list rfc1918 deny 192.168.0.0/16 le 32
ip prefix-list rfc1918 deny 224.0.0.0/3 le 32
ip prefix-list rfc1918 permit 0.0.0.0/0 le 32

router bgp 31
 address-family ipv4 vrf Internet_Access
  neighbor 37.31.255.6 remote-as 100
  neighbor 37.31.255.6 activate
  neighbor 37.31.255.6 prefix-list rfc1918 in
  neighbor 37.31.255.6 prefix-list rfc1918 out
  aggregate-address 37.0.0.0 255.0.0.0 summary-only
  exit-address-family

Vilket ger följande routing-tabell på ISP-1:

ISP-1#sh ip route bgp
 200.200.200.0/32 is subnetted, 1 subnets
 B 200.200.200.200 [20/0] via 37.31.255.5, 00:02:59
 217.21.0.0/26 is subnetted, 2 subnets
 B 217.21.0.64 [20/0] via 37.31.255.5, 00:02:59
 B 217.21.0.0 [20/0] via 37.31.255.5, 00:02:59
 37.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
 B 37.0.0.0/8 [20/0] via 37.31.255.5, 00:00:03

Blev tyvärr en väldigt kort inlägg det här men har inte riktigt tid just nu att gå på djupet och förklara mer ingående, får ta nya tag efter nästa veckas tentor. 🙂

BGP – Advanced BGP Lab, del 3

Jonas CollénBGP

Fortsättning från tidigare inlägg om GNS3Vaults Advanced BGP-lab som finns att läsa här & här.

Path Modifications

bgp-advanced-lab

  • 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.

Vi har just nu full konvergens och kan pinga samtliga loopbacks i vår topologi.

1. 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.

Tar vi en titt på R4 först kan vi se följande:

R4#sh ip bgp
BGP table version is 34, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 1.1.1.0/24 2.2.2.2 0 100 i
*> 3.3.3.3 0 100 i

Den föredrar just nu vägen via R3 för att nå R1s loopback 1.1.1.1. Då vi endast fick ändra konfigurationen på R3 för att styra om trafiken behöver vi använda oss av något Path Attribute. Varken Weight eller Local Preference kan ju hjälpa oss i detta fall då R4 ligger i ett eget AS. MED eller AS-Path Prepending däremot!

R3(config)#ip prefix-list R1-Loopback permit 1.1.1.0/24
R3(config)#route-map R1-Loopback-MED permit 10
R3(config-route-map)#match ip add prefix-list R1-Loopback
R3(config-route-map)#set as-path prepend 100 100
R3(config-route-map)#route-map R1-Loopback-MED permit 20
R3(config-route-map)#exit
R3(config)#router bgp 100
R3(config-router)#neighbor 4.4.4.4 route-map R1-Loopback-MED out

R4#sh ip bgp 1.1.1.0/24
BGP routing table entry for 1.1.1.0/24, version 35
Paths: (2 available, best #2, table Default-IP-Routing-Table)
 Advertised to update-groups:
 1 2
 100 100 100
 3.3.3.3 from 3.3.3.3 (3.3.3.3)
 Origin IGP, localpref 100, valid, external
 100
 2.2.2.2 from 2.2.2.2 (2.2.2.2)
 Origin IGP, localpref 100, valid, external, best

2. 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.

R1(config)#int lo1
R1(config-if)#ip add 172.16.1.1 255.255.255.0
R1(config)#router rip
R1(config-router)#network 172.16.1.0

R4#sh ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 38
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
 1 2
 100
 3.3.3.3 from 3.3.3.3 (3.3.3.3)
 Origin IGP, localpref 100, valid, external
 100
 2.2.2.2 from 2.2.2.2 (2.2.2.2)
 Origin IGP, localpref 100, valid, external, best

I detta fall behöver vi endast ändra BGP lokalt, och bör således använda oss av “Weight”.

R4(config)#ip prefix-list R1-Loopback2 permit 172.16.1.0/24
R4(config)#route-map R1-Loopback2-Weight permit 10
R4(config-route-map)#match ip add prefix-list R1-Loopback2
R4(config-route-map)#set weight 10
R4(config-route-map)#route-map R1-Loopback2-Weight permit 20
R4(config-route-map)#exit
R4(config)#router bgp 10
R4(config-router)#neighbor 3.3.3.3 route-map R1-Loopback2-Weight in

R4#sh ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 39
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
 Advertised to update-groups:
 1 2
 100
 3.3.3.3 from 3.3.3.3 (3.3.3.3)
 Origin IGP, localpref 100, weight 10, valid, external, best
 100
 2.2.2.2 from 2.2.2.2 (2.2.2.2)
 Origin IGP, localpref 100, valid, external

3. When R6 sends a ping towards the loopback interface on R11 it should go through AS300.

Just nu tar R6 vägen via R7->R11.

R6#traceroute 11.11.11.11
Type escape sequence to abort.
Tracing the route to 11.11.11.11
1 192.168.67.7 24 msec 28 msec 68 msec
 2 192.168.117.11 56 msec 72 msec *

Känns som vi kan använda oss av Weight här med då local preference även hade annonserats till R7.

R6(config)#ip prefix-list R11-Loopback permit 11.11.11.0/24
R6(config)#route-map R11-Loopback-Weight permit 10
R6(config-route-map)#match ip add prefix-list R11-Loopback
R6(config-route-map)#set weight 10
R6(config-route-map)#route-map R11-Loopback-Weight permit 20
R6(config-route-map)#exit
R6(config-router)#neighbor 5.5.5.5 route-map R11-Loopback-Weight in

R6#sh ip bgp 11.11.11.0/24
BGP routing table entry for 11.11.11.0/24, version 1007
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
 1 2
 300 400
 5.5.5.5 from 5.5.5.5 (5.5.5.5)
 Origin IGP, localpref 100, weight 10, valid, external, best
 400
 7.7.7.7 (metric 156160) from 7.7.7.7 (7.7.7.7)
 Origin IGP, metric 0, localpref 100, valid, internal
 300 400
 4.4.4.4 from 4.4.4.4 (4.4.4.4)
 Origin IGP, localpref 100, valid, external

4. R7 should prefer the path through R11 for all external networks except for 172.16.1.1.

Vi kan använda oss av Weight här med men själva tillvägagångssättet blir lite annorlunda nu när vi vill matcha allt utom just 172.16.1.0/24-nätet.

R7(config)#ip prefix-list R1-Loopback-R11 permit 172.16.1.0/24
R7(config)#route-map RM-Redirect-to-R11 permit 10
R7(config-route-map)#match ip address prefix-list R1-Loopback-R11
R7(config-route-map)#route-map RM-Redirect-to-R11 permit 20
R7(config-route-map)#set weight 20
R7(config-route-map)#exit
R7(config)#router bgp 200
R7(config-router)#neighbor 11.11.11.11 route-map RM-Redirect-to-R11 in

Vi sätter helt enkelt weight för alla nät som inte matchas i vår första sequence, dvs allt utom 172.16.1.0/24.

Jämför vi 172.16.1.0/24 med 1.1.1.0/24 kan vi se följande:

R7#sh ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 12
Paths: (2 available, best #2, table Default-IP-Routing-Table)
 Advertised to update-groups:
 1
 400 300 100
 11.11.11.11 from 11.11.11.11 (11.11.11.11)
 Origin IGP, localpref 100, valid, external
 300 100
 6.6.6.6 (metric 156160) from 6.6.6.6 (6.6.6.6)
 Origin IGP, metric 0, localpref 100, valid, internal, best

R7#sh ip bgp 1.1.1.0/24
BGP routing table entry for 1.1.1.0/24, version 43
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
 2
 400 300 100
 11.11.11.11 from 11.11.11.11 (11.11.11.11)
 Origin IGP, localpref 100, weight 20, valid, external, best
 300 100
 6.6.6.6 (metric 156160) from 6.6.6.6 (6.6.6.6)
 Origin IGP, metric 0, localpref 100, valid, internal

5. 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.

Här behöver vi istället filtrera bort routing-uppdateringar för 172.16.1.0/24 i R4 & R5 mot R6. Då vi redan har en prefix-lista konfad på R4 som matchar 172.16.1.0/24-nätet återanvänder vi den istället.

R4(config)#do sh ip prefix-list
ip prefix-list R1-Loopback2: 1 entries
 seq 5 permit 172.16.1.0/24
R4(config)#route-map AS200 deny 10
R4(config-route-map)#match ip add prefix-list R1-Loopback2
R4(config-route-map)#route-map AS200 permit 20
R4(config-route-map)#exit
R4(config)#router bgp 10
R4(config-router)#neighbor 6.6.6.6 route-map AS200 out

Jag blir dock osäker på hur vi ska blockera AS200 från att lära sig om nätet via As400 istället (utan att lägga in specifik filtrering där också)?

R6#sh ip bgp 172.16.1.0/24
BGP routing table entry for 172.16.1.0/24, version 1015
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
 2
 400 300 100
 7.7.7.7 (metric 156160) from 7.7.7.7 (7.7.7.7)
 Origin IGP, metric 0, localpref 100, valid, internal, best

Som synes tar den nu istället vägen via R7 -> AS400 R11  -> R10-> AS300 R9..  Jag skulle vilja säga att vi ej har någon möjlighet att påverka vad ett annat AS  i sin tur gör med näten vi annonserar till  dem. För att lösa labben hade jag lagt in samma filter på R11 mot R7 också.

Då var vi tillslut klara med den avancerade labben, gick trots allt väldigt smärtfritt skönt nog. 🙂 MDH har släppt slutprojektet i CCNP-kursen nu så eventuella inlägg närmaste tiden kommer troligtvis handla om det.

BGP – Advanced BGP Lab, del 2

Jonas CollénBGP

EBGP & Redistribution

  • Configure EBGP between AS-peers
  • 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.

Detta blir en fortsättning på gårdagens lab som finns att läsa här. Kom ihåg att varje BGP Speaker kräver en specifik route till respektive neighbor, en default-route räcker ej. Då vi endast annonserar Loopbacks inom IGPs/AS (förutom sub-AS10 & 20/confederation) behöver vi även sätta upp statiska routes. Glöm inte heller ebgp-multihop den här gången… 🙂

EBGP

R2

router bgp 100
 neighbor 4.4.4.4 remote-as 300
 neighbor 4.4.4.4 ebgp-multihop 255
 neighbor 4.4.4.4 update-source Loopback0
ip route 4.4.4.0 255.255.255.0 192.168.24.4

R3

router bgp 100
 neighbor 4.4.4.4 remote-as 300
 neighbor 4.4.4.4 ebgp-multihop 255
 neighbor 4.4.4.4 update-source Loopback0
ip route 4.4.4.0 255.255.255.0 192.168.34.4

R4

router bgp 10
 neighbor 2.2.2.2 remote-as 100
 neighbor 2.2.2.2 ebgp-multihop 255
 neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 ebgp-multihop 255
 neighbor 3.3.3.3 update-source Loopback0
neighbor 6.6.6.6 remote-as 200
 neighbor 6.6.6.6 ebgp-multihop 2
 neighbor 6.6.6.6 update-source Loopback0
ip route 2.2.2.0 255.255.255.0 192.168.24.2
ip route 3.3.3.0 255.255.255.0 192.168.34.3
ip route 6.6.6.0 255.255.255.0 192.168.46.6

R5

router bgp 10
 neighbor 6.6.6.6 remote-as 200
 neighbor 6.6.6.6 ebgp-multihop 2
 neighbor 6.6.6.6 update-source Loopback0
ip route 6.6.6.0 255.255.255.0 192.168.56.6

EBGP-förhållandet mellan confederation-AS #10 & #20 konfigurerade vi upp i gårdagens inlägg här.

R6

router bgp 200
 neighbor 4.4.4.4 remote-as 300
 neighbor 4.4.4.4 ebgp-multihop 2
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 5.5.5.5 remote-as 300
 neighbor 5.5.5.5 ebgp-multihop 2
 neighbor 5.5.5.5 update-source Loopback0
ip route 4.4.4.0 255.255.255.0 192.168.46.4
 ip route 5.5.5.0 255.255.255.0 192.168.56.5

R7

router bgp 200
 neighbor 11.11.11.11 remote-as 400
 neighbor 11.11.11.11 ebgp-multihop 2
 neighbor 11.11.11.11 update-source Loopback0
ip route 11.11.11.0 255.255.255.0 192.168.117.11

R9

router bgp 20
 neighbor 10.10.10.10 remote-as 400
 neighbor 10.10.10.10 ebgp-multihop 2
 neighbor 10.10.10.10 update-source Loopback0
ip route 10.10.10.0 255.255.255.0 192.168.109.10

R10

router bgp 400
 neighbor 9.9.9.9 remote-as 300
 neighbor 9.9.9.9 ebgp-multihop 2
 neighbor 9.9.9.9 update-source Loopback0
ip route 9.9.9.0 255.255.255.0 192.168.109.9

R11

router bgp 400
 neighbor 7.7.7.7 remote-as 200
 neighbor 7.7.7.7 ebgp-multihop 2
 neighbor 7.7.7.7 update-source Loopback0
ip route 7.7.7.0 255.255.255.0 192.168.117.7

Authentication

Enligt labben behöver vi sätta upp autentisering mellan R7 – R11 med lösenordet “VAULT”.

R7 
 router bgp 200
 neighbor 11.11.11.11 password VAULT

R11
 router bgp 400
 neighbor 7.7.7.7 password VAULT

Redistribution

Nästa steg är att annonsera alla fysiska interface (inkl. loopbacks) in i BGP, vi får ej använda “network”. Enklast bör väl vara att köra redistribute på connected, route-map:en är bara för att göra det lite snyggare och sätta origin till IGP istället för “unknown”.

route-map REDIST_C permit 10
 set origin igp

router bgp x
 redistribute connected route-map REDIST_C

La in ovanstående på samtliga routrar i topologin. Vilket gav följande i R1:

R1#sh ip bgp
 BGP table version is 10, local router ID is 1.1.1.1
 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
 Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
 *> 1.1.1.0/24 0.0.0.0 0 32768 i
 r>i2.2.2.0/24 2.2.2.2 0 100 0 i
 r>i3.3.3.0/24 3.3.3.3 0 100 0 i
 * i4.4.4.0/24 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i5.5.5.0/24 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i6.6.6.0/24 4.4.4.4 0 100 0 300 200 i
 * i 4.4.4.4 0 100 0 300 200 i
 * i7.7.7.0/24 4.4.4.4 0 100 0 300 200 i
 * i 4.4.4.4 0 100 0 300 200 i
 * i8.8.8.0/24 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i9.9.9.0/24 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.12.0 2.2.2.2 0 100 0 i
 *> 0.0.0.0 0 32768 i
 * i192.168.13.0 3.3.3.3 0 100 0 i
 *> 0.0.0.0 0 32768 i
 *>i192.168.24.0 2.2.2.2 0 100 0 i
 *>i192.168.34.0 3.3.3.3 0 100 0 i
 * i192.168.45.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.46.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.56.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.58.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.67.0 4.4.4.4 0 100 0 300 200 i
 * i 4.4.4.4 0 100 0 300 200 i
 * i192.168.89.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.109.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.117.0 4.4.4.4 0 100 0 300 200 i
 * i 4.4.4.4 0 100 0 300 200 i

Som synes är det endast näten inom AS100 den lägger till i routing-tabellen.. Anledningen till detta är rätt enkel, R1 har ingen route till 4.4.4.4 (next-hop). Enklaste lösningen är väl att konfigurera next-hop-self på våra border-routers istället.

R2

router bgp 100
 neighbor 1.1.1.1 next-hop-self

R3

router bgp 100
 neighbor 1.1.1.1 next-hop-self

Och så vidare, behöver göra detta på varje border-router vars neighbor saknar egna routes för loopbacks i andra AS.

TCL Verifiering

tclsh
foreach address {
1.1.1.1
2.2.2.2
3.3.3.3
4.4.4.4
5.5.5.5
6.6.6.6
7.7.7.7
8.8.8.8
9.9.9.9
10.10.10.10
11.11.11.11
} { ping $address repeat 1 }

R1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 128/128/128 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 56/56/56 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 120/120/120 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 140/140/140 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 144/144/144 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 192/192/192 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 144/144/144 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 216/216/216 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 252/252/252 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 324/324/324 ms

R5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 212/212/212 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 104/104/104 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 132/132/132 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 60/60/60 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 44/44/44 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 100/100/100 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 32/32/32 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 100/100/100 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 100/100/100 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 184/184/184 ms

R11

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 308/308/308 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 216/216/216 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 216/216/216 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 280/280/280 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 148/148/148 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 68/68/68 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 36/36/36 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 152/152/152 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 80/80/80 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 56/56/56 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms

Vackert! Nu är det bara den roliga biten kvar med “path modifications” men det får allt vänta till nästa vecka då det är party ikväll. 🙂

BGP – Advanced BGP Lab, del 1

Jonas CollénBGP

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!

TSHOOT – Part I, Internet & BGP

Jonas CollénBGP

bgp-internet

Tänkte fokusera på att sätta upp ovanstående del i detta inlägg vilket väl förhoppningsvis ska vara ganska basic.

Kan väl börja med webservern.

Webserver(config)#int fa0/0
Webserver(config-if)#ip add 209.65.200.241 255.255.255.248
Webserver(config-if)#no shut
Webserver(config-if)#exit
Webserver(config)#no ip routing
Webserver(config)#ip default-gateway 209.65.200.242

ISP:n har vi lite mer att fixa med.

ISP(config)#inte fa0/0
ISP(config-if)#ip add 209.65.200.242 255.255.255.248
ISP(config-if)#no shut
ISP(config-if)#descrip Webserver
ISP(config-if)#inte fa0/1
ISP(config-if)#ip add 209.65.200.226 255.255.255.252
ISP(config-if)#no shut
ISP(config-if)#descrip to C
ISP(config-if)#descrip to CustomerA
ISP(config-if)#exit

ISP(config)#router bgp 65002
ISP(config-router)#neighbor 209.65.200.225 remote-as 65001
ISP(config-router)#neighbor 209.65.200.225 shutdown
ISP(config-router)#neighbor 209.65.200.225 description CustomerA
ISP(config-router)#neighbor 209.65.200.225 default-originate
ISP(config-router)#redistribute connected route-map SetOrigin
ISP(config-router)#exit

ISP(config)#access-list 1 permit 209.65.200.240
ISP(config)route-map SetOrigin permit 10
ISP(config-route-map)#match ip address 1
ISP(config-route-map)#set origin igp
ISP(config-route-map)#route-map SetOrigin permit 20
ISP(config-route-map)#exit
ISP(config)#

Att sätta igp origin är väl egentligen inte nödvändigt men det blir åtminstone snyggare än att ha ett “?”. 😉

R1

R1(config)#int fa0/1
R1(config-if)#ip add 209.65.200.225 255.255.255.248
R1(config-if)#no shut
R1(config-if)#description to ISP
R1(config-if)#exit

R1(config)#router bgp 65001
R1(config-router)#neighbor 209.65.200.226 remote-as 65002
R1(config-router)#neighbor 209.65.200.226 description to ISP

Vi kan nu testa ta upp BGP-sessionen på ISPn och förhoppningsvis ska vi väl ha full connectivity mellan Webservern och R1 efter det.

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route
Gateway of last resort is 209.65.200.226 to network 0.0.0.0
209.65.200.0/24 is variably subnetted, 3 subnets, 2 masks
B 209.65.200.240/29 [20/0] via 209.65.200.226, 00:03:13
B 209.65.200.224/30 [20/0] via 209.65.200.226, 00:03:13
C 209.65.200.224/29 is directly connected, FastEthernet0/1
B* 0.0.0.0/0 [20/0] via 209.65.200.226, 00:00:02

Verifiering:

R1#sh ip bgp
BGP table version is 4, local router ID is 209.65.200.225
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 209.65.200.226 0 0 65002 i
*> 209.65.200.224/30
 209.65.200.226 0 0 65002 ?
*> 209.65.200.240/29
 209.65.200.226 0 0 65002 i
R1#ping 209.65.200.241
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.65.200.241, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/40/64 ms

IPv6 – BGP Dual stack

Jonas CollénBGP

Dags för ett inlägg om implementering av BGP i IPv6. Detta ingår dock ej i CCIEs Blueprint så finns väl egentligen ingen anledning lära sig detta, men tycker ändå det var intressant så vi kör på.. 🙂

ipv6-bgp

Tänkte göra ett försök att konfigurera IPv6-dualstack i ovanstående topologi som vi använde i inlägget om iBGP & Transitareas.

IPv4-stacken är redan konfat, R5 annonserar prefixet 5.5.5.0/24 och R6 annonserar 6.6.6.0/24, AS500 används endast som en transit-area,

R5#sh ip bgp
BGP table version is 3, local router ID is 5.5.5.5
 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
 Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
 *> 5.5.5.0/24 0.0.0.0 0 32768 i
 *> 6.6.6.0/24 172.16.51.1 0 500 200 i
R6#sh ip bgp
 BGP table version is 3, local router ID is 6.6.6.6
 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
 Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
 *> 5.5.5.0/24 172.16.36.3 0 500 100 i
 *> 6.6.6.0/24 0.0.0.0 0 32768 i

Vi har full-mesh iBGP-peering inom AS500 och peerar mot Loopbacks & next-hop-self, För mer information om hur vi konfat upp detta se den tidigare posten om iBGP jag länkade till.

R5 – eBGP

Låt oss börja med R5:

ipv6 unicast-routing
 ipv6 route 2001:DB8:CC1E:100::/64 Null0
int fa0/0
 ipv6 address FE80::5 link-local
 ipv6 address 2001:DB8:CC1E:51::5/64
router bgp 100
 bgp router-id 5.5.5.5
 neighbor 2001:DB8:CC1E:51::1 remote-as 500

So far inget nytt, dock behöver vi även aktivera IPv6-funktionalitet i BGP-processen och annonsera vårat prefix. Observera att vi gick in i den vanliga bgp-processen, till skillnad mot ex. OSPF/EIGRP där vi skriver “ipv6 router ospf n”.

R5(config-router)#address-family ipv6
 R5(config-router-af)#neighbor 2001:DB8:CC1E:51::1 activate
 R5(config-router-af)#network 2001:DB8:CC1E:100::/64

R6 – eBGP

ipv6 unicast-routing
 ipv6 route 2001:DB8:CC1E:200::/64 Null0
 !
 interface FastEthernet0/0
 ipv6 address FE80::6 link-local
 ipv6 address 2001:DB8:CC1E:36::6/64
 !
 router bgp 200
 bgp router-id 6.6.6.6
 neighbor 2001:DB8:CC1E:36::3 remote-as 500
 !
 address-family ipv6
 neighbor 2001:DB8:CC1E:36::3 activate
 network 2001:DB8:CC1E:200::/64

Transit-area

R1

Här har vi lite mer att konfigurera. R1s BGP-konfig ser just nu ut enligt följande:

R1#sh run | sec bgp
 redistribute bgp 500
 router bgp 500
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 500
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 neighbor 3.3.3.3 remote-as 500
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 next-hop-self
 neighbor 4.4.4.4 remote-as 500
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 4.4.4.4 next-hop-self
 neighbor 172.16.51.5 remote-as 100
 no auto-summary

Men med våra nyvunna BGP-kunskaper från tidigare inlägg kan vi väl ta och rensa upp detta lite först via peer-groups.

router bgp 500
 neighbor iBGP peer-group
 neighbor iBGP remote-as 500
 neighbor iBGP update-source Loopback0
 neighbor iBGP next-hop-self
 neighbor 2.2.2.2 peer-group iBGP
 neighbor 3.3.3.3 peer-group iBGP
 neighbor 4.4.4.4 peer-group iBGP
 neighbor 172.16.51.5 remote-as 100
 no auto-summary

Grundkonfig:

ipv6 unicast-routing
interface FastEthernet0/0
 ipv6 address FE80::1 link-local
 ipv6 address 2001:DB8:CC1E:51::1/64
interface Serial0/0
 ipv6 address FE80::1 link-local
 ipv6 address 2001:DB8:CC1E:12::1/64
 !
 interface Serial0/1
 ipv6 address FE80::1 link-local
 ipv6 address 2001:DB8:CC1E:14::1/64
 !
 interface Loopback0
 ipv6 address 2001:DB8:CC1E:1111::1/128

IGP:

För att kunna peera mot IPv6-loopback adresser måste vi även annonsera dessa nät över IGP, i detta fall använder i OSPF.

interface Loopback0
 ipv6 ospf 100 area 0
 !
 interface Serial0/0
 ipv6 ospf 100 area 0
 !
 interface Serial0/1
 ipv6 ospf 100 area 0
 !
 interface FastEthernet0/0
 ipv6 ospf 100 area 0
 !
 ipv6 router ospf 100
 router-id 1.1.1.1

iBGP:

router bgp 500
neighbor iBGP_ipv6 peer-group
 neighbor iBGP_ipv6 remote-as 500
 neighbor iBGP_ipv6 update-source Loopback0
 neighbor iBGP_ipv6 next-hop-self
neighbor 2001:DB8:CC1E:2222::2 peer-group iBGP_ipv6
 neighbor 2001:DB8:CC1E:3333::3 peer-group iBGP_ipv6
 neighbor 2001:DB8:CC1E:4444::4 peer-group iBGP_ipv6
adress-family ipv6
 neighbor 2001:DB8:CC1E:2222::2 activate
 neighbor 2001:DB8:CC1E:3333::3 activate
 neighbor 2001:DB8:CC1E:4444::4 activate

eBGP:

router bgp 500
 neighbor 2001:DB8:CC1E:51::5 remote-as 100
address-family ipv6
 neighbor 2001:DB8:CC1E:51::5 activate

Puhh..

R2

Grundkonfig & IGP:

ipv6 unicast-routing
 !
 interface Loopback0
 ipv6 address 2001:DB8:CC1E:2222::2/128
 ipv6 ospf 100 area 0
 !
 interface Serial0/0
 ipv6 address FE80::2 link-local
 ipv6 address 2001:DB8:CC1E:12::2/64
 ipv6 ospf 100 area 0
 !
 interface Serial0/1
 ipv6 address FE80::2 link-local
 ipv6 address 2001:DB8:CC1E:23::2/64
 ipv6 ospf 100 area 0
 !
 ipv6 router ospf 100
 router-id 2.2.2.2

iBGP:

router bgp 500
 neighbor iBGP_ipv6 peer-group
 neighbor iBGP_ipv6 remote-as 500
 neighbor iBGP_ipv6 update-source Loopback0
 neighbor iBGP_ipv6 next-hop-self
 neighbor 2001:DB8:CC1E:1111::1 peer-group iBGP_ipv6
 neighbor 2001:DB8:CC1E:3333::3 peer-group iBGP_ipv6
 neighbor 2001:DB8:CC1E:4444::4 peer-group iBGP_ipv6
 !
 address-family ipv6
 neighbor 2001:DB8:CC1E:1111::1 activate
 neighbor 2001:DB8:CC1E:3333::3 activate
 neighbor 2001:DB8:CC1E:4444::4 activate

R3

Grundkonfig & IGP:

ipv6 unicast-routing
 !
 interface Loopback0
 ipv6 address 2001:DB8:CC1E:3333::3/128
 ipv6 ospf 100 area 0
 !
 interface FastEthernet0/0
 ipv6 address FE80::3 link-local
 ipv6 address 2001:DB8:CC1E:36::3/64
 ipv6 ospf 100 area 0
 !
 interface Serial0/0
 ipv6 address FE80::1 link-local
 ipv6 address 2001:DB8:CC1E:43::3/64
 ipv6 ospf 100 area 0
 !
 interface Serial0/1
 ip address 172.16.23.3 255.255.255.0
 ipv6 address FE80::1 link-local
 ipv6 address 2001:DB8:CC1E:23::3/64
 ipv6 ospf 100 area 0
 !
 ipv6 router ospf 100
 router-id 3.3.3.3

iBGP:

router bgp 500
 neighbor iBGP_ipv6 peer-group
 neighbor iBGP_ipv6 remote-as 500
 neighbor iBGP_ipv6 update-source Loopback0
 neighbor iBGP_ipv6 next-hop-self
 neighbor 2001:DB8:CC1E:1111::1 peer-group iBGP_ipv6
 neighbor 2001:DB8:CC1E:2222::2 peer-group iBGP_ipv6
 neighbor 2001:DB8:CC1E:4444::4 peer-group iBGP_ipv6
 !
 address-family ipv6
 neighbor 2001:DB8:CC1E:1111::1 activate
 neighbor 2001:DB8:CC1E:2222::2 activate
 neighbor 2001:DB8:CC1E:4444::4 activate

eBGP:

router bgp 500
 neighbor 2001:DB8:CC1E:36::6 remote-as 100
 !
 address-family ipv6
 neighbor 2001:DB8:CC1E:36::6 activate

R4

Grundkonfig & IGP:

interface Loopback0
 ipv6 address 2001:DB8:CC1E:4444::4/128
 ipv6 ospf 100 area 0
 !
 interface Serial0/0
 ipv6 address FE80::4 link-local
 ipv6 address 2001:DB8:CC1E:43::4/64
 ipv6 ospf 100 area 0
 !
 interface Serial0/1
 ipv6 address FE80::4 link-local
 ipv6 address 2001:DB8:CC1E:14::4/64
 ipv6 ospf 100 area 0
 !
 ipv6 router ospf 100
 router-id 4.4.4.4

iBGP:

router bgp 500
 neighbor iBGP_ipv6 peer-group
 neighbor iBGP_ipv6 remote-as 500
 neighbor iBGP_ipv6 update-source Loopback0
 neighbor iBGP_ipv6 next-hop-self
 neighbor 2001:DB8:CC1E:1111::1 peer-group iBGP_ipv6
 neighbor 2001:DB8:CC1E:2222::2 peer-group iBGP_ipv6
 neighbor 2001:DB8:CC1E:3333::3 peer-group iBGP_ipv6
 !
 address-family ipv6
 neighbor 2001:DB8:CC1E:1111::1 activate
 neighbor 2001:DB8:CC1E:2222::2 activate
 neighbor 2001:DB8:CC1E:3333::3 activate

Verifiering:

R5:

ipv6-bgp-summary-r5

ipv6-bgp-unicast-r5

R2:

ipv6-bgp-summary-r2

R6:

ipv6-bgp-summary-r6

ipv6-bgp-unicast-r6

All done!

Se tidigare inlägg för information om hur vi sätter upp RIPng, EIGRP & OSPFv3.

BGP – Route Dampening

Jonas CollénBGP

Route Dampening är BGP’s skydd mot flappande routes. Har vi 450,000+ routes i vår routing-tabell är det garanterat ett stort antal av dessa som kanske har problem med sin uppkoppling eller har ett interface som studsar. Utan att filtrera bort dessa uppdateringar skulle vår router troligtvis gå på knäna i princip direkt.

Route dampening påverkar inte våra neighbors utan den filtrerar endast det specifika prefixet som har problem.

Per default använder BGP en light-variant av dampening för sina utgående uppdateringar genom attt ha en wait-time satt till 30 sekunder för eBGP & 5 sekunder för iBGP innan den skickar ett BGP-Update paket.

Om vi tar följande topologi så kan vi titta lite närmare på hur dampening fungerar i praktiken.

confederations

Nätet 200.200.20.0/24 som annonseras via R5 till ISP-Telia/Tele2 har fått problem med sin fiberuppkoppling till R3 och tappar sin anslutning var 45:e sekund.

R3 upptäcker att den inte längre har kontakt och informerar R2&R1 som i sin tur skickar ett BGP Update-paket till ISP-Telia/Tele2 att nätet inte längre är nåbart.

ISP-routrarna sätter då per default ett “Penalty”-värde för 200.200.20.0/24 prefixet (1000). Penalty-värdet börjar dock genast räkna ner mot 0 igen tack vare funktionen “Decay Algorithm” där default-värdet är 15min. Efter 15 minuter så har penalty-värdet halverats till 500, 15min efter det har det halverats till 250 osv. Detta värde nollställs ej när routen 45 sekunder senare blir nåbar igen.

När vi tappar länken en andra gång, så informerar vi återigen ISP-Telia/Tele2. Säg att Penalty-värdet nu möjligtvis har hunnit räkna till 995. Den lägger då till ytterligare 1000 till Penalty-värdet (totalt 1995).

När penalty-värdet för prefixet 200.200.20.0/24 är >=2000 så har vi nått “Suppress-limit”, både ISP-Telia&Tele2 börjar då ignorera uppdateringar för det prefixet (suppressed) och sätter nätet som unreachable.

Reuse-limit är per default 750, när vårt nät stabiliserat och decay-algorithm fått värdet att gå under detta så börjar nätet användas igen. Med default-värden kommer med andra ord ett nät som blivit suppressed vara så i minst 30 minuter (>2000/2 15min, 1000/2 15min -> 500) .

Max-tiden för dampening är dock 60 minuter oavsett hur instabil en länk är.

Default-värden:

  • Penalty – 1000
  • Suppress Limit – 2000
  • Reuse Liimit – 750
  • Decay Algorithm (Half-life) – 15 min

BGP ger oss möjligheten att modifiera alla dessa förutom Penalty-värdet!

Vi aktiverar Route Dampening och justerar ovanstående värden genom:

router bgp n
bgp dampening ....

Det är dock viktigt att vi verifierar att värdena vi konfigurerar faktiskt är giltiga genom följande formel:

max-penalty = reuse-limit * 2^(max-suppress-time/half-life)

Säg att vi konfigurerat följande värden:

  • Penalty 1000
  • Suppress Limit 10000
  • Reuse Limit 1500
  • Half-Life 30min
  • Maximum suppression 60min

max-penalty = 1500*2^(60/30) = 6000. Vi kommer med andra ord aldrig nå vår suppress-limit!

Det går att kombinera dampening med route-maps om vi exempelvis endast vill använda dampening för ett enskilt prefix.

ISP-Tele2(config)#route-map 200_dampening permit 10
ISP-Tele2(config-route-map)#match ip address 10
ISP-Tele2(config-route-map)#set dampening ?
<1-45> half-life time for the penalty
ISP-Tele2(config-route-map)#set dampening 5 ?
 <1-20000> penalty to start reusing a route
ISP-Tele2(config-route-map)#set dampening 5 1900 ?
 <1-20000> penalty to start suppressing a route
ISP-Tele2(config-route-map)#set dampening 5 1900 2000 ?
 <1-255> Maximum duration to suppress a stable route
ISP-Tele2(config-route-map)#set dampening 5 1900 2000 10
ISP-Tele2(config)#router bgp 2200
ISP-Tele2(config-router)#bgp dampening route-map 200_dampening

Vi testar stänga ner Lo0 på R5 en gång:

ISP-Tele2#sh ip bgp 200.200.20.0
BGP routing table entry for 200.200.20.0/24, version 21
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
 Not advertised to any peer
 400
 172.16.100.1 from 172.16.100.1 (172.16.100.1)
 Origin IGP, localpref 100, valid, external, best
 Dampinfo: penalty 820, flapped 1 times in 00:01:27

Vi gör det några gånger till för att få penalty-värdet över 2000:

ISP-Tele2#sh ip bgp 200.200.20.0
BGP routing table entry for 200.200.20.0/24, version 24
Paths: (1 available, no best path)
Flag: 0x820
 Not advertised to any peer
 400, (suppressed due to dampening)
 172.16.100.1 from 172.16.100.1 (172.16.100.1)
 Origin IGP, localpref 100, valid, external
 Dampinfo: penalty 2278, flapped 3 times in 00:04:36, reuse in 00:01:20

dampening

Vi kan rensa bgp dampening för ett prefix via kommandot “clear ip bgp dampening 200.200.20.0 255.255.255.0”. Däremot behålls penalty-värdet! Så skulle länken flappa ytterligare en gång kommer det med all sannolikhet blockeras direkt igen.

ISP-Tele2#show ip bgp dampening flap-statistics
 BGP table version is 25, local router ID is 30.0.7.1
 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
 Origin codes: i - IGP, e - EGP, ? - incomplete
Network From Flaps Duration Reuse Path
 *> 200.200.20.0 172.16.100.1 3 00:07:38 400

Det går även att nollställa penalty-värdet via “clear ip bgp 1.1.1.1 flap-statistics”, detta rensar dock penalty-värdet för alla routes vi lärt oss från den specifika neighborn.

Det avslutar det sista jag hade om BGP just nu, har tagit upp det viktigaste av det lilla som nämns i CCNP Route men även Ciscos cert 642-661 BGP från CCIP.

BGP – Improving effiency

Jonas CollénBGP

BGP ger oss möjligheten att justera en del parametrar för att effektivisera bgp processen och ge en bättre resurshantering. En router med 450,000+ routes att hantera uppskattar nog all hjälp den kan få. 😉

MTU-Discovery

BGP använder per default en MTU-size på endast 536 bytes (<Ios 12.2 visade det sig). I ett ethernet-segment har vi ju dock möjligheten att skicka 1500-bytes paket (1492 för PPPoE), och egentligen ännu större med hjälp av “Jumbo frames” (om det är supportat).

Genom att aktivera kommandot “ip tcp path-mtu-discovery” globalt på routern så aktiveras Path MTU Discovery vilket är en standardiserad teknik för att bestämma vilken MTU-size som stödjs mellan två hosts (i detta fall mellan routern och dess neighbor).

Routern sätter då DF-biten (Don’t Fragment) i IP-headern för alla utgående TCP-paket. Om någon enhet längs vägen till destinationen inte stödjer den MTU-size vi använt kan två saker hända:

  1. DF-biten är satt till 0 – paketet fragmenteras till en mindre MTU-size och skickas sedan vidare
  2. DF-biten är satt till 1 – Paketet droppas och returnerar en “ICMP – Fragmentation Needed (Type 3, Code 4)” innehållandes sin egen MTU-size

Då DF-biten i detta fall är satt till 1 så returneras ett Type 3-paket, vår router använder informationen till att justera ner sin egen MTU-size så den matchar.

Det är med andra ord viktigt att vi tillåter ICMP Type 3-paket i vår brandvägg/ACL. Ett vanligt problem är annars att TCPs “3-way handshake” lyckas men sessionen sedan hänger sig när routern försöker skicka data, en så kallad “black hole-connection”.

mtu-path-discovery

Denna process upprepas till MTU-sizen är tillräckligt liten och paketet nått hela vägen till destinationen.

Cisco har en väldigt läsvärd whitepaper om IP Fragmentation & MTU-Discovery här.

Vi kan verifiera vad BGP valt att använda för värden via show ip bgp neighbors:

mtu-path-discovery2

Haha.. Så går det när jag nöjer mig med att läsa teorin innan man testat det praktiskt. Här kan vi ju faktiskt ser att BGP valt en MTU-size 1460! Lite efterforskning visade att detta aktiveras per default för varje neighbor sedan IOS v12.2. Borde kanske ta och uppdatera mitt läsmaterial.. 😀

Vi ska nu för tiden kunna styra detta individuellt per neighbor om vi vill enligt den dokumentation jag hittat, men i den IOS-version (c3750 12.4(T15)) som jag använder är detta ej möjligt konstigt nog:

R2(config-router)#neighbor 10.10.12.1 transport ? 
 connection-mode Specify passive or active connection

Vi har dock fortfarande möjlighet att aktivera MTU Discovery globalt på routern om vi skulle vilja göra det för någon annan process så denna post inte blir totalt värdelös. 😀

R2(config)#ip tcp path-mtu-discovery age-timer ?
 <10-30> Aging time
 infinite Disable pathmtu aging timer

Väljer vi infinte testar routern förbindelsen bara en gång och behåller sedan MTU-värdet, 30 sekunders intervaller är annars default.

Peer-groups

Med hjälp av Peer-groups kan vi minska systemresurserna som behövs vid skapandet av BGP Update-paket, det kan även förenkla vår konfiguration av neighbors, win-win! 🙂

Peer-groups ger oss möjligheten att gruppera neighbor-syntaxer, som du säkert märkt vid det här laget så är det en hel del neighbor-syntaxer som upprepas gång på gång. Detta gör att routern sedan endast behöver generera ett BGP Update-paket som den sen kan replikera till samtliga grupp-medlemmar. Vi kan dock fortfarande ha individuell konfiguration för inkommande uppdateringar!

Se följande konfiguration för en iBGP full mesh mellan fyra routrar till exempel:

router bgp 500
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 500
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 neighbor 2.2.2.2 password cisco
 neighbor 3.3.3.3 remote-as 500
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 next-hop-self
 neighbor 3.3.3.3 password cisco
 neighbor 4.4.4.4 remote-as 500
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 4.4.4.4 next-hop-self
 neighbor 4.4.4.4 password cisco
 neighbor 172.16.51.5 remote-as 100
 no auto-summary

Vi ser att neighbor-syntaxerna är identiska för 2.2.2.2, 3.3.3.3 & 4.4.4.4, det är med andra ord ett perfekt läge att använda oss av en peer-group.

Sedan IOS 12.0 så skapar routern detta själv “behind the scenes” även om du inte väljer att konfigurera detta själv. Vi kan verifiera detta med “show ip bgp update-group”:

BGP version 4 update-group 1, external, Address Family: IPv4 Unicast
 BGP Update version : 0/0, messages 0
 Update messages formatted 0, replicated 0
 Number of NLRIs in the update sent: max 0, min 0
 Minimum time between advertisement runs is 30 seconds
 Has 1 member (* indicates the members currently being sent updates): 
 172.16.51.5
BGP version 4 update-group 2, internal, Address Family: IPv4 Unicast
 BGP Update version : 0/0, messages 0
 NEXT_HOP is always this router
 Update messages formatted 0, replicated 0
 Number of NLRIs in the update sent: max 0, min 0
 Minimum time between advertisement runs is 0 seconds
 Has 3 members (* indicates the members currently being sent updates): 
 2.2.2.2 3.3.3.3 4.4.4.4

Men rekommenderat är ändå att göra detta på egen hand och låta så lite som möjligt skötas “automatiskt” för att undvika fel (tänk no autonegotiate osv).

Vi konfigurerar en peer-group enligt följande:

router bgp n
neighbor IBGP_ROUTERS peer-group
neighbor IBGP_ROUTERS remote-as 500
neighbor IBGP_ROUTERS update-source Loopback0
neighbor IBGP_ROUTERS next-hop-self
neighbor IBGP_ROUTERS password cisco

Våra neighbor-statements blir nu istället endast:

neighbor 2.2.2.2 peer-group IBGP_ROUTERS
neighbor 3.3.3.3 peer-group IBGP_ROUTERS
neighbor 4.4.4.4 peer-group IBGP_ROUTERS
neighbor 172.16.51.5 remote-as 100

Helt klar en mer “clean” konfig dessutom!

BGP peer-group is IBGP_ROUTERS, remote AS 500
 BGP version 4
 Default minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
 BGP neighbor is IBGP_ROUTERS, peer-group internal, members:
 2.2.2.2 3.3.3.3 4.4.4.4 
 Index 0, Offset 0, Mask 0x0
 NEXT_HOP is always this router
 Update messages formatted 0, replicated 0
 Number of NLRIs in the update sent: max 0, min 0

Peer-Template

Det finns nu för tiden en form av “Peer-groups 2.0” – Peer template, det går dock ej att kombinera template med groups.

Vi konfigurerar det via:

router bgp n
template peer-policy n

peer-templates

Alternativt session-relaterade kommandon:

router bgp n
template peer-session n

peer-sessions

Vi aktiverar det sedan per neighbor genom:

neighbor 1.1.1.1 inherit peer-policy JONAS_POLICY
neighbor 1.1.1.1 inherit peer-session JONAS_SESSION

Input-Queues

Ger oss möjligheten att justera hur många paket routern skall buffra tills processorn är tillgänglig innan den börjar använda “taildrops”, dvs droppa de senast inkomna paketen. Default är 75, dvs. routern håller bara 75 paket i buffern innan den börjar droppa paket.

Detta kan markant öka konvergenstiden när vi försöker sätta upp en BGP-session som använder “full routingtable”/450k+ routes då det är väldigt mycket data som måste processas.  Cisco rekommenderar att vi ökar detta till 1000, vilket görs på interface-nivå genom kommandot:

R2(config-if)#hold-queue 1000 in

Vi ska dock vara försiktiga med att sätta för stort värde då vi inte vill buffra TCP-Ack paket i onödan. Det är klart bättra att vi istället droppar dessa paket så avsändaren får möjlighet att justera sin window size, ett bra mellanvärde ska som sagt vara 1000.

BGP Scan-process

BGPs Scan-process var något jag nämnde lite kort i min introduktion till BGP som du hittar här. BGP Scanner startar per default var 60:e sekund och går igenom hela BGP-table (sh ip bpg) och validerar att next-hop fortfarande är nåbart genom att kontrollera routerns RIB.  Om en route upptäcks vara onåbar markeras den som “invalid”, tas bort ur routing-table och informerar sina peers.

Vi kan modifera detta intervall via kommandot “bgp scan-time” för att hitta invalid-routes snabbare och minska konvergenstiden , detta kan dock markant öka CPU-belastningen om BGP-table innehåller många routes.

R2(config-router)#bgp scan-time ?
 <5-60> Scanner interval (seconds)

BGP Advertisement-interval

Om routern behöver skicka ut en uppdatering till sina peers väntar den först ett förutbestämt antal sekunder innan den skickar uppdateringen, Detta ger routern möjlighet att samla ihop flera skiljda uppdateringar och skicka ut dessa samtidigt, exempelvis vid ett större nätfel eller dylikt.

Exempelvis om vår BPG-Scanner upptäckt att vi inte längre kan nå next-hop adressen 200.0.21.1 för prefixet 191.16.0.0/16, väntar routern ett förutbestämt antal sekunder innan den skickar en uppdatering.

Default-värdet är 30 sekunder för eBGP-peers & 5 sekunder för iBGP-peers. Vi kan ändra detta genom kommandot:

 R2(config-router)#neighbor 10.10.12.1 advertisement-interval ?
 <0-600> time in seconds

BGP Maximum-prefix

För att skydda oss mot exempelvis en felkonfigurering hos vår ISP har vi möjlighet att per neighbor bestämma det maximala antalet prefix vi accepterar att de skickar till oss.

Vi kan som bekant kontrollera hur många prefix vi tar emot i dagsläget via kommandot sh ip bgp summary:

prefixlimit

Genom att konfigurera maximum-prefix behöver vi inte vara oroliga för att någon trött admin bakom exempelvis neighbor 10.10.12.1 skulle råka annonsera hela BGP-table på 450k routes till oss av misstag och kanske vår router.  🙂

router bgp 64512
neighbor 10.10.12.1 maximum-prefix 20

Om vår neighbor överstiger det konfigurerade värdet stänger routern per default ner sessionen, och vi måste sedan manuellt göra en clear ip bgp för att få upp sessionen igen.

Vi kan dock modifiera detta så att routern exempelvis först varnar vid en viss % av maxvärdet eller bara startar om sessionen.

R2(config-router)#neighbor 10.10.12.1 maximum-prefix 10 ?
 <1-100> Threshold value (%) at which to generate a warning msg
 restart Restart bgp connection after limit is exceeded
 warning-only Only give warning message when limit is exceeded

Next up – Route dampening. 🙂