GP Multihoming: n Enterprise View 2008 isco Systems, Inc. ll rights reserved. isco Public 2 1
GP Multihoming Techniques Multihoming asics Single Provider Multiple Providers Using Policy Provider 1 The Internet Provider 2 192.2.34.0/24 2008 isco Systems, Inc. ll rights reserved. isco Public 3 Multihoming asics 2008 isco Systems, Inc. ll rights reserved. isco Public 4 2
Multihoming asics efinition Policies Used in this Presentation Why Multihome? ssigned Netblock Filters 2008 isco Systems, Inc. ll rights reserved. isco Public 5 Multihoming efinition More than one link external to the local network Two or more links to the same ISP Two or more links to different ISPs Usually two external facing routers One router gives link and provider redundancy only 2008 isco Systems, Inc. ll rights reserved. isco Public 6 3
Policies Used in this Presentation Three basic principles for isco IOS configuration examples throughout presentation: prefix-lists to filter prefixes filter-lists to filter SNs route-maps to apply policy 2008 isco Systems, Inc. ll rights reserved. isco Public 7 Policies Used in this Presentation Local preference Outbound traffic flows Metric (ME) Inbound traffic flows (local scope) S-PTH prepend Inbound traffic flows (Internet scope) ommunities Specific inter-provider peering 2008 isco Systems, Inc. ll rights reserved. isco Public 8 4
Why Multihome? Single exit point, single provider The Internet No need for GP Point static default to upstream ISP Upstream ISP advertises stub network Policy confined within upstream ISP s policy 192.2.34.0/24 2008 isco Systems, Inc. ll rights reserved. isco Public 9 Why Multihome? Multiple exit points, single provider Use GP (not IGP or static) to loadshare Use private S (SN > 64511) Upstream ISP advertises stub network Policy confined within upstream ISP s policy The Internet Provider 2008 isco Systems, Inc. ll rights reserved. isco Public 10 5
Why Multihome? Many Situations Possible Multiple sessions to same ISP Secondary for backup only Load-share between primary and secondary Selectively use different ISPs Provider 1 The Internet 192.2.34.0/24 Provider 2 2008 isco Systems, Inc. ll rights reserved. isco Public 11 Why Multihome? Redundancy One connection to Internet means the network is dependent on: Local router (configuration, software, hardware) WN media (physical failure, carrier failure) Upstream service provider (configuration, software, hardware) Reliability usiness critical applications demand continuous availability Lack of redundancy implies lack of reliability implies loss of revenue 2008 isco Systems, Inc. ll rights reserved. isco Public 12 6
Why Multihome? Supplier iversity Many businesses demand supplier diversity as a matter of course Internet connection from two or more suppliers With two or more diverse WN paths With two or more exit points With two or more international connections Two of everything 2008 isco Systems, Inc. ll rights reserved. isco Public 13 Why Multihome? Note Well Using multiple providers does not guarantee circuit diversity There is much backhauling in the world today There is much cross leasing of facilities Fate sharing is still an issue So, be careful out there Provider 1 Single O, Multiple Racks The Internet 192.2.34.0/24 Provider 2 Single Fiber, Multiple Wavelengths 2008 isco Systems, Inc. ll rights reserved. isco Public 14 7
Why Multihome? Leverage: Playing one ISP off against the other for: Service quality Service offerings vailability Not really a reason, but oft quoted 2008 isco Systems, Inc. ll rights reserved. isco Public 15 Why Multihome? Summary: Multihoming is easy to demand as requirement for any service provider or end-site network ut what does it really mean: In real life? For the network? nd how do we do it? 2008 isco Systems, Inc. ll rights reserved. isco Public 16 8
ssigned Netblock Filters You must announce assigned address block to Internet You may also announce subprefixes reachability is not guaranteed urrent RIR minimum allocation is /21 Several ISPs filter RIR blocks on this boundary Several ISPs filter the rest of address space according to the IN assignments This activity is called net police by some 2008 isco Systems, Inc. ll rights reserved. isco Public 17 ssigned Netblock Filters The RIRs publish their minimum allocation sizes at: frini: PNI: RIN: LNI: RIPE N: www.afrinic.net/docs/policies/afpol-v4200407-000.htm www.apnic.net/db/min-alloc.html www.arin.net/reference/ip_blocks.html lacnic.net/en/registro/index.html www.ripe.net/ripe/docs/smallest-alloc-sizes.html IN publishes the address space it has assigned to endsites and allocated to the RIRs: www.iana.org/assignments/ipv4-address-space Several ISPs use this published information to filter prefixes on: What should be routed (from IN) The minimum allocation size from the RIRs 2008 isco Systems, Inc. ll rights reserved. isco Public 18 9
ssigned Netblock Filters Meant to punish ISPs who pollute the routing table with specifics rather than announcing aggregates Impacts legitimate multihoming especially at the Internet s edge Impacts regions where domestic backbone is unavailable or costs $$$ compared with international bandwidth Hard to maintain requires updating when RIRs start allocating from new address blocks on t filter based on assigned netblocks unless consequences are well understood and you are prepared to keep the list current onsider using the Project ymru or another reputable bogon GP feed: http://www.cymru.com/gp/bogon-rs.html 2008 isco Systems, Inc. ll rights reserved. isco Public 19 Single Provider 2008 isco Systems, Inc. ll rights reserved. isco Public 20 10
Single Provider Using Private utonomous Systems One Link s ackup Load Sharing 2008 isco Systems, Inc. ll rights reserved. isco Public 21 Using Private utonomous Systems pplications n ISP with customers multihomed on their backbone (RF2270) corporate network with several regions but connections to the Internet only in the core -or- -or- Within a GP confederation 65001 192.2.32.0/24 1880 192.2.34.0/24 192.2.32.0/22 {1880} 192.2.35.0/24 65002 192.2.33.0/24 65003 2008 isco Systems, Inc. ll rights reserved. isco Public 22 11
Using Private utonomous Systems Private SNs must be removed from all prefixes announced to the public Internet Include configuration to remove private SNs in the egp template s with RF1918 address space, private SNs are intended for internal use They should not be leaked to the public Internet isco IOS neighbor x.x.x.x remove-private-s 2008 isco Systems, Inc. ll rights reserved. isco Public 23 One Link as ackup Use one link as the primary, the other as a backup The Internet One link is large, the other small Provider ggregation One link is fixed bandwidth, the other is charged per unit of traffic Provider It s best to use a private S in this situation Primary Link Secondary Link No need for the upstreams on the Internet to know details about the connection The provider might aggregate towards the Internet at their edge Private S 2008 isco Systems, Inc. ll rights reserved. isco Public 24 12
One Link as ackup ccept only defaults on both links The Internet Use local preference to prefer the primary default over the secondary Use internal IGP metrics to draw traffic to the primary link dvertise the same address space on both links efault Only Provider Same Route Provider Strips Private S efault Only sk the provider to prefer one link over the other using local preference Using conditional advertisement is another option Local Pref Prefers IGP Metric Prefers 2008 isco Systems, Inc. ll rights reserved. isco Public 25 One Link as ackup router bgp 65534 network 121.10.0.0 mask 255.255.224.0 neighbor 122.102.10.2 remote-as XXX neighbor 122.102.10.2 description primary-link neighbor 122.102.10.2 prefix-list aggregate out neighbor 122.102.10.2 prefix-list default in ip prefix-list aggregate permit 121.10.0.0/19 ip prefix-list default permit 0.0.0.0/0 ip route 121.10.0.0 255.255.224.0 null0 Primary Link The Internet Provider Secondary Link IGP Metric Prefers 2008 isco Systems, Inc. ll rights reserved. isco Public 26 13
One Link as ackup router bgp 65534 network 121.10.0.0 mask 255.255.224.0 neighbor 122.102.10.6 remote-as XXX neighbor 122.102.10.6 description backup-link neighbor 122.102.10.6 prefix-list aggregate out neighbor 122.102.10.6 route-map backup-out out neighbor 122.102.10.6 prefix-list default in neighbor 122.102.10.6 route-map backup-in in ip prefix-list aggregate permit 121.10.0.0/19 ip prefix-list default permit 0.0.0.0/0 ip route 121.10.0.0 255.255.224.0 null0 route-map backup-out permit 10 match ip address prefix-list aggregate set metric 10 route-map backup-out permit 20 route-map backup-in permit 10 set local-preference 90 Primary Link The Internet Provider IGP Metric Prefers Secondary Link 2008 isco Systems, Inc. ll rights reserved. isco Public 27 Load Sharing egp Multihop If you have multiple links between the same pair of routers Use egp multihop egp to loopback addresses egp prefixes learned with loopback address as next hop The Internet Provider router bgp 65534 neighbor 1.1.1.1 remote-as XXX neighbor 1.1.1.1 ebgp-multihop 2 ip route 1.1.1.1 255.255.255.255 serial 1/0 ip route 1.1.1.1 255.255.255.255 serial 1/1 2008 isco Systems, Inc. ll rights reserved. isco Public 28 14
Load Sharing egp Multihop One major problem If one link fails the multihop session can switch to the alternate path Try and avoid use of egpmultihop unless: It s absolutely necessary or Load sharing across multiple links Original Path The Internet Provider Path When -> Fails Many ISPs discourage its use 2008 isco Systems, Inc. ll rights reserved. isco Public 29 Load Sharing igp Multihop If you have Multiple igp sessions to the same provider (peering S) The Internet Terminating in the same router You can also use igp multipath Provider router bgp 201 neighbor 1.1.2.1 remote-as XXX neighbor 1.1.2.5 remote-as XXX neighbor 1.1.2.9 remote-as XXX maximum-paths 3 2008 isco Systems, Inc. ll rights reserved. isco Public 30 15
Load Sharing ontrolling Traffic Through nnouncements The most common case, however, is multiple connections at multiple points You probably don t normally buy circuits to leave them idle Even if the circuits have unequal capacity, you want to use both of them The Internet Provider 2008 isco Systems, Inc. ll rights reserved. isco Public 31 Load Sharing ontrolling Traffic Through nnouncements Outbound Traffic Flow ccept only default routes Run igp between the edge GP speakers for backup llow each egp speaker to prefer its local default ontrol traffic into the edge using IGP metrics The Internet Provider efault Only igp IGP Metric to djust Inbound Traffic 2008 isco Systems, Inc. ll rights reserved. isco Public 32 16
Load Sharing ontrolling Traffic Through nnouncements Inbound Traffic Flow dvertise the full block out both paths Split the block, and advertise more specifics out different paths djust where you split the block and advertise to achieve the utilizations you want Full lock + Specifics The Internet Provider igp Full lock + Specifics 2008 isco Systems, Inc. ll rights reserved. isco Public 33 Load Sharing ontrolling Traffic Through nnouncements ssume you have Router : 10.1.0.0/23 Router : 10.1.2.0/23 Pulls half the destinations in through one link, and the other half in through the other link 10.1.0.0/23 The Internet Provider igp 10.1.2.0/23 2008 isco Systems, Inc. ll rights reserved. isco Public 34 17
Load Sharing ontrolling Traffic Through nnouncements If the -> link is still taking more traffic... Router : 10.1.0.0/24 Router : 10.1.1.0/24 10.1.2.0/23 Pulls three quarters of the destinations in through one link, and the other quarter in through the other link 10.1.0.0/23 The Internet Provider igp 10.1.2.0/24 10.1.2.0/23 2008 isco Systems, Inc. ll rights reserved. isco Public 35 Load Sharing ontrolling Traffic Through nnouncements If the provider Is aggregating the space you re using outbound nd doesn t care what prefix lengths you advertise in Then, you have a lot of flexibility with this technique Not all providers will support this, though Make certain to ask before diving too deep into long length prefixes 10.1.0.0/23 The Internet Provider igp ggregate Here 10.1.2.0/24 10.1.2.0/23 2008 isco Systems, Inc. ll rights reserved. isco Public 36 18
Load Sharing ontrolling Traffic Through nnouncements router bgp 65534 network 10.1.0.0 mask 255.255.224.0 network 10.1.0.0 mask 255.255.240.0 neighbor x.x.x.x remote-as XXX neighbor x.x.x.x prefix-list morespecifics out ip prefix-list morespecifics permit ip prefix-list morespecifics permit 10.1.0.0/23 ip route 10.1.0.0 255.255.240.0 null0 ip route 10.1.0.0 255.255.224.0 null0 router bgp 65534 network 10.1.0.0 mask 255.255.224.0 network 10.1.1.0 mask 255.255.240.0 neighbor x.x.x.x remote-as XXX neighbor x.x.x.x prefix-list morespecifics out ip prefix-list morespecifics permit ip prefix-list morespecifics permit 10.1.2.0/23 ip route 10.1.0.0 255.255.240.0 null0 ip route 10.1.0.0 255.255.224.0 null0 10.1.0.0/23 The Internet Provider igp 10.1.2.0/24 10.1.2.0/23 2008 isco Systems, Inc. ll rights reserved. isco Public 37 Load Sharing Why Not S Path Prepend or ME? If you are only advertising one prefix The provider only chooses one path out to your network The provider only advertises one path to their upstreams S path prepend and ME require multiple advertisements In which case, you can use the techniques already described Short S Path Only One dvertisement Upstream 1 Upstream 2 Provider Only One of Two Will e hosen Long S Path 2008 isco Systems, Inc. ll rights reserved. isco Public 38 19
Multiple Providers 2008 isco Systems, Inc. ll rights reserved. isco Public 39 Multiple Providers Using Private utonomous Systems One Link as ackup Inbound Load Sharing Outbound Load Sharing 2008 isco Systems, Inc. ll rights reserved. isco Public 40 20
Using Private utonomous Systems Provider 1 and 2 both strip the private S t upstream providers, this looks like the route originated in two different autonomous systems Some providers might filter for this s GP security comes on line, this may be problematic Talk to your providers before doing this 10.1.1.0/24 {Provider 1} Upstream 10.1.1.0/24 {Provider 2} Provider 1 Provider 2 10.1.1.0/24 {65555} Private S 10.1.1.0/24 {65555} 2008 isco Systems, Inc. ll rights reserved. isco Public 41 One Path as ackup S Path Prepend Use S path prepend to prefer one entrance This causes the upstream providers to prefer provider 1 over provider 2 Use local preference to not use the link for outbound traffic Upstream Provider 1 Provider 2 10.1.1.0/20 {65555} ustomer 2 10.1.1.0/20 {65555} Local Pref to Prefer Primary Link 2008 isco Systems, Inc. ll rights reserved. isco Public 42 21
One Path as ackup S Path Prepend router bgp 65555 network 10.1.0.0 mask 255.255.224.0 neighbor x.x.x.x remote-as XXX neighbor x.x.x.x prefix-list aggregate out neighbor x.x.x.x prefix-list default in ip prefix-list aggregate permit 121.10.0.0/19 ip prefix-list default permit 0.0.0.0/0 ip route 10.1.0.0 255.255.224.0 null0 Upstream ustomer 2 Provider 1 Provider 2 router bgp 65555 network 10.1.0.0 mask 255.255.224.0 neighbor x.x.x.x remote-as 120 neighbor x.x.x.x prefix-list aggregate out neighbor x.x.x.x route-map prepend-out out neighbor x.x.x.x route-map set-pref in ip prefix-list aggregate permit 121.10.0.0/19 route-map prepend-out permit 10 set as-path prepend 130 130 130 route-map set-pref permit 10 set local-preference 80 10.1.1.0/20 {65555} 10.1.1.0/20 {65555, 65555} 2008 isco Systems, Inc. ll rights reserved. isco Public 43 One Path as ackup S Path Prepend This does not direct all the traffic through the one link, however The S path length doesn t impact forwarding decisions within provider 2 Virtually all providers set the local preference to prefer routes learned from customers over routes learned from peers Upstream ustomer 2 Provider 1 Provider 2 10.1.1.0/20 {65555} 10.1.1.0/20 {65555, 65555} Local Pref Set to Prefer Routes Learned from ustomers 2008 isco Systems, Inc. ll rights reserved. isco Public 44 22
One Path as ackup S Path Prepend If customer 2 prefers the path through provider 2 They could have a default only to provider 2 They could be accepting a partial routing table Etc. Then provider 2 will prefer the -> link Rather than taking the path through the Upstream- >provider 1->-> ll the traffic coming from provider 2 s customers will follow the -> link Provider 1 Provider 2 10.1.1.0/20 {65555} Upstream ustomer 2 10.1.1.0/20 {65555, 65555} Local Pref Set to Prefer Routes Learned from ustomers 2008 isco Systems, Inc. ll rights reserved. isco Public 45 One Path as ackup onditional dvertisement onditional advertisement Provides total control over the use of the backup path Only advertises routes to one peer when the other peer is down If the -> link fails, advertise to from Upstream ustomer 2 Provider 1 Provider 2 10.1.1.0/20 {65555} 10.1.1.0/20 {65555, 65555} 2008 isco Systems, Inc. ll rights reserved. isco Public 46 23
One Path as ackup onditional dvertisement router bgp 65555 bgp log-neighbor-changes network 10.1.0.0 mask 255.255.240.0 neighbor <> remote-as XXX neighbor <> advertise-map VERTISE non-exist-map NON-EXIST neighbor <> remote-as 65555 ip route 10.1.0.0 255.255.240.0 null0 access-list 60 permit <a->b link address> access-list 65 permit 10.1.0.0 route-map NON-EXIST permit 10 match ip address 65 route-map VERTISE permit 10 match ip address 60 Provider 1 Provider 2 10.1.1.0/20 {65555} Upstream ustomer 2 10.1.1.0/20 {65555, 65555} Make ertain this Link Is dvertised to in GP 2008 isco Systems, Inc. ll rights reserved. isco Public 47 Inbound Load Sharing We want to inbound load share between these two connections Why can t we just S path prepend for this? Traffic from S65500 will still flow through 65200 Traffic from S65400 will still flow through S65300 Only the traffic sourced from S65600 will be impacted by S path prepend by itself This might work, or it might not 65600 65300 65200 65400 65500 65100 10.1.1.0/24 2008 isco Systems, Inc. ll rights reserved. isco Public 48 24
Inbound Load Sharing What are our other options? Longer match prefixes are still your friend Provider 1 Upstream ustomer 2 Provider 2 dvertise through one connection dvertise and 10.1.0.0/23 through the other connection 10.1.0.0/23 2008 isco Systems, Inc. ll rights reserved. isco Public 49 Inbound Load Sharing router bgp 65555 network 10.1.0.0 mask 255.255.252.0 network 121.10.0.0 mask 255.255.254.0 neighbor x.x.x.x remote-as <provider 2> neighbor x.x.x.x prefix-list firstblock out ip prefix-list firstblock permit ip prefix-list firstblock permit 10.1.0.0/23 Provider 1 Upstream ustomer 2 Provider 2 router bgp 65555 network 10.1.0.0 mask 255.255.252.0 network 10.1.0.0 mask 255.255.254.0 neighbor x.x.x.x remote-as <provider 1> neighbor x.x.x.x prefix-list secondblock out ip prefix-list secondblock permit 10.1.0.0/23 2008 isco Systems, Inc. ll rights reserved. isco Public 50 25
Inbound Load Sharing This is a very basic case ut shows the first steps in designing a load-sharing solution Start with a simple concept Provider 1 Upstream ustomer 2 Provider 2 nd build on it 10.1.0.0/23 2008 isco Systems, Inc. ll rights reserved. isco Public 51 Inbound Load Sharing You can extend this concept by dding various longer prefix matches on both links ombining advertisements of longer prefixes out both links with S path prepending For instance, here we are Prepending the /22 to influence traffic towards dvertising a longer prefix to influence other traffic towards Upstream Provider 1 ustomer 2 Provider 2 10.1.0.0/23 2008 isco Systems, Inc. ll rights reserved. isco Public 52 26
Inbound Load Sharing router bgp 65555 network 10.1.0.0 mask 255.255.252.0 network 10.1.0.0 mask 255.255.253.0 neighbor x.x.x.x remote-as <provider 2> neighbor x.x.x.x prefix-list subblocks out neighbor x.x.x.x route-map traffic-eng out route-map traffic-eng permit 10 match ip address prefix-list aggregate set as-path prepend 65555 65555 route-map traffic-eng permit 20 ip prefix-list subblocks permit le 23 ip prefix-list aggregate permit Provider 1 Upstream ustomer 2 Provider 2 10.1.0.0/23 router bgp 65555 network 10.1.0.0 mask 255.255.252.0 neighbor x.x.x.x remote-as <provider 1> neighbor x.x.x.x prefix-list aggregate out ip prefix-list aggregate permit ip route 10.1.0.0 255.255.252.0 null0 2008 isco Systems, Inc. ll rights reserved. isco Public 53 Inbound Load Sharing This example is more commonplace Shows how ISPs and end-sites subdivide address space frugally, as well as use the S-PTH prepend concept to optimise the load sharing between different ISPs Notice that the /22 aggregate block is always announced Upstream Provider 1 ustomer 2 Provider 2 10.1.0.0/23 2008 isco Systems, Inc. ll rights reserved. isco Public 54 27
Inbound Load Sharing RF1998 ommunities Informational RF escribes how to implement load sharing and backup on multiple inter-s links GP communities used to determine local preference in upstream s network Gives control to the customer Simplifies upstream s configuration Simplifies network operation 2008 isco Systems, Inc. ll rights reserved. isco Public 55 Inbound Load Sharing RF1998 ommunities ommunity values defined to have particular meanings: Sx:100 set local pref 100 preferred route Sx:90 set local pref 90 backup route if dualhomed on Sx Sx:80 set local pref 80 main link is to another ISP with same S path length Sx:70 set local pref 70 main link is to another ISP 2008 isco Systems, Inc. ll rights reserved. isco Public 56 28
Inbound Load Sharing RF1998 ommunities Sample customer router configuration router bgp 130 neighbor x.x.x.x remote-as 100 neighbor x.x.x.x description ackup ISP neighbor x.x.x.x route-map config-community out neighbor x.x.x.x send-community ip as-path access-list 20 permit ^$ ip as-path access-list 20 deny.* route-map config-community permit 10 match as-path 20 set community 100:90 2008 isco Systems, Inc. ll rights reserved. isco Public 57 Inbound Load Sharing RF1998 ommunities Sample ISP router configuration Homed to another ISP ip community-list 70 permit 100:70 Homed to another ISP with equal SPTH length ip community-list 80 permit 100:80 ustomer backup routes ip community-list 90 permit 100:90 route-map set-customer-local-pref permit 10 match community 70 set local-preference 70..next slide 2008 isco Systems, Inc. ll rights reserved. isco Public 58 29
Inbound Load Sharing RF1998 ommunities route-map set-customer-local-pref permit 20 match community 80 set local-preference 80 route-map set-customer-local-pref permit 30 match community 90 set local-preference 90 route-map set-customer-local-pref permit 40 set local-preference 100 2008 isco Systems, Inc. ll rights reserved. isco Public 59 Inbound Load Sharing RF1998 ommunities Supporting RF1998 Many ISPs do, more should heck S object in the Internet routing registry If you do, insert comment in S object in the IRR Or make a note on your website 2008 isco Systems, Inc. ll rights reserved. isco Public 60 30
Inbound Load Sharing RF1998 ommunities RF1998 is okay for simple multihomed customers ssumes that upstreams are interconnected ISPs have created many other communities to handle more complex situations Simplify ISP GP configuration Give customer more policy control 2008 isco Systems, Inc. ll rights reserved. isco Public 61 ISP GP ommunities There are no recommended ISP GP communities apart from RF1998 The four standard communities www.iana.org/assignments/bgp-well-known-communities Efforts have been made to document from time to time totem.info.ucl.ac.be/publications/papers-elec-versions/draftquoitin-bgp-comm-survey-00.pdf ut so far nothing more ollection of ISP communities at www.onesc.net/communities ISP policy is usually published On the ISP s website Referenced in the S object in the IRR 2008 isco Systems, Inc. ll rights reserved. isco Public 62 31
Inbound Load Sharing Other Policies: Sprintlink Example More Info at: www.sprintlink.net/policy/bgp.html 2008 isco Systems, Inc. ll rights reserved. isco Public 63 Inbound Load Sharing Other Policies: PT Example aut-num: S2764 as-name: SN-ONNET-NET descr: PT Limited admin-c: NO2-P tech-c: NO2-P remarks: ommunity support definitions remarks: remarks: ommunity efinition remarks: ------------------------------------------------ remarks: 2764:2 on't announce outside local POP remarks: 2764:4 Lower local preference by 15 remarks: 2764:5 Lower local preference by 5 remarks: 2764:6 nnounce to customers and all peers (incl int'l peers), but not transit remarks: 2764:7 nnounce to customers only remarks: 2764:14 nnounce to NX notify: routing@connect.com.au mnt-by: ONNET-U changed: nobody@connect.com.au 20050225 source: IR More at: http://info.connect.com.au/docs/routing/general/multi-faq.shtml#q13 2008 isco Systems, Inc. ll rights reserved. isco Public 64 32
Inbound Load Sharing Other Policies: Verizon usiness Europe Example aut-num: S702 descr: Verizon usiness EME - ommercial IP service provider in Eur remarks: Vzi uses the following communities with its customers: 702:80 Set Local Pref 80 within S702 702:120 Set Local Pref 120 within S702 702:20 nnounce only to Vzi S'es and Vzi customers 702:30 Keep within Europe, don't announce to other Vzi S 702:1 Prepend S702 once at edges of Vzi to Peers 702:2 Prepend S702 twice at edges of Vzi to Peers 702:3 Prepend S702 thrice at edges of Vzi to Peers dvanced communities for customers 702:7020 o not announce to S702 peers with a scope of National but advertise to Global Peers, European Peers and Vzi customers. 702:7001 Prepend S702 once at edges of Vzi to S702 peers with a scope of National. 702:7002 Prepend S702 twice at edges of Vzi to S702 peers with a scope of National. (more) 2008 isco Systems, Inc. ll rights reserved. isco Public 65 Inbound Load Sharing Other Policies: Verizon usiness Europe Example (more) 702:7003 Prepend S702 thrice at edges of Vzi to S702 peers with a scope of National. 702:8020 o not announce to S702 peers with a scope of European but advertise to Global Peers, National Peers and Vzi customers. 702:8001 Prepend S702 once at edges of Vzi to S702 peers with a scope of European. 702:8002 Prepend S702 twice at edges of Vzi to S702 peers with a scope of European. 702:8003 Prepend S702 thrice at edges of Vzi to S702 peers with a scope of European. -------------------------------------------------------------- dditional details of the Vzi communities are located at: http://www.verizonbusiness.com/uk/customer/bgp/ -------------------------------------------------------------- mnt-by: WOM-EME-RIE-MNT source: RIPE 2008 isco Systems, Inc. ll rights reserved. isco Public 66 33
Inbound Load Sharing Other Policies: T Ignite Example aut-num: S5400 descr: T Ignite European ackbone remarks: remarks: ommunity to ommunity to remarks: Not announce To peer: S prepend 5400 remarks: remarks: 5400:1000 ll peers & Transits 5400:2000 remarks: remarks: 5400:1500 ll Transits 5400:2500 remarks: 5400:1501 Sprint Transit (S1239) 5400:2501 remarks: 5400:1502 SVVIS Transit (S3561) 5400:2502 remarks: 5400:1503 Level 3 Transit (S3356) 5400:2503 remarks: 5400:1504 T&T Transit (S7018) 5400:2504 remarks: 5400:1506 Globalrossing Trans(S3549) 5400:2506 remarks: remarks: 5400:1001 Nexica (S24592) 5400:2001 remarks: 5400:1002 Fujitsu (S3324) 5400:2002 remarks: 5400:1004 &W EU (1273) 5400:2004 <snip> notify: notify@eu.bt.net mnt-by: IP-MNT source: RIPE 2008 isco Systems, Inc. ll rights reserved. isco Public 67 Inbound Load Sharing Other Policies: Level 3 Example aut-num: S3356 descr: Level 3 ommunications <snip> remarks: ------------------------------------------------------- remarks: customer traffic engineering communities - Suppression remarks: ------------------------------------------------------- remarks: 64960:XXX - announce to S XXX if 65000:0 remarks: 65000:0 - announce to customers but not to peers remarks: 65000:XXX - do not announce at peerings to S XXX remarks: ------------------------------------------------------- remarks: customer traffic engineering communities - Prepending remarks: ------------------------------------------------------- remarks: 65001:0 - prepend once to all peers remarks: 65001:XXX - prepend once at peerings to S XXX <snip> remarks: 3356:70 - set local preference to 70 remarks: 3356:80 - set local preference to 80 remarks: 3356:90 - set local preference to 90 remarks: 3356:9999 - blackhole (discard) traffic <snip> mnt-by: LEVEL3-MNT source: RIPE 2008 isco Systems, Inc. ll rights reserved. isco Public 68 34
Outbound Load Sharing efault Only What about my outbound traffic? First option: ccept only a default route Use the metrics on the internal IGP default routes to pull traffic to specific exit points Provider 1 Upstream ustomer 2 Provider 2 Use IGP Metrics to raw Traffic in Evenly 2008 isco Systems, Inc. ll rights reserved. isco Public 69 Outbound Load Sharing efault Only This can lead to suboptimal routing Traffic destined to customer 2 could be drawn to, and exit through provider 1 You actually might not care about this It does take the load off your network, and push it onto the provider s network Provider 1 Upstream ustomer 2 Provider 2 Use IGP Metrics to raw Traffic in Evenly 2008 isco Systems, Inc. ll rights reserved. isco Public 70 35
Outbound Load Sharing Partial Routes Second option: accept partial routes Partial routes include a default route and all the networks the provider is directly connected to In this case, provider 2 would send a route for customer 2 and a default Provider 1 efault + Provider 1 s ustomers Upstream ustomer 2 Provider 2 efault + Provider 2 s ustomers 2008 isco Systems, Inc. ll rights reserved. isco Public 71 Outbound Load Sharing Partial Routes You still draw internal traffic to the edge with IGP default routes ut now igp between the internal speakers draws traffic to the correct exit Eliminates 80%+ of all suboptimal routing at the edge Provider 1 efault + Provider 1 s ustomers Upstream igp Use IGP Metrics to raw Traffic in Evenly ustomer 2 Provider 2 efault + Provider 2 s ustomers 2008 isco Systems, Inc. ll rights reserved. isco Public 72 36
Outbound Load Sharing Full Routes What about full routes? You can gain a lot of control over your exit point ut you probably won t ever need this, as a leaf node Only pull in full routes if you are transiting traffic Provider 1 Full Routes Upstream igp Use IGP Metrics to raw Traffic in Evenly ustomer 2 Provider 2 Full Routes 2008 isco Systems, Inc. ll rights reserved. isco Public 73 Summary 2008 isco Systems, Inc. ll rights reserved. isco Public 74 37
Summary Multihoming is not hard, really Keep it simple and stupid Full routing table is rarely required default is often just as good If customers want 235k prefixes, charge them money for it 2008 isco Systems, Inc. ll rights reserved. isco Public 75 Q and 2008 isco Systems, Inc. ll rights reserved. isco Public 76 38
Recommended Reading ontinue your isco Live learning experience with further reading from isco Press heck the Recommended Reading flyer for suggested books vailable Onsite at the isco ompany Store 2008 isco Systems, Inc. ll rights reserved. isco Public 77 omplete Your Online Session Evaluation Give us your feedback and you could win fabulous prizes. Winners announced daily. Receive 20 Passport points for each session evaluation you complete. omplete your session evaluation online now (open a browser through our wireless network to access our portal) or visit one of the Internet stations throughout the onvention enter. on t forget to activate your isco Live virtual account for access to all session material on-demand and return for our live virtual event in October 2008. Go to the ollaboration Zone in World of Solutions or visit www.cisco-live.com. 39
2008 isco Systems, Inc. ll rights reserved. isco Public 79 40