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 – Improving effiency

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