Advanced multihoming
1 like305 views
- The document discusses strategies for multihoming service provider networks, including balancing inbound and outbound traffic flows. - It provides examples of configurations for multihoming with one upstream provider and one local peer, one upstream and a local Internet exchange point, and two upstreams with one local peer. - Key aspects addressed include announcing address blocks to peers, accepting default routes from upstreams, and using route filters and policies to determine traffic engineering goals.
![Two Upstreams, One Local Peer
Full Routes
44
ip route 121.10.0.0 255.255.224.0 null0
!
ip as-path access-list 10 permit ^(130_)+$
ip as-path access-list 10 permit ^(130_)+_[0-9]+$
!
route-map AS130-loadshare permit 10
match ip as-path 10
set local-preference 120
!
route-map AS130-loadshare permit 20
set local-preference 80
!](https://image.slidesharecdn.com/advanced-multihoming-160522034016/85/Advanced-multihoming-44-320.jpg)
![Two Upstreams, One Local Peer
Partial Routes
51
ip prefix-list my-block 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
!
ip as-path access-list 10 permit ^(130_)+$
ip as-path access-list 10 permit ^(130_)+_[0-9]+$
!
route-map tag-default-low permit 10
match ip address prefix-list default
set local-preference 80
!
route-map tag-default-low permit 20
!](https://image.slidesharecdn.com/advanced-multihoming-160522034016/85/Advanced-multihoming-51-320.jpg)
![ISP B peering Inbound AS-PATH
filter
ip as-path access-list 1 deny _209_
ip as-path access-list 1 deny _701_
ip as-path access-list 1 deny _1239_
ip as-path access-list 1 deny _3356_
ip as-path access-list 1 deny _3549_
ip as-path access-list 1 deny _3561_
ip as-path access-list 1 deny _2914_
ip as-path access-list 1 deny _7018_
!
ip as-path access-list 1 deny _ISPA_
ip as-path access-list 1 deny _ISPC_
!
ip as-path access-list 1 permit _ISPB$
ip as-path access-list 1 permit _ISPB_[0-9]+$
ip as-path access-list 1 permit _ISPB_[0-9]+_[0-9]+$
ip as-path access-list 1 permit _ISPB_[0-9]+_[0-9]+_[0-9]+$
ip as-path access-list 1 deny .* 66
Don’t need ISPA and
ISPC prefixes via ISPB](https://image.slidesharecdn.com/advanced-multihoming-160522034016/85/Advanced-multihoming-66-320.jpg)
Advanced multihoming
- 1. Service Provider Multihoming ISP Workshops 1Last updated 31st March 2015
- 2. Service Provider Multihoming p Previous examples dealt with loadsharing inbound traffic n Of primary concern at Internet edge n What about outbound traffic? p Transit ISPs strive to balance traffic flows in both directions n Balance link utilisation n Try and keep most traffic flows symmetric n Some edge ISPs try and do this too p The original “Traffic Engineering” 2
- 3. Service Provider Multihoming p Balancing outbound traffic requires inbound routing information n Common solution is “full routing table” n Rarely necessary p Why use the “routing mallet” to try solve loadsharing problems? n “Keep It Simple” is often easier (and $$$ cheaper) than carrying N-copies of the full routing table 3
- 4. Service Provider Multihoming MYTHS!! Common MYTHS 1. You need the full routing table to multihome n People who sell router memory would like you to believe this n Only true if you are a transit provider n Full routing table can be a significant hindrance to multihoming 2. You need a BIG router to multihome n Router size is related to data rates, not running BGP n In reality, to multihome, your router needs to: p Have two interfaces, p Be able to talk BGP to at least two peers, p Be able to handle BGP attributes, p Handle at least one prefix 3. BGP is complex n In the wrong hands, yes it can be! Keep it Simple! 4
- 5. Service Provider Multihoming: Some Strategies p Take the prefixes you need to aid traffic engineering n Look at NetFlow data for popular sites p Prefixes originated by your immediate neighbours and their neighbours will do more to aid load balancing than prefixes from ASNs many hops away n Concentrate on local destinations p Use default routing as much as possible n Or use the full routing table with care 5
- 6. Service Provider Multihoming p Examples n One upstream, one local peer n One upstream, local exchange point n Two upstreams, one local peer n Three upstreams, unequal link bandwidths p Require BGP and a public ASN p Examples assume that the local network has their own /19 address block 6
- 7. Service Provider Multihoming One upstream, one local peer 7
- 8. One Upstream, One Local Peer p Very common situation in many regions of the Internet p Connect to upstream transit provider to see the “Internet” p Connect to the local competition so that local traffic stays local n Saves spending valuable $ on upstream transit costs for local traffic 8
- 9. One Upstream, One Local Peer 9 AS 100 C A Upstream ISP AS130 Local Peer AS120
- 10. One Upstream, One Local Peer p Announce /19 aggregate on each link p Accept default route only from upstream n Either 0.0.0.0/0 or a network which can be used as default p Accept all routes the local peer originates 10
- 11. router bgp 100 network 121.10.0.0 mask 255.255.224.0 neighbor 122.102.10.2 remote-as 120 neighbor 122.102.10.2 prefix-list my-block out neighbor 122.102.10.2 prefix-list AS120-peer in ! ip prefix-list AS120-peer permit 122.5.16.0/19 ip prefix-list AS120-peer permit 121.240.0.0/20 ! ip prefix-list my-block permit 121.10.0.0/19 ! ip route 121.10.0.0 255.255.224.0 null0 250 One Upstream, One Local Peer p Router A Configuration 11 Prefix filters inbound
- 12. router bgp 100 network 121.10.0.0 mask 255.255.224.0 neighbor 122.102.10.2 remote-as 120 neighbor 122.102.10.2 prefix-list my-block out neighbor 122.102.10.2 filter-list 10 in ! ip as-path access-list 10 permit ^(120_)+$ ! ip prefix-list my-block permit 121.10.0.0/19 ! ip route 121.10.0.0 255.255.224.0 null0 One Upstream, One Local Peer p Router A – Alternative Configuration 12 AS Path filters – more “trusting”
- 13. One Upstream, One Local Peer p Router C Configuration 13 router bgp 100 network 121.10.0.0 mask 255.255.224.0 neighbor 122.102.10.1 remote-as 130 neighbor 122.102.10.1 prefix-list default in neighbor 122.102.10.1 prefix-list my-block out ! ip prefix-list my-block 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
- 14. One Upstream, One Local Peer p Two configurations possible for Router A n Filter-lists assume peer knows what they are doing n Prefix-list higher maintenance, but safer n Some ISPs use both p Local traffic goes to and from local peer, everything else goes to upstream 14
- 15. Aside: Configuration Recommendations p Private Peers n The peering ISPs exchange prefixes they originate n Sometimes they exchange prefixes from neighbouring ASNs too p Be aware that the private peer eBGP router should carry only the prefixes you want the private peer to receive n Otherwise they could point a default route to you and unintentionally transit your backbone 15
- 16. Service Provider Multihoming One upstream, Local Exchange Point 16
- 17. One Upstream, Local Exchange Point p Very common situation in many regions of the Internet p Connect to upstream transit provider to see the “Internet” p Connect to the local Internet Exchange Point so that local traffic stays local n Saves spending valuable $ on upstream transit costs for local traffic p This example is a scaled up version of the previous one 17
- 18. One Upstream, Local Exchange Point 18 AS 100 C A Upstream ISP AS130 IXP
- 19. One Upstream, Local Exchange Point p Announce /19 aggregate to every neighbouring AS p Accept default route only from upstream n Either 0.0.0.0/0 or a network which can be used as default p Accept all routes originated by IXP peers 19
- 20. One Upstream, Local Exchange Point p Router A Configuration 20 interface fastethernet 0/0 description Exchange Point LAN ip address 120.5.10.1 mask 255.255.255.224 ! router bgp 100 neighbor ixp-peers peer-group neighbor ixp-peers prefix-list my-block out neighbor ixp-peers remove-private-AS neighbor ixp-peers send-community neighbor ixp-peers route-map set-local-pref in ! …next slide
- 21. One Upstream, Local Exchange Point 21 neighbor 120.5.10.2 remote-as 200 neighbor 120.5.10.2 peer-group ixp-peers neighbor 120.5.10.2 prefix-list peer200 in neighbor 120.5.10.3 remote-as 201 neighbor 120.5.10.3 peer-group ixp-peers neighbor 120.5.10.3 prefix-list peer201 in neighbor 120.5.10.4 remote-as 202 neighbor 120.5.10.4 peer-group ixp-peers neighbor 120.5.10.4 prefix-list peer202 in neighbor 120.5.10.5 remote-as 203 neighbor 120.5.10.5 peer-group ixp-peers neighbor 120.5.10.5 prefix-list peer203 in ...next slide
- 22. One Upstream, Local Exchange Point 22 ! ip prefix-list my-block permit 121.10.0.0/19 ip prefix-list peer200 permit 122.0.0.0/19 ip prefix-list peer201 permit 122.30.0.0/19 ip prefix-list peer202 permit 122.12.0.0/19 ip prefix-list peer203 permit 122.18.128.0/19 ! route-map set-local-pref permit 10 set local-preference 150 !
- 23. One Upstream, Local Exchange p Note that Router A does not generate the aggregate for AS100 n If Router A becomes disconnected from backbone, then the aggregate is no longer announced to the IX n BGP failover works as expected p Note the inbound route-map which sets the local preference higher than the default n This is a visual reminder that BGP Best Path for local traffic will be across the IXP n (And allows for future case where operator may need to take BGP routes from their upstream(s)) 23
- 24. One Upstream, Local Exchange Point p Router C Configuration 24 router bgp 100 network 121.10.0.0 mask 255.255.224.0 neighbor 122.102.10.1 remote-as 130 neighbor 122.102.10.1 prefix-list default in neighbor 122.102.10.1 prefix-list my-block out ! ip prefix-list my-block 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
- 25. One Upstream, Local Exchange Point p Note Router A configuration n Prefix-list higher maintenance, but safer n No generation of AS100 aggregate p IXP traffic goes to and from local IXP, everything else goes to upstream 25
- 26. Aside: IXP Configuration Recommendations p IXP peers n The peering ISPs at the IXP exchange prefixes they originate n Sometimes they exchange prefixes from neighbouring ASNs too p Be aware that the IXP border router should carry only the prefixes you want the IXP peers to receive and the destinations you want them to be able to reach n Otherwise they could point a default route to you and unintentionally transit your backbone p If IXP router is at IX, and distant from your backbone n Don’t originate your address block at your IXP router 26
- 27. Service Provider Multihoming Local Exchange Point, with Upstream also being a Peer 27
- 28. Local Exchange Point, with Upstream also being Peer p Quite a common situation n Several local ISPs providing access to the local market n One or two licensed international transit providers n Licensed transits also peer at the IXP p How to ensure that: n Transit traffic goes on transit link n Peering traffic goes on peering link 28
- 29. Local Exchange Point, with Upstream also being Peer 29 AS 100 C A Link to Upstream ISP IXP To the Internet Transit Provider
- 30. Local Exchange Point, with Upstream also being Peer p Outbound traffic from AS100: n Upstream sends full BGP table to AS100 n Upstream sends domestic routes to IXP peers n AS100 uses IXP for domestic traffic n AS100 uses Upstream link for international traffic p Inbound traffic to AS100: n AS100 sends address block to IXP peers n AS100 sends address block to upstream n Best path from upstream to AS100 preferred via the IXP (see previous scenario) p Problem: how to separate international and domestic inbound traffic? 30
- 31. Solution: AS Separation 31 AS 100 C A Link to Upstream ISP IXP B To the Internet Domestic AS150 Transit AS160 D
- 32. Solution: AS Separation p The transit provider needs to separate their network into domestic (AS150: local routes) and transit (AS160: international routes) p Transit customers connect to transit AS (AS160) p Domestic AS (AS150) peers at the IX, passing domestic routes only p Inbound traffic to AS100 now: n AS100 sends address block to IXP peers (including AS150) n AS100 sends address block to upstream (AS160) n Important: Router D does NOT pass prefixes learned from IX peers to AS160 n Best path from upstream to AS100 preferred via the transit link 32
- 33. Local Exchange Point, with Upstream also being Peer p Transit providers who peer with their customers at an IX for local routes need to split their ASNs into two: n One AS for domestic business/domestic routes n One AS for international transit routes p Two ASNs are justifiable from the RIRs because the two ASNs have completely different routing policies n Domestic AS peers at IXP n Transit AS connects transit customers and upstreams p This solution is much easier to implement than other solutions such as complex source address policy routing 33
- 34. Service Provider Multihoming Two upstreams, one local peer 34
- 35. Two Upstreams, One Local Peer p Connect to both upstream transit providers to see the “Internet” n Provides external redundancy and diversity – the reason to multihome p Connect to the local peer so that local traffic stays local n Saves spending valuable $ on upstream transit costs for local traffic 35
- 36. Two Upstreams, One Local Peer 36 AS 100 C A Upstream ISP AS140 Local Peer AS120 D Upstream ISP AS130
- 37. Two Upstreams, One Local Peer p Announce /19 aggregate on each link p Accept default route only from upstreams n Either 0.0.0.0/0 or a network which can be used as default p Accept all routes originated by local peer p Note separation of Router C and D n Single edge router means no redundancy p Router A n Same routing configuration as in example with one upstream and one local peer 37
- 38. Two Upstreams, One Local Peer p Router C Configuration 38 router bgp 100 network 121.10.0.0 mask 255.255.224.0 neighbor 122.102.10.1 remote-as 130 neighbor 122.102.10.1 prefix-list default in neighbor 122.102.10.1 prefix-list my-block out ! ip prefix-list my-block 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
- 39. Two Upstreams, One Local Peer p Router D Configuration 39 router bgp 100 network 121.10.0.0 mask 255.255.224.0 neighbor 122.102.10.5 remote-as 140 neighbor 122.102.10.5 prefix-list default in neighbor 122.102.10.5 prefix-list my-block out ! ip prefix-list my-block 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
- 40. Two Upstreams, One Local Peer p This is the simple configuration for Router C and D p Traffic out to the two upstreams will take nearest exit n Inexpensive routers required n This is not useful in practice especially for international links n Loadsharing needs to be better 40
- 41. Two Upstreams, One Local Peer p Better configuration options: n Accept full routing from both upstreams p Expensive & unnecessary! n Accept default from one upstream and some routes from the other upstream p The way to go! 41
- 42. Loadsharing with different ISPs 42 AS 130 AS 140 AS 100 DC Transit Cust1 Cust2 Cust3 Cust4 Cust5 Internet
- 43. Two Upstreams, One Local Peer Full Routes p Router C Configuration 43 router bgp 100 network 121.10.0.0 mask 255.255.224.0 neighbor 122.102.10.1 remote-as 130 neighbor 122.102.10.1 prefix-list rfc6890-deny in neighbor 122.102.10.1 prefix-list my-block out neighbor 122.102.10.1 route-map AS130-loadshare in ! ip prefix-list my-block permit 121.10.0.0/19 ! ! See http://tools.ietf.org/html/rfc6890 ...next slide Allow all prefixes apart from RFC6890 blocks
- 44. Two Upstreams, One Local Peer Full Routes 44 ip route 121.10.0.0 255.255.224.0 null0 ! ip as-path access-list 10 permit ^(130_)+$ ip as-path access-list 10 permit ^(130_)+_[0-9]+$ ! route-map AS130-loadshare permit 10 match ip as-path 10 set local-preference 120 ! route-map AS130-loadshare permit 20 set local-preference 80 !
- 45. Two Upstreams, One Local Peer Full Routes p Router D Configuration 45 router bgp 100 network 121.10.0.0 mask 255.255.224.0 neighbor 122.102.10.5 remote-as 140 neighbor 122.102.10.5 prefix-list rfc6890-deny in neighbor 122.102.10.5 prefix-list my-block out ! ip prefix-list my-block permit 121.10.0.0/19 ! ! See http://tools.ietf.org/html/rfc6890 Allow all prefixes apart from RFC6890 blocks
- 46. Two Upstreams, One Local Peer Full Routes p Router C configuration: n Accept full routes from AS130 n Tag prefixes originated by AS130 and AS130’s neighbouring ASes with local preference 120 p Traffic to those ASes will go over AS130 link n Remaining prefixes tagged with local preference of 80 p Traffic to other all other ASes will go over the link to AS140 p Router D configuration same as Router C without the route-map 46
- 47. Two Upstreams, One Local Peer Full Routes p Full routes from upstreams n Summary of routes received: ASN Full Routes Partial Routes AS140 500000 @lp 100 AS130 30000 470000 @lp 120 @lp 80 Total 1000000
- 48. Two Upstreams, One Local Peer Full Routes p Full routes from upstreams n Expensive – needs lots of memory and CPU n Need to play preference games n Previous example is only an example – real life will need improved fine-tuning! n Previous example doesn’t consider inbound traffic – see earlier in presentation for examples 48
- 49. Two Upstreams, One Local Peer Partial Routes: Strategy p Ask one upstream for a default route n Easy to originate default towards a BGP neighbour p Ask other upstream for a full routing table n Then filter this routing table based on neighbouring ASN n E.g. want traffic to their neighbours to go over the link to that ASN n Most of what upstream sends is thrown away n Easier than asking the upstream to set up custom BGP filters for you 49
- 50. p Router C Configuration router bgp 100 network 121.10.0.0 mask 255.255.224.0 neighbor 122.102.10.1 remote-as 130 neighbor 122.102.10.1 prefix-list rfc6890-deny in neighbor 122.102.10.1 prefix-list my-block out neighbor 122.102.10.1 filter-list 10 in neighbor 122.102.10.1 route-map tag-default-low in ! Two Upstreams, One Local Peer Partial Routes 50 Allow all prefixes apart from RFC6890 blocks AS filter list filters prefixes based on origin ASN
- 51. Two Upstreams, One Local Peer Partial Routes 51 ip prefix-list my-block 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 ! ip as-path access-list 10 permit ^(130_)+$ ip as-path access-list 10 permit ^(130_)+_[0-9]+$ ! route-map tag-default-low permit 10 match ip address prefix-list default set local-preference 80 ! route-map tag-default-low permit 20 !
- 52. Two Upstreams, One Local Peer Partial Routes p Router D Configuration 52 router bgp 100 network 121.10.0.0 mask 255.255.224.0 neighbor 122.102.10.5 remote-as 140 neighbor 122.102.10.5 prefix-list default in neighbor 122.102.10.5 prefix-list my-block out ! ip prefix-list my-block 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
- 53. Two Upstreams, One Local Peer Partial Routes p Router C configuration: n Accept full routes from AS130 p (or get them to send less) n Filter ASNs so only AS130 and AS130’s neighbouring ASes are accepted n Allow default, and set it to local preference 80 n Traffic to those ASes will go over AS130 link n Traffic to other all other ASes will go over the link to AS140 n If AS140 link fails, backup via AS130 – and vice-versa 53
- 54. Two Upstreams, One Local Peer Partial Routes p Partial routes from upstreams n Summary of routes received: ASN Full Routes Partial Routes AS140 500000 @lp 100 1 @lp 100 AS130 30000 470000 @lp 120 @lp 80 30000 1 @lp 100 @lp 80 Total 1000000 30002
- 55. Distributing Default route with IGP p Router C IGP Configuration p Router D IGP Configuration p Primary path is via Router D, with backup via Router C n Preferred over carrying default route in iBGP router ospf 100 default-information originate metric 30 ! router ospf 100 default-information originate metric 10 !
- 56. Two Upstreams, One Local Peer Partial Routes p Partial routes from upstreams n Not expensive – only carry the routes necessary for loadsharing n Need to filter on AS paths n Previous example is only an example – real life will need improved fine-tuning! n Previous example doesn’t consider inbound traffic – see earlier in presentation for examples 56
- 57. Aside: Configuration Recommendation p When distributing internal default by iBGP or OSPF/ISIS n Make sure that routers connecting to private peers or to IXPs do NOT carry the default route n Otherwise they could point a default route to you and unintentionally transit your backbone n Simple fix for Private Peer/IXP routers: ip route 0.0.0.0 0.0.0.0 null0 57
- 58. Service Provider Multihoming Three upstreams, unequal bandwidths 58
- 59. Three upstreams, unequal bandwidths p Autonomous System has three upstreams n 16Mbps to ISP A n 8Mbps to ISP B n 4Mbps to ISP C p What is the strategy here? n One option is full table from each p 3x 533k prefixes ⇒ 1600k paths n Other option is partial table and defaults from each p How?? 59
- 60. Strategy p Two external routers (gives router redundancy) n Do NOT need three routers for this p Connect biggest bandwidth to one router n Most of inbound and outbound traffic will go here p Connect the other two links to the second router n Provides maximum backup capacity if primary link fails p Use the biggest link as default n Most of the inbound and outbound traffic will go here p Do the traffic engineering on the two smaller links n Focus on regional traffic needs 60
- 61. Diagram p Router A has 16Mbps circuit to ISP A p Router B has 8Mbps and 4Mbps circuits to ISPs B&C 61 AS 100 B ISP A AS110 ISP C AS130 A ISP B AS120
- 62. Outbound load-balancing strategy p Available BGP feeds from Transit providers: n Full table n Customer prefixes and default n Default Route p These are the common options on Internet today n Very rare for any provider to offer anything different n Very rare for any provider to customise BGP feed for a customer 62
- 63. Outbound load-balancing strategy p Accept only a default route from the provider with the largest connectivity, ISP A n Because most of the traffic is going to use this link p If ISP A won’t provide a default: n Still run BGP with them, but discard all prefixes n Point static default route to the upstream link n Distribute the default in the IGP p Request the full table from ISP B & C n Most of this will be thrown away n (“Default plus customers” is not enough) 63
- 64. Outbound load-balancing strategy p How to decide what to keep and what to discard from ISPs B & C? n Most traffic will use ISP A link — so we need to find a good/useful subset p Discard prefixes transiting the global transit ISPs n Global transit ISPs generally appear in most non-local or regional AS-PATHs p Discard prefixes with ISP A’s ASN in the path n Makes more sense for traffic to those destinations to go via the link to ISP A 64
- 65. Outbound load-balancing strategy p Global Transit (Tier-1) ISPs include: 209 CenturyLink (Qwest) 701 VerizonBusiness (UUNET) 1229 TeliaSonera (Telia) 1239 Softbank (Sprint) 1668 AOL TDN 2914 NTT America (NTT/Verio) 3549 Level 3 (GlobalCrossing) 3356 Level 3 3561 CenturyLink (Savvis, ex C&W) 7018 AT&T 65
- 66. ISP B peering Inbound AS-PATH filter ip as-path access-list 1 deny _209_ ip as-path access-list 1 deny _701_ ip as-path access-list 1 deny _1239_ ip as-path access-list 1 deny _3356_ ip as-path access-list 1 deny _3549_ ip as-path access-list 1 deny _3561_ ip as-path access-list 1 deny _2914_ ip as-path access-list 1 deny _7018_ ! ip as-path access-list 1 deny _ISPA_ ip as-path access-list 1 deny _ISPC_ ! ip as-path access-list 1 permit _ISPB$ ip as-path access-list 1 permit _ISPB_[0-9]+$ ip as-path access-list 1 permit _ISPB_[0-9]+_[0-9]+$ ip as-path access-list 1 permit _ISPB_[0-9]+_[0-9]+_[0-9]+$ ip as-path access-list 1 deny .* 66 Don’t need ISPA and ISPC prefixes via ISPB
- 67. Outbound load-balancing strategy: ISP B peering configuration p Part 1: Dropping Global Transit ISP prefixes n This can be fine-tuned if traffic volume is not sufficient n (More prefixes in = more traffic out) p Part 2: Dropping prefixes transiting ISP A & C network p Part 3: Permitting prefixes from ISP B, their BGP neighbours, and their neighbours, and their neighbours n More AS_PATH permit clauses, the more prefixes allowed in, the more egress traffic n Too many prefixes in will mean more outbound traffic than the link to ISP B can handle 67
- 68. Outbound load-balancing strategy p Similar AS-PATH filter can be built for the ISP C BGP peering p If the same prefixes are heard from both ISP B and C, then establish proximity of their origin ASN to ISP B or C n e.g. ISP B might be in Japan, with the neighbouring ASN in Europe, yet ISP C might be in Europe n Transit to the ASN via ISP C makes more sense in this case 68
- 69. Inbound load-balancing strategy p The largest outbound link should announce just the aggregate p The other links should announce: a) The aggregate with AS-PATH prepend b) Subprefixes of the aggregate, chosen according to traffic volumes to those subprefixes, and according to the services on those subprefixes p Example: n Link to ISP B could be used just for Broadband/Dial customers — so number all such customers out of one contiguous subprefix n Link to ISP C could be used just for commercial leased line customers — so number all such customers out of one contiguous subprefix 69
- 70. Router A: eBGP Configuration Example router bgp 100 network 100.10.0.0 mask 255.255.224.0 neighbor 122.102.10.1 remote 110 neighbor 122.102.10.1 prefix-list default in neighbor 122.102.10.1 prefix-list aggregate out ! ip prefix-list default permit 0.0.0.0/0 ip prefix-list aggregate permit 100.10.0.0/19 ! 70
- 71. Router B: eBGP Configuration Example router bgp 100 network 100.10.0.0 mask 255.255.224.0 neighbor 120.103.1.1 remote 120 neighbor 120.103.1.1 filter-list 1 in neighbor 120.103.1.1 prefix-list ISP-B out neighbor 120.103.1.1 route-map to-ISP-B out neighbor 121.105.2.1 remote 130 neighbor 121.105.2.1 filter-list 2 in neighbor 121.105.2.1 prefix-list ISP-C out neighbor 121.105.2.1 route-map to-ISP-C out ! ip prefix-list aggregate permit 100.10.0.0/19 ! ...next slide 71
- 72. Router B: eBGP Configuration Example ip prefix-list ISP-B permit 100.10.0.0/19 ip prefix-list ISP-B permit 100.10.0.0/21 ! ip prefix-list ISP-C permit 100.10.0.0/19 ip prefix-list ISP-C permit 100.10.28.0/22 ! route-map to-ISP-B permit 10 match ip address prefix-list aggregate set as-path prepend 100 ! route-map to-ISP-B permit 20 ! route-map to-ISP-C permit 10 match ip address prefix-list aggregate set as-path prepend 100 100 ! route-map to-ISP-C permit 20 72 /21 to ISP B “dial customers” e.g. Single prepend on ISP B link /22 to ISP C “biz customers” e.g. Dual prepend on ISP C link
- 73. What about outbound backup? p We have: n Default route from ISP A by eBGP n Mostly discarded full table from ISPs B&C p Strategy: n Originate default route by OSPF on Router A (with metric 10) — link to ISP A n Originate default route by OSPF on Router B (with metric 30) — links to ISPs B & C n Plus on Router B: p Static default route to ISP B with distance 240 p Static default route to ISP C with distance 245 n When link goes down, static route is withdrawn 73
- 74. Outbound backup: steady state p Steady state (all links up and active): n Default route is to Router A — OSPF metric 10 n (Because default learned by eBGP ⇒ default is in RIB ⇒ OSPF will originate default) n Backup default is to Router B — OSPF metric 20 n eBGP prefixes learned from upstreams distributed by iBGP throughout backbone n (Default can be filtered in iBGP to avoid “RIB failure error”) 74
- 75. Outbound backup: failure examples p Link to ISP A down, to ISPs B&C up: n Default route is to Router B — OSPF metric 20 n (eBGP default gone from RIB, so OSPF on Router A withdraws the default) p Above is true if link to B or C is down as well p Link to ISPs B & C down, link to ISP A is up: n Default route is to Router A — OSPF metric 10 n (static defaults on Router B removed from RIB, so OSPF on Router B withdraws the default) 75
- 76. Other considerations p Default route should not be propagated to devices terminating non-transit peers and customers p Rarely any need to carry default in iBGP n Best to filter out default in iBGP mesh peerings p Still carry other eBGP prefixes across iBGP mesh n Otherwise routers will follow default route rules resulting in suboptimal traffic flow n Not a big issue because not carrying full table 76
- 77. Router A: iBGP Configuration Example router bgp 100 network 100.10.0.0 mask 255.255.224.0 neighbor ibgp-peers peer-group neighbor ibgp-peers remote-as 100 neighbor ibgp-peers prefix-list ibgp-filter out neighbor 100.10.0.2 peer-group ibgp-peers neighbor 100.10.0.3 peer-group ibgp-peers ! ip prefix-list ibgp-filter deny 0.0.0.0/0 ip prefix-list ibgp-filter permit 0.0.0.0/0 le 32 ! 77
- 78. Three upstreams, unequal bandwidths: Summary p Example based on many deployed working multihoming/loadbalancing topologies p Many variations possible — this one is: n Easy to tune n Light on border router resources n Light on backbone router infrastructure n Sparse BGP table ⇒ faster convergence 78