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!

IPv6 – BGP Dual stack

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 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!

BGP – Key BGP Attributes

Detta blir ett kort inlägg som sträcker sig lite utanför CCNP-nivån.

BGP Attributes är information/metrics om en specifik route som ingår i “BGP Update”-paketen som skickas mellan peers. Dessa attribut används främst av BGPs “Best path selection”-process som vi gått igenom många gånger tidigare och är kategoriserade som antingen “Well-known” eller “Optional attributes”.

  • “Well-known” (standard) – vilket måste stödjas av alla leverantörers BGP-implementering (Cisco, Juniper etc.)
  • Optional (proprietary) – stödjs endast av en/flera tillverkare

Well-known Attributes

Well-known attribut är i sin tur uppdelade i två kategorier, Mandatory = Måste alltid finnas med, samt Discretionary vilket är “optional” och behöver ej ingå i update-paketen (men måste fortfarande stödjas av alla leverantörer!).

  • Origin * (igp/egp/?)
  • AS-Path *
  • Next-Hop *
  • Local Preference
  • Atomic Aggregate

* Mandatory – Måste alltid ingå i BGPs update-paket för att det skall vara giltigt

Detta stämmer ju överens med den bild vi fått av Local Preference då vi vet att det endast gäller inom ett AS (iBGP) och skickas inte med i uppdateringar över eBGP.  Atomic aggregate används som du kanske redan listat ut för route-summering och är med andra ord inget som alltid används, därav klassas även den som “Discretionary”.

Optional Attributes

  •  Multi-Exit Descriminator (MED)
  • Aggregator
  • Community

Här är några exempel på några av de de vanligast implementerade”optional”-attributen, men som till skillnad från Well-known inte behöver stödjas, känner routern inte till attributet så ignoreras det bara.

Detta ger möjligheten för tillverkare etc. att ta fram egna attribut, och detta är även den största orsaken att vi fortfarande använder BGPv4 som inte behövts uppgraderas till version 5 på över 10 år. Nya tillägg läggs hela tiden till, men pga att de räknas som optional attribut behöver “koden” inte skrivas om för “alla andra”.

Detta (och mycket annat) tas upp i videon från Google Tech Talks som jag länkat innan, väldigt sevärd! https://www.youtube.com/watch?v=_Mn4kKVBdaM

Hur MED används och konfigureras har vi redan tittat på i ett tidigare inlägg, se här. Aggregator informerar om VILKEN router det är som gjort route-summeringen.

Community ger oss möjligheten att dela upp ett AS i flera “communitys”. Mer om detta i en senare post!

BGP – Lab, Configuring a Transit AS/ISP

Tänkte göra ett försök att sätta upp Jeremys Transit AS-lab från hans CCIP BGP-serie. Labben är uppbyggd enligt följande:

topology transit lab
scenario transit lab

requirements transit lab 1

requirements transit lab 2

Min lösning

gns3topology

Grundkonfig

!ISP1 Basic conf
inte s0/0
ip add 17.9.1.1 255.255.255.252
no shut
description To R2
clock rate 256000
int s0/1
ip add 17.9.1.5 255.255.255.252
no shut
description To R2
clock rate 256000
int lo0
ip add 11.11.11.11 255.255.255.255
no shut

!ISP2 Basic conf
inte s0/0
ip add 180.1.5.1 255.255.255.252
no shut
description To R1
clock rate 256000
int s0/1
ip add 180.1.5.5 255.255.255.252
no shut
description To R1
clock rate 256000
int lo0
ip add 22.22.22.22 255.255.255.255
no shut

!R1 Basic conf
int s0/0
ip add 17.9.1.2 255.255.255.252
no shut
description To ISP1
int s0/1
ip add 17.9.1.6 255.255.255.252
no shut
description To ISP1
int s0/2
ip add 10.1.1.5 255.255.255.252
no shut
clock rate 256000
description To R2
int s0/3
ip add 10.1.1.1 255.255.255.252
no shut
clock rate 256000
description To R3
int lo0
ip add 1.1.1.1 255.255.255.255

!R2 Basic conf
int s0/0
ip add 180.1.5.2 255.255.255.252
no shut
description To ISP2
int s0/1
ip add 180.1.5.6 255.255.255.252
no shut
description To ISP2
int s0/2
ip add 10.1.1.6 255.255.255.252
no shut
description To R1
int s0/3
ip add 10.1.1.9 255.255.255.252
no shut
clock rate 256000
description To R4
int lo0
ip add 2.2.2.2 255.255.255.255

!R3 Basic conf
int s0/0
ip add 150.1.0.1 255.255.255.252
no shut
description To Cust1
clock rate 256000
int s0/1
ip add 10.1.1.13 255.255.255.252
no shut
clock rate 256000
description To R4
int s0/3
ip add 10.1.1.2 255.255.255.252
no shut
description To R1
int lo0
ip add 3.3.3.3 255.255.255.255

!R4 Basic conf
int s0/0
ip add 10.1.1.10 255.255.255.252
no shut
description To R2
int s0/1
ip add 10.1.1.14 255.255.255.252
no shut
description To R3
int lo0
ip add 4.4.4.4 255.255.255.255
no shut
!Cust1 Basic conf
int s0/0
ip add 150.1.0.2 255.255.255.252
no shut
description To R3
int lo0
ip add 150.1.1.1 255.255.255.0

Configure IGP

  • Configure network-statements as specific as possible
  • Only advertise between internal routers
  • Use a hello-timer of 1 second / dead-timer of 3 seconds

Enligt uppgiften skulle vi använda oss av OSPF. Känns inte som något är nytt här så skriver bara ner den konfig jag skriver. Kom ihåg att vi sätter hello/deadtimers per interface! Glöm inte passive-interface default.

!R1
router ospf 1
passive-interface default
no passive-interface s0/2
no passive-interface s0/3
router-id 1.1.1.1
network 1.1.1.1 0.0.0.0 area 0
network 17.9.1.2 0.0.0.0 area 0
network 17.9.1.6 0.0.0.0 area 0
network 10.1.1.5 0.0.0.0 area 0
network 10.1.1.1 0.0.0.0 area 0
int s0/2
ip ospf hello-interval 1
ip ospf dead-interval 3
int s0/3
ip ospf hello-interval 1
ip ospf dead-interval 3

!R2
router ospf 1
passive-interface default
no passive-interface s0/2
no passive-interface s0/3
router-id 2.2.2.2
network 2.2.2.2 0.0.0.0 area 0
network 180.1.5.2 0.0.0.0 area 0
network 180.1.5.6 0.0.0.0 area 0
network 10.1.1.6 0.0.0.0 area 0
network 10.1.1.9 0.0.0.0 area 0
int s0/2
ip ospf hello-interval 1
ip ospf dead-interval 3
int s0/3
ip ospf hello-interval 1
ip ospf dead-interval 3

!R3
router ospf 1
passive-interface default
no passive-interface s0/3
no passive-interface s0/1
router-id 3.3.3.3
network 3.3.3.3 0.0.0.0 area 0
network 150.1.0.1 0.0.0.0 area 0
network 10.1.1.2 0.0.0.0 area 0
network 10.1.1.13 0.0.0.0 area 0
int s0/1
ip ospf hello-interval 1
ip ospf dead-interval 3
int s0/3
ip ospf hello-interval 1
ip ospf dead-interval 3

!R4
router ospf 1
passive-interface default
no passive-interface s0/0
no passive-interface s0/1
router-id 4.4.4.4
network 4.4.4.4 0.0.0.0 area 0
network 10.1.1.14 0.0.0.0 area 0
network 10.1.1.10 0.0.0.0 area 0
int s0/0
ip ospf hello-interval 1
ip ospf dead-interval 3
int s0/1
ip ospf hello-interval 1
ip ospf dead-interval 3

Kom ihåg att verifiera så att alla nät är nåbara redan nu innan det börjar bli lite mer avancerat. 🙂

Full-mesh IGP

  • Peers should fail over based on IGP if any internal links fail
  • Set logical descriptions in BGP
  • Disable BGP synchronization

Steg 1 har vi redan löst delvis genom att konfigurera Loopbacks på R1-R4 som vi annonserar via OSPF. När vi sätter upp iBGP-relations nu så behöver vi endast använda loopback-adresserna istället för de fysiska länknäten. Kom ihåg att även ändra update-source (om du inte vet varför, se tidigare inlägg om iBGP transit-area)!

Steg 2 fixar vi genom descriptions per neighbor-statement, och BGP synchronization är avslaget per default i den IOS jag använder (v12.4(15)T13) (no synchronization).

!R1 iBGP
router bgp 500
neighbor 2.2.2.2 remote-as 500
neighbor 2.2.2.2 description iBGP to R2
neighbor 2.2.2.2 update-source Lo0
neighbor 3.3.3.3 remote-as 500
neighbor 3.3.3.3 description iBGP to R3
neighbor 3.3.3.3 update-source Lo0
neighbor 4.4.4.4 remote-as 500
neighbor 4.4.4.4 description iBGP to R4
no synchronization

!R2
router bgp 500
neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 description iBGP to R1
neighbor 1.1.1.1 update-source Lo0
neighbor 3.3.3.3 remote-as 500
neighbor 3.3.3.3 description iBGP to R3
neighbor 3.3.3.3 update-source Lo0
neighbor 4.4.4.4 remote-as 500
neighbor 4.4.4.4 description iBGP to R4
neighbor 4.4.4.4 update-source Lo0
no synchronization

!R3
router bgp 500
neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 description iBGP to R1
neighbor 1.1.1.1 update-source Lo0
neighbor 2.2.2.2 remote-as 500
neighbor 2.2.2.2 description iBGP to R2
neighbor 2.2.2.2 update-source Lo0
neighbor 4.4.4.4 remote-as 500
neighbor 4.4.4.4 description iBGP to R4
neighbor 2.2.2.2 update-source Lo0
no synchronization

!R4
router bgp 500
neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 description iBGP to R1
neighbor 1.1.1.1 update-source Lo0
neighbor 2.2.2.2 remote-as 500
neighbor 2.2.2.2 description iBGP to R2
neighbor 2.2.2.2 update-source Lo0
neighbor 3.3.3.3 remote-as 500
neighbor 3.3.3.3 description iBGP to R3
neighbor 3.3.3.3 update-source Lo0
no synchronization

En sh ip bgp summary visar att vi är på rätt spår. 🙂

R1#sh ip bgp summary 
BGP router identifier 1.1.1.1, local AS number 500
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 500 6 7 1 0 0 00:03:47 0
3.3.3.3 4 500 4 5 1 0 0 00:01:55 0
4.4.4.4 4 500 4 4 1 0 0 00:00:12 0

Configure eBGP-peers between NL Fast & ISP1-2 and Customer

  • On redudant links, peers using loopback and provide loadbalancing
  • Configure authentication
  • Set logical descriptions for neighbors

Steg 1 skiljer sig inte jättemycket från vad vi nyss gjorde när vi satte upp iBGP-mesh. Som du förhoppningsvis kommer ihåg tillåter BGP endast en öppen session mot en neighbor, för redundanta länkar bör vi således använda Loopback-interface för att inte vara låsta till någon specifik länk. Kom ihåg att ändra update-source!

Lastbalansering skapar vi enklast via två statiska routes som båda pekar på ISP1/2s loopback-adress och vice-versa.

Autentisering har jag inte skrivit någon post om ännu men det är extremt enkelt att sätta upp i BPG som du kommer se nedan.

!R1 eBGP

ip route 11.11.11.11 255.255.255.255 17.9.1.1
ip route 11.11.11.11 255.255.255.255 17.9.1.5

router bgp 500
neighbor 11.11.11.11 remote-as 200
neighbor 11.11.11.11 description ISP1
neighbor 11.11.11.11 password cisco
neighbor 11.11.11.11 update-source lo0

!ISP1

ip route 1.1.1.1 255.255.255.255 17.9.1.2
ip route 1.1.1.1 255.255.255.255 17.9.1.6

router bgp 200
neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 description ISP1
neighbor 1.1.1.1 password cisco
neighbor 1.1.1.1 update-source Lo0

!R2

ip route 22.22.22.22 255.255.255.255 180.1.5.1
ip route 22.22.22.22 255.255.255.255 180.1.5.5

router bgp 500
neighbor 22.22.22.22 remote-as 300
neighbor 22.22.22.22 description ISP1
neighbor 22.22.22.22 password cisco
neighbor 22.22.22.22 update-source lo0
neighbor 22.22.22.22 ebgp-multihop 2

!ISP2

ip route 2.2.2.2 255.255.255.255 180.1.5.2
ip route 2.2.2.2 255.255.255.255 180.1.5.6

router bgp 300
neighbor 2.2.2.2 remote-as 500
neighbor 2.2.2.2 description ISP1
neighbor 2.2.2.2 password cisco
neighbor 2.2.2.2 update-source Lo0

Här fastande jag dock ett tag, av någon anledning fick jag inte upp någon adjacency? Varken debug ip bgp all eller wireshark gav några hintar om vad felet kunde tänkas vara. En show ip bgp summary visade endast att neighbor x.x.x.x var fast i “idle”. Tillslut kom jag dock på vad det var, gör du? Försök att finna lösningen själv!

facit i vit text (markera för svar): eBGP-multihop! TTL sätts som bekant till 1 för eBGP-relationsships, när vi använder Loopbacks behöver vi därför modifera detta via neighbor x.x.x.x ebgp-multihop 2. Har en tidigare post dedikerad om just detta om detta koncept är nytt för dig och finns att läsa här.

Announce networks in BGP appropriately

  • ISP1 & 2 should use filtered redistribution to announce their networks. Only networks located on the loopback-interfaces of ISP1&2 should enter the BGP-table
  • The Cust1-router should advertise its network using the network-statement
  • R1 & R2 should advertise the WAN-link subnet (currently 150.1.0.0/30) as 150.1.0.0/24

Här är det nog lika bra vi bryter ner det i mindre delar. Vi börjar med filtered redistribution!

Verkar som att det saknades i topologin jeremy skapade, men ISP1 ska tydligen ha mer än det loopback-nätet vi använder för att sätta upp eBGP. Jag skapade därför 5 nät på respektive router:

!R1
int lo1
ip add 200.10.0.1 255.255.255.0
int lo2
ip add 200.10.1.1 255.255.255.0
int lo3
ip add 200.10.2.1 255.255.255.0
int lo4
ip add 200.10.3.1 255.255.255.0
int lo5
ip add 200.10.4.1 255.255.255.0

!R2
int lo1
ip add 200.20.0.1 255.255.255.0
int lo2
ip add 200.20.1.1 255.255.255.0
int lo3
ip add 200.20.2.1 255.255.255.0
int lo4
ip add 200.20.3.1 255.255.255.0
int lo5
ip add 200.20.4.1 255.255.255.0

Vi hade enkelt kunnat lösa detta genom att använda network-statements för Loopback-näten, men i detta fall så önskas filtrering. Finns säkert många olika lösningar på detta men såhär tänkte jag:

Vi skapar först en prefix-lista:

!ISP1
 ip prefix-list LOOPBACKS seq 5 permit 200.10.0.0/24
 ip prefix-list LOOPBACKS seq 10 permit 200.10.1.0/24
 ip prefix-list LOOPBACKS seq 15 permit 200.10.2.0/24
 ip prefix-list LOOPBACKS seq 20 permit 200.10.3.0/24
 ip prefix-list LOOPBACKS seq 25 permit 200.10.4.0/24

 !ISP2
 ip prefix-list LOOPBACKS seq 5 permit 200.20.0.0/24
 ip prefix-list LOOPBACKS seq 10 permit 200.20.1.0/24
 ip prefix-list LOOPBACKS seq 15 permit 200.20.2.0/24
 ip prefix-list LOOPBACKS seq 20 permit 200.20.3.0/24
 ip prefix-list LOOPBACKS seq 25 permit 200.20.4.0/24

Sedan en route-map som endast tillåter nät som matchar vår prefix-lista, passar även på att sätta origin till igp när vi ändå är igång:

!ISP1 & 2
route-map LOOPBACK_FILTER permit 10
match ip address prefix-list LOOPBACKS
set origin igp

Och vi använder sedan route-mapen som filter när vi aktiverar redistribution av nät som är “Connected”:

!ISP1 & 2
router bgp 200 / 300
redistribute connected route-map LOOPBACK_FILTER

Det borde fixa biffen! En debug visar att vi är på rätt spår:

*Mar 1 02:18:30.707: BGP: Applying map to find origin for 200.10.4.0/24
*Mar 1 02:18:30.735: BGP: Applying map to find origin for 200.10.0.0/24
*Mar 1 02:18:30.739: BGP: Applying map to find origin for 200.10.1.0/24
*Mar 1 02:18:30.743: BGP: Applying map to find origin for 200.10.2.0/24
*Mar 1 02:18:30.747: BGP: Applying map to find origin for 200.10.3.0/24

Och en sh ip bgp på R4 visar att allt fungerar som det ska!

R4-bgplab

Next up var :

  • The Cust1-router should advertise its network using the network-statement

Denna router har just nu endast grundkonfig så vi får fixa allt grundläggande också! Då vi ej har en redundant lina behöver vi ej “krångla” med loopbacks/ebgp multihop. Observera också att kunden använder ett Privat-AS, vilket kan jämföras med privata ip-adresser, och bör således aldrig annonseras ut till internet(ISP1/2).

!R3
 router bgp 500
 neighbor 150.1.0.2 remote-as 64512
 neighbor 150.1.0.2 description Cust1
 neighbor 150.1.0.2 password cisco

!Cust1 (private AS)
 router bgp 64512
 no synchronization
 network 150.1.1.0 mask 255.255.255.0
 neighbor 150.1.0.1 remote-as 500
 neighbor 150.1.0.1 description NLFastISP
 neighbor 150.1.0.1 password cisco

Ser bra ut! Observera dock att vi just nu skickar med det privata as-numret till ISP:en.

isp1

Detta är inget som nämns i CCNP-boken så fick ta och googla lite, skönt nog var det väldigt enkelt att fixa!

!R1
router bgp 500
neighbor 11.11.11.11 remove-private-as

!R2
router bgp 500
neighbor 22.22.22.22 remote-private-as
  • R1 & R2 should advertise the WAN-link subnet (currently 150.1.0.0/30) as 150.1.0.0/24

Enklast tycker jag borde vara att göra enligt följande:

!R3
ip route 150.1.0.0 255.255.255.0 null0
router bgp 500
network 150.1.0.0 mask 255.255.255.0

Svårare än så behöver det nog inte vara..

isp1-null0

Woho!! 🙂

Verify

  • Verify that all expected neighbors have formed – check!
  • Verify that all expected routes appear – check!
  • ISP1 & 2 should be able to ping: Cust1 routes & NL FastISP WAN-link
ISP1#ping 150.1.0.1 source lo0
Success rate is 0 percent (0/5)
ISP1#ping 150.1.1.1 source lo0
Success rate is 0 percent (0/5)

Crap.. 🙂 Let the troubleshooting begin!

En traceroute visar att vi fastnar i R3:

ISP1#traceroute 150.1.0.2
Type escape sequence to abort.
Tracing the route to 150.1.0.2
1 17.9.1.6 36 msec
 17.9.1.2 48 msec
 17.9.1.6 72 msec
 2 10.1.1.2 8 msec 40 msec 124 msec
 3 * * *

Om du varit väldigt uppmärksam på skärmdumparna jag visat under labben här så kanske du redan upptäckt ett stort problem. Om vi kollar en skärmdump från R4 exempelvis:

r4-bgplab2

Endast 150.1.0.0/24 & 150.1.1.0/24 har valts till “best”-route och har därför inte lagt in i routing table! Det är även därför vi inte kan se ISP2’s routes i ISP1’s table.

isp1-null0

Problemet är helt enkelt att routrarna EJ har en route för den next-hop adressen som annonseras (förutom R1<->ISP1 och R2<->ISP2 tack vare sina statiska routes)!

Jag löste det enligt följande:

!R1
access-list 1 permit 11.11.11.11 0.0.0.0 
route-map LOOP_REDIST permit 10
match ip address 1
router ospf 1
redistribute static subnets route-map LOOP_REDIST

!R2
access-list 1 permit 22.22.22.22 0.0.0.0 
route-map LOOP_REDIST permit 10
match ip address 1
router ospf 1
redistribute static subnets route-map LOOP_REDIST

Let’s watch the magic happen! 🙂

r4-bgplab3

Och från ISP:

isp2

Vackert!

Vi bör dock se till att Customer1 får en default-route, vi vill ju inte hålla på och annonsera våra interna nät dit. Detta löser vi enklast genom följande:

!R3
router bgp 500
#neighbor 150.1.0.2 default-originate

Detta skickar en default-route till Cust1 via BGP! Enkelt. 🙂

custisp

Vi kan nu pinga som önskat!

ISP1#ping 150.1.1.1 source lo1
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/63/92 ms

ISP2#ping 150.1.1.1 source lo1
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/83/140 ms

Finally! Ytterligare något man skulle kunna fixa till är att blockera ISP1 från att lära sig ISP2’s routes via vårat AS och vice versa, då detta gör oss till en transit-area även för dem – något vi absolut inte vill! Men klockan börjar bli väldigt sent och jag ska upp tidigt och jobba imorgon så tar och avslutar här. Problemet hade vi hur som enkelt löst genom route-maps, och endast tillåtit de nät vi specificerar att annonseras ut till AS200 & 300.

BGP – Local Preference & RIB-failures

Vi fortsätter på temat BGP Path Selection från föregående posten där vi kollade närmare på route manipulering via route-maps & weight-attributet.

Local Preference

  • Is a Path Attribute
  • Purpose – Identifies the best exit point from the AS to reach a given prefix
  • Scope – Throughout the AS in which it was set; not advertised to eBGP peers
  • Range – 0 through 4,294,967,295 (2^32 – 1)
  • Which is best? – Higher value is better
  • Default – 100
  • Changing the default – Using the bgp default local-preference n
  • Configuration – Via neighbor route-map; in option is required for updates from an eBGP peer

Efter Weight under BGP’s “best path selection”-process så hittar vi Local Preference, som tillskillnad från just Weight är det BGP Path Attribute. Detta betyder att det inte används endast lokalt av den routern vi konfigurerar det på utan att det annonseras vidare till andra. För Local Preference så är det dock endast till iBGP-neighbors vi annonserar detta!

Detta ger oss möjligheten att inom ett enskilt AS ge oss möjligheten att annonsera till alla iBGP-neighbors en önskad “exit point” för en specifik route vi lärt oss via eBGP. Själva utförandet görs genom en route-map på de inkommande routinguppdateringarna från vår eBGP-peer.

Om vi tittar närmare på ovanstående topologi så har vi ett full mesh-nät inom AS500 mellan R1,R2,R3 & R4. BGP table ser för tillfället ut enligt följande för R1:

bgp localpreference

Och R2:

bgp localpreference2

Du kanske redan har sett något som ser lite konstigt ut? För R2 så har vi default-värdet 100 på Local Preference för samtliga routes, men inte på R1? Vi har även routes markerade med r för R2, men mer om detta senare.

Detta beror på att som tidigare nämnt så används Local Preference endast inom iBGP, routes vi lärt oss från eBGP (R1) skickas endast med ett null värde och routern listar därför inget alls för dessa. R2, som inte har någon eBGP-neighbor utan lär sig alla routes via iBGP får dock default-värdet 100 för samtliga.

För att testa detta rent praktiskt – låt oss försöka konfigurera så att alla iBGP-peers i AS500 väljer omvägen via AS200 för att nå nätet 192.168.0.0/24, istället för direkt via R4 -> AS50.

Vilken router är det då vi ska utföra ändringen i? Om Local Preference justeras via en route-map på inkommande routing-uppdateringar från en eBGP-neighbor, så måste det ju vara i R3 vi ska ändra detta?

Vi börjar med att skapa en…. access-lista.

access-list 1 permit 192.168.0.0

Vi skapar sedan en route-map:

route-map LOCAL-PREF permit 10
match ip address 1
set local-preference 150
route-map LOCAL-PREF permit 20
router bgp 500
neighbor 172.16.36.6 route-map LOCAL-PREF in
do clear ip bgp *

Om allt fungerar som det ska så skall nu R3 annonsera detta till resterande iBGP-neighbors (R1,R2 & R4) som tack vare den högre Local pref. kommer välja att gå via R3(AS500) -> R6(AS200) -> R7(AS50) för att nå 192.168.0.0/24.

bgp localpref3

Sick! 🙂

Vi hade givetvis även kunnat ändra detta i R4 också, men då istället sänkt Local Preference <100 för att få samma effekt.

RIB-Failure

När BGP är klar med sin “BGP best path”-algoritm och har valt vilken väg som är bäst för en specifikt destination, har jag tidigare skrivit att detta skickas vidare till routerns routing table, detta är dock en sanning med modifikation..

BGP skickar nämligen den bästa routen till en annan process vid namnet “IOS Routing Table Manager” (RTM). IOS RTM väljer sedan den bästa routen för en destination mellan flera olika konkurrerande källor. En route kan ju som du bör veta vid det här laget även läras via IGP/BGP/Connected/Static route. IOS samlar den bästa routen från varje process och skickar detta vidare till RTM som sedan i sin tur väljer vilken route som är bäst. För att lyckas med detta används “Administrative Distance” (detta borde du verkligen kunna om du läst CCNA ;)..)

  • Connected – AD 0
  • Static – AD 1
  • EIGRP Summary route – AD 5
  • BGP – AD 20
  • EIGRP (internal) – AD 90
  • IGRP – AD 100
  • OSPF – AD 110
  • ISIS – AD 115
  • RIP – AD 120
  • ODR (On-Demand Routing) – AD 160
  • EIGRP (External) – AD 170
  • iBGP – AD 200
  • Unreachable – AD 255

I de flesta fall borde vi aldrig se en route vi lärt oss via BGP även finns i vår IGP-process eller som Connected (detta blir mer ett problem när vi senare börjar grotta ner oss i MPLS VPNs med BGP/IGP-redistribution). Men hur som helst, OM det skulle hända så finns det ett inbyggt kommando som kan vara bra att känna till – sh ip bgp rib-failures.

Om vi går tillbaka och kollar R2’s BGP-table igen från föregående exempel:

bgp localpreference2

En sh ip bgp rib-failures visar följande:

R2#sh ip bgp rib-failure 
Network Next Hop RIB-failure RIB-NH Matches
200.0.0.0 1.1.1.1 Higher admin distance n/a
200.0.1.0 1.1.1.1 Higher admin distance n/a
200.0.2.0 1.1.1.1 Higher admin distance n/a
200.0.3.0 1.1.1.1 Higher admin distance n/a

Detta listar routes som BGP anser vara bäst, men som RTM valt att ej lägga till i routing table – anledningen är tydlig här, iBGP har en AD på 200, och routern har valt att lägga till routes från en annan “källa” med lägre AD.

show ip route visar boven:

R2#sh ip route | i O E2 
O E2 200.0.0.0/24 [110/1] via 172.16.12.1, 00:03:47, Serial0/0
O E2 200.0.1.0/24 [110/1] via 172.16.12.1, 00:03:47, Serial0/0
O E2 200.0.2.0/24 [110/1] via 172.16.12.1, 00:03:47, Serial0/0
O E2 200.0.3.0/24 [110/1] via 172.16.12.1, 00:03:47, Serial0/0

RTM har fått information om samma routes från OSPF-processen med en AD på 110 och därför valt detta istället.

Detta orsakades på grund av ett konfigurationsfel i R1 där vi redistributade klassfulla BGP-nät in till OSPF-processen, efter att ha tagit bort detta försvann även rib-failure:

R2#sh ip bgp 
BGP table version is 86, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i5.5.5.0/24 1.1.1.1 0 100 0 100 i
*>i6.6.6.0/24 3.3.3.3 0 100 0 200 i
*>i10.0.0.0/16 1.1.1.1 0 100 0 100 i
*>i192.168.0.0 3.3.3.3 0 150 0 200 50 i
*>i200.0.0.0 1.1.1.1 0 100 0 100 i
*>i200.0.1.0 1.1.1.1 0 100 0 100 i
*>i200.0.2.0 1.1.1.1 0 100 0 100 i
*>i200.0.3.0 1.1.1.1 0 100 0 100 i

Vackert!

BGP – AS_SEQ Path Attribute & Best Path Selection

AS_SEQ Path

Per default använder sig BGP av AS_Path attributet “AS_SEQ” (Autonomous System Sequence) för att bestämma vilken route som är bäst, men även för att förhindra eventuella routing loopar.

AS_Path listar vilka AS som trafiken kommer gå via för att nå sin destination, BGP kommer då att välja den route som går via lägst antal AS. Detta kan komiskt nog liknas vid RIP som använder hopcount för att räkna ut den bästa vägen.

Låt oss använda följande topologi för att testa detta lite mer ingående:

bgp AS-path

Vi tar och kollar vidare på nätet 192.168.0.0/24.

I R5 kan vi se följande:

R5#sh ip route | beg Gat
 Gateway of last resort is not set
C 200.0.0.0/24 is directly connected, Loopback1
 5.0.0.0/24 is subnetted, 1 subnets
 C 5.5.5.0 is directly connected, Loopback0
 C 200.0.1.0/24 is directly connected, Loopback2
 6.0.0.0/24 is subnetted, 1 subnets
 B 6.6.6.0 [20/0] via 172.16.51.1, 01:03:52
 C 200.0.2.0/24 is directly connected, Loopback3
 172.16.0.0/24 is subnetted, 1 subnets
 C 172.16.51.0 is directly connected, FastEthernet0/0
 C 200.0.3.0/24 is directly connected, Loopback4
 B 192.168.0.0/24 [20/0] via 172.16.51.1, 00:16:32
 B 200.0.0.0/22 [200/0] via 0.0.0.0, 00:52:34, Nu
R5#sh ip bgp
 BGP table version is 13, 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
 *> 192.168.0.0 172.16.51.1 0 500 200 50 i
 s> 200.0.0.0 0.0.0.0 0 32768 i
 *> 200.0.0.0/22 0.0.0.0 32768 i
 s> 200.0.1.0 0.0.0.0 0 32768 i
 s> 200.0.2.0 0.0.0.0 0 32768 i
 s> 200.0.3.0 0.0.0.0 0 32768 i

Observera next-hop adressen, R1 annonserar sin egen adress då det är ett eBGP-förhållande mellan R1 <-> R5.  Vi kan också se att för R5 skall nå destinationen 192.168.0.0 kommer den behöva gå via Path: 500 -> 200 -> 50. Detta känns ju dock ej som den kortaste vägen när trafiken går via AS 200 också?

Gör vi samma sak på R4 ser det ju dock bättre ut:

R4#sh ip bgp
 BGP table version is 35, 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
 *>i5.5.5.0/24 1.1.1.1 0 100 0 100 i
 * 6.6.6.0/24 172.16.47.7 0 50 200 i
 *>i 3.3.3.3 0 100 0 200 i
 *> 192.168.0.0 172.16.47.7 0 0 50 i
 r>i200.0.0.0/22 1.1.1.1 0 100 0 100 i

Varför väljer då R5 att ta omvägen?

R1#sh ip bgp 192.168.0.0
 BGP routing table entry for 192.168.0.0/24, version 4
 Paths: (2 available, best #1, table Default-IP-Routing-Table)
 Flag: 0x820
 Advertised to update-groups:
 1
 200 50
 3.3.3.3 (metric 129) from 3.3.3.3 (3.3.3.3)
 Origin IGP, metric 0, localpref 100, valid, internal, best
 50
 172.16.47.7 (inaccessible) from 4.4.4.4 (4.4.4.4)
 Origin IGP, metric 0, localpref 100, valid, internal

Det visade sig att jag glömt annonsera nätet 172.16.47.0/24  i R4 till OSPF-processen, BGP använder endast routes den kan nå.

Efter jag fixat detta får vi nu förväntat resultat på R5:

R5#sh ip bgp
 BGP table version is 22, 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
 *> 192.168.0.0 172.16.51.1 0 500 50 i
 s> 200.0.0.0 0.0.0.0 0 32768 i
 *> 200.0.0.0/22 0.0.0.0 32768 i
 s> 200.0.1.0 0.0.0.0 0 32768 i
 s> 200.0.2.0 0.0.0.0 0 32768 i
 s> 200.0.3.0 0.0.0.0 0 32768 i

Om vi även kollar R3’s tabell kan vi se att den har två routes till 192.168.0.0/24-nätet, men att den väljer den med kortast AS_PATH.

R3#sh ip bgp
 BGP table version is 38, local router ID is 3.3.3.3
 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
 *>i5.5.5.0/24 1.1.1.1 0 100 0 100 i
 *> 6.6.6.0/24 172.16.36.6 0 0 200 i
 * 192.168.0.0 172.16.36.6 0 200 50 i
 *>i 172.16.47.7 0 100 0 50 i
 r>i200.0.0.0/22 1.1.1.1 0 100 0 100 i
Routing entry for 192.168.0.0/24
 Known via "bgp 500", distance 200, metric 0
 Tag 50, type internal
 Last update from 172.16.47.7 00:24:41 ago
 Routing Descriptor Blocks:
 * 172.16.47.7, from 4.4.4.4, 00:24:41 ago
 Route metric is 0, traffic share count is 1
 AS Hops 1
 Route tag 50

En viktig skillnad mellan iBGP och eBGP är förövrigt att iBGP ej lägger till sitt AS i AS_PATH. Varför? BGP’s “loop prevention” innebär att routern alltid inspekterar AS_PATH för nya routes, och om den finner att sitt eget AS-nummer redan finns med så ignoreras routen (en bättre väg måste bevisligen redan finnas). Hur vi löser loop prevention i iBGP har jag redan nämnt i det tidigare inlägget  “BGP – Internal BGP & Transitarea” (full mesh).

Best Path Selection

Som vi sett i ovanstående exempel, lämnar vi BGP med default-inställningar kommer den välja routen med kortast AS-PATH. Det ingår dock betydligt fler variabler där routern går i turordning tills den hittar den bästa kandidaten.

  1. Largest Weight
  2. Highest Local Preference
  3. Locally originated
  4. Shortest AS-Path
  5. Lowest origin type (i < e < ?)
  6. Lowest MED (metric)
  7. eBGP > iBGP
  8.  Lowest IGP metric to neighbor (max. match check)
  9. Older route
  10. Lowest Router-ID

Det är med andra ord lite mer än vad vi är vana med från OSPF/EIGRP. 😉 Det är somliga av dessa värden vi senare kommer att modifiera för att ha möjlighet att påverka vilken väg vi önskar att trafiken skall ta.

BGP – eBGP Multihop

I tidigare inlägg har vi konstaterat att det är rekommenderat att använda sig av loopback-interface när vi sätter upp BGP-neighbors om vi har redundanta vägar. Något som inte är lika självklart är att det krävs ytterligare konfiguration för att sätta upp detta över eBGP tillskillnad mot iBGP.

iBGP

Vi testar först att sätta upp en enkel adjacency mellan loopback-adresserna inom ett AS (iBGP).

iBGP peer redundant

Konfig:

R1
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 !
 interface FastEthernet0/0
 ip address 172.16.0.1 255.255.255.252
 !
 interface FastEthernet0/1
 ip address 172.32.0.1 255.255.255.252
 !
 router bgp 100
 neighbor 13.37.0.1 remote-as 100
 neighbor 13.37.0.1 update-source Loopback0
 !
 ip route 13.37.0.1 255.255.255.255 172.16.0.2
 ip route 13.37.0.1 255.255.255.255 172.32.0.2
 ---
R2

 interface Loopback0
 ip address 13.37.0.1 255.255.255.255
 !
 interface FastEthernet0/0
 ip address 172.16.0.2 255.255.255.252
 !
 interface FastEthernet0/1
 ip address 172.32.0.2 255.255.255.252
 !
 router bgp 100
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback0
 !
 ip route 1.1.1.1 255.255.255.255 172.32.0.1
 ip route 1.1.1.1 255.255.255.255 172.16.0.1

Vilket ger följande när vi kör debug ip bgp all:

*Mar 1 00:18:01.267: BGP: 13.37.0.1 open active, local address 1.1.1.1
*Mar 1 00:18:01.295: BGP: 13.37.0.1 went from Active to OpenSent
*Mar 1 00:18:01.295: BGP: 13.37.0.1 sending OPEN, version 4, my as: 100, holdtime 180 seconds
*Mar 1 00:18:01.299: BGP: 13.37.0.1 send message type 1, length (incl. header) 45
*Mar 1 00:18:01.363: BGP: 13.37.0.1 rcv message type 1, length (excl. header) 26
*Mar 1 00:18:01.363: BGP: 13.37.0.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar 1 00:18:01.363: BGP: 13.37.0.1 rcv OPEN w/ OPTION parameter len: 16
*Mar 1 00:18:01.367: BGP: 13.37.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar 1 00:18:01.367: BGP: 13.37.0.1 OPEN has CAPABILITY code: 1, length 4
*Mar 1 00:18:01.367: BGP: 13.37.0.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar 1 00:18:01.367: BGP: 13.37.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 00:18:01.371: BGP: 13.37.0.1 OPEN has CAPABILITY code: 128, length 0
*Mar 1 00:18:01.371: BGP: 13.37.0.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar 1 00:18:01.371: BGP: 13.37.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 00:18:01.371: BGP: 13.37.0.1 OPEN has CAPABILITY code: 2, length 0
*Mar 1 00:18:01.371: BGP: 13.37.0.1 OPEN has ROUTE-REFRESH capability(new) for all address-families 
BGP: 13.37.0.1 rcvd OPEN w/ remote AS 100
*Mar 1 00:18:01.375: BGP: 13.37.0.1 went from OpenSent to OpenConfirm
*Mar 1 00:18:01.375: BGP: 13.37.0.1 went from OpenConfirm to Established
*Mar 1 00:18:01.375: %BGP-5-ADJCHANGE: neighbor 13.37.0.1 Up

Lätt som en plätt.. OPEN-message från R2 till R1 ser ut enligt följande:

iBGP TTL

R1#sh ip bgp neighbors 
BGP neighbor is 13.37.0.1, remote AS 100, internal link
 BGP version 4, remote router ID 13.37.0.1
 BGP state = Established, up for 00:05:52

Okej, inga problem där med andra ord. Kom dock ihåg att ändra update-source! BGP kräver att avsändar-adressen matchar med den neighbor-adress som är konfigurerad i den mottagande routern. Låt oss testa vad som händer när vi kör samma lösning men över eBGP.

eBGP

eBGP peer redundant

Konfig:

R1
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 !
 interface FastEthernet0/0
 ip address 172.16.0.1 255.255.255.252
 !
 interface FastEthernet0/1
 ip address 172.32.0.1 255.255.255.252
 !
 router bgp 100
 neighbor 13.37.0.1 remote-as 500
 neighbor 13.37.0.1 update-source Loopback0
 !
 ip route 13.37.0.1 255.255.255.255 172.16.0.2
 ip route 13.37.0.1 255.255.255.255 172.32.0.2
 ---
R2

 interface Loopback0
 ip address 13.37.0.1 255.255.255.255
 !
 interface FastEthernet0/0
 ip address 172.16.0.2 255.255.255.252
 !
 interface FastEthernet0/1
 ip address 172.32.0.2 255.255.255.252
 !
 router bgp 500
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback0
 !
 ip route 1.1.1.1 255.255.255.255 172.32.0.1
 ip route 1.1.1.1 255.255.255.255 172.16.0.1

En debug ip bgp all visar dock ingen aktivitet, ser inte heller något i wireshark märkligt nog (vilket jag själv blev lite förvånad över). Problemet är nämligen så att BGP vid ett eBGP-förhållande sätter TCP-paketens TTL till 1. Om du kollar det tidigare OPEN-meddelandet från exemplet från iBGP ovan kan vi se att TTL är satt till 255(!).

Då TTL endast är satt till 1 sker följande:

  1. R1 skickar sitt OPEN-message till R2 med TTL=1
  2. R2 tar emot OPEN-meddelandet på Fa0/0 eller Fa0/1
  3. R2 ser att destinationen är dess Lo0, men innan den skickar vidare paketet minskar den TTL med -1
  4. R2 upptäcker att TTL=0 och kastar därför paketet innan det vidarebefodrar det till loopback

BGP har infört en lösning en för detta kallad ebgp-multihop, vi konfar det enligt följande:

R1(config-router)#neighbor 13.37.0.1 ebgp-multihop ?
 <1-255> maximum hop count

I detta fall behöver vi sätta det till 2 för både R1 & R2:

neighbor 13.37.0.1 ebgp-multihop 2

Genast börjar det hända saker! 🙂

*Mar 1 00:48:15.535: BGP: 1.1.1.1 went from Idle to Active
*Mar 1 00:48:15.543: BGP: 1.1.1.1 open active delayed 28864ms (35000ms max, 28% jitter)
*Mar 1 00:48:44.407: BGP: 1.1.1.1 open active, local address 13.37.0.1
*Mar 1 00:48:44.463: BGP: 1.1.1.1 went from Active to OpenSent
*Mar 1 00:48:44.463: BGP: 1.1.1.1 sending OPEN, version 4, my as: 500, holdtime 180 seconds
*Mar 1 00:48:44.471: BGP: 1.1.1.1 send message type 1, length (incl. header) 45
*Mar 1 00:48:44.555: BGP: 1.1.1.1 rcv message type 1, length (excl. header) 26
*Mar 1 00:48:44.555: BGP: 1.1.1.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar 1 00:48:44.555: BGP: 1.1.1.1 rcv OPEN w/ OPTION parameter len: 16
*Mar 1 00:48:44.555: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar 1 00:48:44.555: BGP: 1.1.1.1 OPEN has CAPABILITY code: 1, length 4
*Mar 1 00:48:44.559: BGP: 1.1.1.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar 1 00:48:44.559: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 00:48:44.559: BGP: 1.1.1.1 OPEN has CAPABILITY code: 128, length 0
*Mar 1 00:48:44.559: BGP: 1.1.1.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar 1 00:48:44.559: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 00:48:44.563: BGP: 1.1.1.1 OPEN has CAPABILITY code: 2, length 0
*Mar 1 00:48:44.563: BGP: 1.1.1.1 OPEN has ROUTE-REFRESH capability(new) for all address-families 
BGP: 1.1.1.1 rcvd OPEN w/ remote AS 100
*Mar 1 00:48:44.563: BGP: 1.1.1.1 went from OpenSent to OpenConfirm
*Mar 1 00:48:44.563: BGP: 1.1.1.1 went from OpenConfirm to Established
*Mar 1 00:48:44.567: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

Kollar vi i wireshark kan vi se att detta OPEN-message ser lite annorlunda ut.

eBGP TTL

Man kan kanske tycka att det är konstigt att detta bara är ett problem när vi använder eBGP men samtidigt måste vi tänka över vilket användningsområde det har. Ett iBGP-adjacency kan sträcka sig över flera kontinenter för multinationella företag, men eBGP kommer du alltid sätta upp i en “border-router” mot din ISP.

BGP – The basics

BGP (Border Gateway Protocol) är tillskillnad från RIP/OSPF/EIGRP/ISIS ett External/Exterior Gateway Protocol och är just nu uppe i version 4 som släpptes redan 1994. Det främsta tillägget vid v4 var möjligheten att använda CIDR & Route aggregation (CIDR fanns inte ens som en RFC innan det släpptes i BGPv4). När behöver vi då använda oss av BGP? Här är ett exempel på några bra grundregler:

Use BGP if at least one of the following conditions exists:

  • The AS allows packets to transit through it to reach other autonomous systems
  • The AS has multiple connections to other autonomous systems
  • The flow of traffic entering and leaving the AS must be manipulated

When NOT to use BGP:

  • A single connection to the Internet or another AS
  • Lack of memory or processor power on routers to handle constant BGP updates
  • You have limited understanding of route filtering and the BGP path-selection process
  • Low bandwith between autonomous systems

Här är en väldigt sevärd video från en av skaparna av protokollet, Dr. Yakov Rekhter, där han berättar lite om historiken bakom BGP och annat matnyttigt från Googles Tech Talks:

BGP – Protocol Design

Basics

  • Använder sig av TCP (port 179)
  • Är ett “Path Vector Protocol”
  • Alla paket skickas som unicast
  • Till skillnad från IGPs använder sig BGP inte (endast) av metric för att räkna ut den bästa vägen
  • Neighbors måste konfigureras manuellt, behöver dock ej vara på samma subnät
  • Endast en TCP-session per neighbor (trots redundanta länkar)
  • Använder keepalives och hold timers (default 60/180 sec)
  • När neighbor-relation formas mellan två AS används External BGP (eBGP)
  • När neighbor-relation formas inom samma AS används Internal BGP (iBGP)
  • Användandet av Loopback-interface för neighbor-statements är rekommenderat när det finns redundanta länkar

Här finns förresten en bra förklaring av vad ett Autonomous System är. En full BGP routing table består i dagsläget av närmare 400,000 routes(!).

BGP_Table_growth.svg

Processer

BGP drivs av fyra processer:

  • BGP Open – Startar peering mot våra neighbors
  • BGP I/O – Förbereder / Behandlar BGP Updates & Keepalives
  • BGP Scanner – Kontrollerar next-hop addresser och bestämmer över vilka routes som skall annonnseras
  • BGP Router – Räknar ut “Best path”, hanterar routingförändringar

BGP Scanner startar periodvis för att verifiera att vi fortfarande kan nå next-hop addresser för routes i vår routing-table.  Detta kan leda till att andra processer som körs samtidigt (ex icmp) påverkas, trafik som färdas GENOM routern ska dock ej påverkas då det (bör) hanteras av CEF (Cisco Express Forwarding).

Tables

  • BGP Table
  • Neighbor Table
  • Routing Table

Precis som för ex. OSPF så sparas alla BGP prefix & Path Attributes i BGP Table. Routern utför sedan egna beräkningar över vilken route som är bäst och som i sin tur installeras i routing table. OBS – En stor skillnad mot just OSPF är dock att BGP endast annonserar den bästa routen till sina neighbors för en viss destination och bortser från alla övriga möjliga vägar den eventuellt känner till.

BGP Message types

De message-types som BGP använder sig av för att upprätta neighbor relations och utbyta routing-information är följande:

  • Open – Skickas efter vi manuellt konfigurerat en neighbor och en TCP-session har etablerats och kan liknas det Hello-paket OSPF/EIGRP skickar.
  • Update – Används för att utbyta routing information
  • Keepalive – Används för att upprätthålla neighbor-sessionen och resettar holdtimern
  • Notification – Används när ett fel inträffat och resettar neighbor-sessionen

Lås oss använda oss av följande topologi och titta närmare på dessa paket:

bgp basics

Open-message

BGP’s Open-message innehåller vissa parametrar (där vissa måste matchas med den angivna neighborn för att en adjacency skall bildas), dessa är:

  • Version (8-bit field) – BGP Version nummer (2,3 eller 4). Försöker du peera med en neighbor som använder sig av en tidigare version nekas Open-paketet, routern kommer istället försöka skicka med en äldre version (3), paketet accepteras inte förrän versionerna stämmer överens. BGP är därmed bakåtkompitabelt med äldre versioner, men oddsen att du skall träffa på detta är väl mer eller mindre obefintligt nu för tiden då v4 släpptes redan 1994(!)
  • My autonomous system (16-bit field) – Avsändarens Autonomous System-nummer
  • Hold Time (16-bit field) – Om Hold Timer skiljer sig används den lägst angivna tiden av båda, default hos cisco är 180 sek. Kan sättas till 0, keepalive kommer då ej att skickas.
  • BGP Identifier (32-bit field) – Avsändarens Router-ID
  • Optional Parameters- För att annonsera support för “optional capabilites”, ex. authentisering, multiprotocol support, route refresh m.m)

Avsändarens ip-adress & AS-nummer måste matchas med det neighbor-statement den mottagande routern har samt ev. lösenord om autentisering aktiverats, router-id får inte heller vara samma på de båda routrarna.

Nedan visar ett Open-paket skickat från R5 till R1:

open packet

Router-ID

BGP väljer sitt Router-ID precis som OSPF enligt följande princip:

  1. Om vi använt kommandot bgp router-id rid
  2. Den högsta Loopback-adressen vars interface är Up/Up
  3. Det högsta adressen av routerns alla övriga interface och som är Up/Up

Update-message

Innehåller information om en specifik AS-path och all dess tillhörande routing-information med exempelvis vilka nät som finns nåbara inom detta, finns flera paths skickas det ett specifikt Update-paket för varje path.

Kan innehålla följande fält:

  • Withdrawn Routes – En lista med adresser som skall tas bort från BGPs routing process (ej längre nåbara etc)
  • Path attributes – AS-Path, Origin, Local Preference
  • Network Layer Reachability Information – Innehåller en lista med ip-adress prefix som kan nås via denna AS-path

Om vi utökar vår topologi och annonserar nätet 5.5.5.0/24 från R5 och 6.6.6.0/24 från R6 in till BGP kan vi se följande Update-paket skickat från R1 till R5:

update packet

update packet wireshark

Neighbor-states

BGP har även fem olika states den genomgår innan vi har full adjacency (Established) mellan två neighbors, detta kan liknas vid OSPF-processen där vi går från 2Way-state till Exstart-state osv.

  • Idle – Vi har konfigurerat en neighbor men BGP har inte initierats ännu
  • Connect – BGP väntar på att en TCP-session ska upprättas
  • Active – TCP-sessionen är upprättad men ingen BGP-information har skickats ännu
  • OpenSent – Open-paket skickat, TCP-sessionen är etablerad men inget Open-paket har mottagits
  • OpenConfirm – Open-paket är både skickat & mottaget, TCP-sessionen är etablerad. Routern väntar nu på ett BGP Keepalive-paket för att bekräfta att alla neighbor-relaterade parametrar matchades, eller ett Notification-paket som informerar om något fel inträffat (parameter mismatch t.ex.)
  • Established – Alla neighbor-parametrar accepterades och vi har nu full neighbor adjacency. Routern börjar nu skicka BGP Update-paket.

Vi kan verifiera detta genom kommandot sh ip bgp summary eller sh ip bgp neighbors.

R5#sh ip bgp summary
BGP router identifier 5.5.5.5, local AS number 100
BGP table version is 5, main routing table version 5
2 network entries using 240 bytes of memory
2 path entries using 104 bytes of memory
3/2 BGP path/bestpath attribute entries using 372 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 772 total bytes of memory
BGP activity 3/1 prefixes, 3/1 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.51.1 4 500 20 20 5 0 0 00:16:00 1

R5#sh ip bgp neighbors 
BGP neighbor is 172.16.51.1, remote AS 500, external link
 BGP version 4, remote router ID 1.1.1.1
 BGP state = Established, up for 00:16:33
 Last read 00:00:32, last write 00:00:32, hold time is 180, keepalive interval is 60 seconds
 Neighbor capabilities:
 Route refresh: advertised and received(old & new)
 Address family IPv4 Unicast: advertised and received
 Message statistics:
 InQ depth is 0
 OutQ depth is 0
 Sent Rcvd
 Opens: 1 1
 Notifications: 0 0
 Updates: 1 1
 Keepalives: 19 19
 Route Refresh: 0 0
 Total: 21 21
 Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
 BGP table version 5, neighbor version 5/0
 Output queue size: 0
 Index 1, Offset 0, Mask 0x2
 1 update-group member
 Sent Rcvd
 Prefix activity: ---- ----
 Prefixes Current: 1 1 (Consumes 52 bytes)
 Prefixes Total: 1 1
 Implicit Withdraw: 0 0
 Explicit Withdraw: 0 0
 Used as bestpath: n/a 1
 Used as multipath: n/a 0
Outbound Inbound
 Local Policy Denied Prefixes: -------- -------
 Bestpath from this peer: 1 n/a
 Total: 1 0
 Number of NLRIs in the update sent: max 1, min 1
Connections established 1; dropped 0
 Last reset never
Connection state is ESTAB, I/O status: 1, unread input bytes: 0 
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 172.16.51.5, Local port: 179
Foreign host: 172.16.51.1, Foreign port: 27320
Connection tableid (VRF): 0
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x3F7670):
Timer Starts Wakeups Next
Retrans 21 0 0x0
TimeWait 0 0 0x0
AckHold 20 17 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0
iss: 580665860 snduna: 580666319 sndnxt: 580666319 sndwnd: 15926
irs: 414342032 rcvnxt: 414342486 rcvwnd: 15931 delrcvwnd: 453

SRTT: 282 ms, RTTO: 429 ms, RTV: 147 ms, KRTT: 0 ms
minRTT: 12 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle
IP Precedence value : 6
Datagrams (max data segment is 1460 bytes):
Rcvd: 24 (out of order: 0), with data: 21, total data bytes: 453
Sent: 39 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 21, total data bytes: 458
 Packets received in fast path: 0, fast processed: 0, slow path: 0
 Packets send in fast path: 0
 fast lock acquisition failures: 0, slow path: 0

Vi kan även kontrollera att TCP-sessionen är igång genom kommandot:

R5#sh tcp brief
TCB Local Address Foreign Address (state)
66B535F4 172.16.51.5.179 172.16.51.1.27320 ESTAB

I den tidigare posten BGP – Internal BGP & Transit-Areas  kan du se flera exempel på hur vi konfigurerar neighbor-relationships.

Cisco’s Enterprise Definitioner

I det fall vi behöver använda oss av BGP benämner Cisco nätmodellerna enligt följande för “Enterprise Customers” (vilket CCNP Route inriktar sig på):

Single Homed – 1 länk per ISP, 1 ISP
Dual Homed – 2+ länkar per ISP, 1 ISP
Single Multihomed – 1 länk per ISP, 2+ ISPs
Dual Multihomed – 2+ länkar per ISP, 2+ ISPs

Single Homed

singlehomed

När vi endast har en länk mellan vårat företag och ISP. Här finns det endast en möjlig nexthop-adress för alla externa adresser och det finns med andra ord ingen egentlig anledning att använda oss av BGP. De vanligaste lösningarna innebär att vi antingen:

  • Vi använder en statisk default route i vår CPE som pekar på ISP-A,  ISP-A konfigurerar i sin tur en statiskt route för vårat publika nät
  • Vi använder oss av BGP, men ISP-A annonserar endast en default-route till oss, och vi annonserar vårat publika nät till ISP-A

Båda dessa lösningar har dock en nackdel att interna paket vars destination är någonstans internt på nätverket men som inte hittar en matchande route, kommer forwardas ut på “internet” via vår default-route innan vi når en unreachable hos ISP-A.  Cisco rekommenderar därför att vi skapar en “discard route” för våra interna nät, genom att sätta en statisk route för exempelvis 10.0.0.0/8-nätet som pekar på Null0.

Dual Homed

dualhomed

dualhomed2

När vi har två upplänkar till en och samma ISP kallas detta Dual homed. Här har vi nu möjlighet att influera vilken väg vi vill att paket skall ta, men om vi endast vill utföra något av följande:

  • Föredra en uppkoppling för samtliga destinationer, men om denna länk går ner så skall trafiken slå över till den andra länken
  • Lastbalansera 50/50 mellan de båda länkarna, men om en länk går ner så skall trafiken slå över till den andra länken

I båda dessa fallen duger det gott och väl med användandet av statiska routes!

Om vi istället vill specificera vilken länk vi ska använda för specifika destinationer kommer BGP in i bilden. Låt oss bygga vidare lite på vår topologi för att enklare förklara:

dualhomed google

Vi kan här se att den snabbaste vägen för att ta oss till Google är via ISP-A2, istället för att gå omvägen via ISP-A1 och sedan genom “molnet” för att tillslut hamna hos Google. För att lyckas med detta måste vi modifiera BGPs “Path Attributes” för att internt få vägen via CustomerABC-2 mer attraktiv. Detta kommer dock bli en en egen post då det är ett väldigt brett ämne.. Något som är värt att notera är att om vi har ett core-nät bakom våra ABC-routrar är det mycket möjligt att vi även behöver använda oss av iBGP där också för att undvika eventuella routing-loopar som annars kan uppstå.

Single Multihomed

singlemultihomed2

singlemultihomed

Dual Multihomed

dualmultihomed

Partial & Full Updates

En ISP ger i de flesta fall tre olika möjligheter för att utbyta BGP-information. Som vi tidigare nämnt börjar en full BGP table nu närma sig 450,000 routes vilket ställer enorma krav på hårdvaran. Ska du dessutom peera med två ISPs med en och samma router kommer den ha en bgp table per neighbor, det blir dvs 900,000 routes totalt som routern ska orka hantera. 🙂 De alternativ som finns är:

  • Default route only – Inte så svår att lista ut, ISPn annonserar endast en default-route via BGP
  • Full updates – ISPn annonserar hela BGP tablen
  • Partial Updates – ISPn annonserar endast specifikt valda prefix samt en default-route via BPG

Partial Updates ger fördelen att vi har möjligheten att välja en “bättre” route för ett specifikt nät vi är intresserad av utan att behöva spara alla övriga routes i vår egen utrustning.