BGP routing ISP környezetben Kinczli Zoltán Synergon Rt.

Exterior gateway protocol BGP refresh Exterior gateway protocol 179/tcp Path Vector Distance Vector + Path AS Path: loop detection Best Path választás „A” legjobb út csak ezt hírdeti inkrementális update-ek external és internal BGP internal: AS path nem változik, nincs loop detection > full mesh prefix/mask, attribútumok NH, AS-Path, origin, MED, loc-pref, community, aggregator

BestPath BestPath választás „érvényes” utak közül szinkronizáció NH elérhető nincs AS loop enforce-first esetén egyező első AS „hop” nem received-only „A” legjobb út: 1, azaz egy „install” RIB/CEF hírdet lokális és eBGP-ből: mindenkinek iBGP-ből: csak eBGP peer felé iBGP peer felé nem de multipath: 1-16 eBGP, iBGP, eiBGP

BestPath algoritmus NSWLLAOMENOR Never NextHop Sing synchronization Where weight Lemmings local-preference Levitate locally originated As AS-Path Ostriches origin Mediate MED Except eBGP vs. iBGP Near nearest neighbor Old oldest route Redmond RID

E(xterior)GP vs I(nterior)GP EGP – IGP E(xterior)GP vs I(nterior)GP IGP: AS-en belül gyors konvergencia limitált prefix-szám, adatbázis OSPF, ISIS, EIGRP EGP AS-ek között robusztus, pld. 170k prefix ! BGP legyen az EGP és az IGP független egymástól takarjuk el kifelé a belső változásokat változások hatása ne „csatolódjon”

ISP design IGP - OSPF, ISIS, EIGRP EGP - BGP v4 csak az „infrastruktúra” címeket hirdeti Internet és előfizetői prefixeket nem Cél: minimalizálni az IGP adatbázist nagy stabilitás, gyors konvergencia EGP - BGP v4 iBGP: néhány/összes internet prefix előfizetői prefixek eBGP prefix exchange a peer-ekkel routing policy

BGP „külső” prefixek elérhetőse NextHop EGP - IGP BGP „külső” prefixek elérhetőse uplink, peering, downlink (előfizető) NextHop eBGP: a peer címe iBGP, RR, confederation: amit az eBGP peer „mondott” 3rd party NH multiaccess media (eth, frame-relay) set ip next-hop peer-address ingress és egress next-hop-self

EGP – IGP interakció External prefix info NextHop elérhetősége BGP-ből > NextHop attribútum NextHop elérhetősége IGP-ből IGP-ben: passive interface Javasolt: NH tracking miatt IGP-ben: redistribute connected BGP-ben: next-hop-self Rekurzió BGP update: prefix(NH) IGP Lookup NH-ra > NH of NH Prefix(NH of NH)

BGP timerek Session timers Process timers Keepalive (60s), hold (180s), 3:1 arány javasolt iBGP: ahol nincs közvetlen link 3 perc a hiba detektáláa fast-external-fallover Lokális, bontja a BGP sessiont, ha a fizikai i/f down Process timers Scan timer (60s) Local originated, NH check, conditional adv, dampening Tranzit updatekre NINCS hatása Minimum Advertisement Timer (eBGP 30s, iBGP 5s) 1 update per MAT interval

Mit hirdetünk „originate” network parancs network 194.149.60.0 mask 255.255.254.0 CIDR kell: megegyező (prefix és mask) IGP route connected, statikus vagy dinamikus statikus: pull-up route (tipikusan null0 i/f-re) permanent: nincs flap redistribute statikus: single-homed customer Szűrés (defa, priv, garbage, etc…)

Mit hirdetünk „originate” aggregate kell: more specific a BGP tablában opciók summary-only, as-set advertise-map suppress-map, unsuppress-map, attribute-map !!! ISP: no auto-summary !!! default generálás default-information originate kell: default a BGP táblában network 0.0.0.0 kell default a routing táblában pld statikus pull-up null0) neighbor x.x.x.x default-originate

Ne tedd Don’t distribute BGP into IGP Don’t distribute IGP into BGP Nincs IGP aki 170k prefixet „kibír” Minden core routeren BGP tranzit: megőrizni az attribútumokat Don’t distribute IGP into BGP ??? Ne legyen az IGP-ben előfizetői prefix Az IGP az ISP core lelke Előfizető eszköze ne „vegyen részt” az IGP-ben Kellene distribute IGP into BGP Különben elveszíted a skálázhatóságot !

Tedd iBGP: loopback (/32) címek között iBGP full mesh BGP BGP NH Független a topológiától iBGP full mesh Redundáns RR BGP no auto-summary external distance is IGP distance felett, pld 200 aggregálj „manuálisan”, CIDR BGP NH peering kapcsolatok IGP-ben passive interface Originate prefixes into BGP in CORE Blackhole, ha leszakadó POP/peering pont továbbra is hirdeti

Tedd Tedd „manuális” aggregálás prefix downstream irányból csak az allokált address block-ot prefix downstream irányból Csak az assigned prefixeket prefix upstream irányból rendszerint felesleges kivételek ha mégis kell, szűrni: rfc1918, saját, /24-nél hosszabb upstreamtől kérj default-ot egy/pár prefix-et, ami(ke)t default-ként használhatsz ip default-netwok VAGY rekurzív statikus default

Loadbalancing Control Plane Data Plane Alkalmazás Routing protokol „párhuzamos” utak a RIB/FIB-be Mi a párhuzamos: routing protokol specifikus Data Plane Csomagtovábbítás RIB/FIB alapján CEF: Per-packet, per-destination Alkalmazás Redundáns CORE, IGP értelemben párhuzamos linkekkel pld: n*2Mbps vonal ugyanazon szolgáltató ugyanazon routeréhez különböző routereihez

eBGP loadbalancing AS 301 AS 201 Azonos, external prefixek között Weight, loc-pref, AS-Path origin, MED, NH IGP(cost) Csak a peering router balance-ol iBGP-n már csak egy utat hirdet RR már csak egy utat reflektál IGP megoszthatja a terhelést rekurzió a NH-ra AS 301 D C 193.1.0.0/16 Next-hop: C 193.1.0.0/16 Next-hop: D router bgp 201 maximum-path 2 A 193.1.0.0/16 Next-hop: A B AS 201

eBGP loadbalancing 1 eBGP kapcsolat N eBGP kapcsolat AS 201 loopback i/f-ek között eBGP multihop ! loopback elérhetőség Statikus Billegő i/f ? Up/up de csomag nincs ? IGP AS-en kívüli kapcsolat IGP az előfizetővel? N eBGP kapcsolat fizikai i/f címken AS 300 router bgp 300 maximum-path 2 D router bgp 201 maximum-path 2 A AS 201

iBGP loadbalancing AS 201 Azonos, internal prefixek között show ip bgp Weight, loc-pref, AS-Path origin, MED, NH IGP(cost) show ip bgp 1 bestpath a többi multipath RR Csak a bestpath-t hirdeti Next-hop-self on RR De RR a forwarding pathban 193.1.0.0/16 via eBGP C D 193.1.0.0/24 Next-hop: D 193.1.0.0/24 Next-hop: C A AS 201 router bgp 201 neighbor D remote-as 201 neighbor C remote-as 201 maximum-paths ibgp 2

Loadbalancing – loadsharing párhuzamos utak között Párhuzamos: routing protokol „szerint” Pld: egyenlő IGP cost alapján automatikus pld: multihoming u.azon ISP felé Loadsharing „alternatív” utak között Topológiai, logikai értelemben A routing protokol szerint nem „párhuzamosak” Nem automatikus Policy alapján megtervezett Pld: multihoming két különböző ISP-hez Nem lehet loadbalancing BGP értelemben, mert eltérő AS-Path

Multihoming Multihoming Miért jó a multihoming? Policy Egynél több external kapcsolat Ha BGP, akkor kell AS private, public Miért jó a multihoming? Redundancia, rendelkezésre állás Policy prefix-list prefixet szűr filter-list ASN-t szűr route-map írja le a policyt loc-pref, MED, AS Path, communities

Kiinduló feltételezések Multihoming Kiinduló feltételezések Az assigned block-ot KELL hirdetni More specifiket LEHET hirdetni de nincs garancia, hogy elfogadják RIR minimum allocations Pld ha /21 a /22-es prefixeket „legálisan” szűrhetik > NetPolice NetPolice filter Hatása a legális multihomingra 

CIDR report http://www.cidr-report.org/ 171k prefix 20,000 AS Kb 60k more specific 20,000 AS Majd fele 1 „prefixes” Átlag 8 pref/AS

Multihoming Stub network Multihomed stub Nem kell BGP Stat defa to upstream Loadbalancing „párhuzamos” utak között u.azon ISP u.azon routeréhez Upstream hirdet Routing policy Az upstream konrollálja Multihomed stub BGP, private AS Loadbalancing vagy loadharing BGP-vel

Multihoming „igazi” multihomed Több scenario External link típusa Több link egy ISP-hez is backup-only vagy loadshared Több external kapcsolat External link típusa Tranzit A teljes internet elérhetőségét szolgáltatja Peer Megállapodás alapján, csak bizonyos prefixeket pld: csak co-location és előfizető

Multihoming Full view hiedelem Full view Gondolkodjunk Ha multihome, akkor full view kell Full view $$$ Memória Main CPU DRAM VIP/LC/DFC DRAM is, mert CEF tábla Full view = nyers erő Gondolkodjunk Mi a multihoming célja? Backup-only vagy párhuzamos használat, terhelés-megosztással? Mit akarunk elosztani? Download, upload

Multihoming - stub Address space Backup only Provider PA BGP, private ASN ISP remove private, proxy-aggregate Assigned prefix hirdetése mindkét linken Backup linken Megnövelt MED (backup az ingress forgalom számára) Csökkentett loc-pref (backup az egress forgalom számára)

Multihoming - stub Address space Loadsharing Provider PA BGP, private ASN ISP remove private, proxy-aggregate Assigned prefix hirdetése mindkét linken Egymás backupjai Split assigned, pld /19-et két /20-ra Ingress load-sharing: egy link – egy /20 Azonos sebességű utakat tételezve fel Adressing, split változtatása Egress load-sharing: Kell-e megosztani az egress forgalmat? Default from upstream, iBGP info, IGP cost alapján

Multihoming - nem stub BGP, public ASN Address space Lehet Private AS: provider együttműködés de „inconsistent” lesz, nem szép Address space mindkét providertől: PA assigned RIR: allocated PI Példában: /19

Multihoming – nem stub Backup only /19 prefix mindkét uplink felé Ingress Backup linken AS-Path prepend Egress Accept default, backup csökentett loc-pref

Multihoming – nem stub Loadharing 1. Split /19 > két /20 Ingress loadsharing Advertise /19 mindkét linken Advertise /20 egy-egy linken Netpolice Uplinkek közti együttműködés ‘more specific’-et peering kapcsolatokon is mert leghosszabb prefix győz, nem összehasonlíthatók hiába loc-pref

Multihoming – nem stub Loadharing 2. Ingress loadsharing Advertise /19 mindkét linken Egyiken prepend n-szer Advertise /20 egy linken Hangolás Prepend n, subprefix hossza Netpolice Uplinkek közti együttműködés More specifiket peering kapcsolatokon is Leghosszabb prefix győz Hiába loc-pref

Eddig ingress loadsharing Egress loadsharing? ISP multihoming Eddig ingress loadsharing Egress loadsharing? Téveszme: full view kell „nagy” router kell a BGP bonyolult Stratégiák Traffic engineering: netflow Merre megy a forgalmunk, dest ASN? Upstream-ek és közvetlen szomszédaik

Helyi peering, internet exchange (IXP) ISP multihoming Tier1/2 uplink Regionális uplink Helyi peering, internet exchange (IXP) Pld BIX

ISP multihoming Hirdetés Announce /19-et minden linken Accept Partial Default/partial from uplinks Partial from regional uplink All from local peers Partial ^200_[0-9]+$ vagy ^200_[0-9]+_[0-9]+$ Loc-pref on default Regional < uplink