The next example we're going to look at is the case where we have a customer or endsite multi-homed between two ISPs who are members of an internet exchange point. this is quite a common situation where the end user network is multi-homed for redundancy purposes or for load balancing purposes the diagram shows the situation and we have to look and see what the traffic engineering considerations are required for this particular setup the issues we need to address include transit in other words which path does incoming transit traffic take to the end side which path does outgoing transit traffic take from the n site we also need to consider the peering situation how does peering traffic from other exchange part members get to the end site and what about traffic from the n side to other ixp members each isp will consider the end site to be their customer and would like to have their customers traffic transit their link to the customer let's look at the route announcements first as100 would announce its address block to both upstreams s120 and as130 will both tag high local preference on the announcement they receive from as100 and therefore traffic from es120 and 130 respectively will go over their respective direct links es120 and es130 will announce es100s address block onwards to their upstreams and to the rest of the internet and the global internet will choose the path to as100 according to best path rules s120 and as130 will also announce es100s routes to the exchange points right server and to the ixp members they peer with and we'll follow the peering priorities discussed earlier es120 will hear 100's writes from the direct connection and set local preference 250. es120 will hear as100's routes across the exchange point and set local preference 170. if you remember from the earlier we set higher priority for direct bgp customer routes over the same routes heard from across an exchange point or the transit link and es130 will do exactly the same thing in steady state traffic from as120 or as130 to their customer will traverse the direct transit link the diagram shows how this will work the green arrow shows incoming traffic from the global internet either going through as120 upstream or as130 upstream to get to as100 an outgoing traffic will use either or both of the upstream links through as120 or as130 to the global internet what about if we now look at a failure mode what happens if the link from as120 to as100 breaks it could be shut down it could be a physical failure or there could be some issue with the border router in as100 the diagram shows the link being broken s120 will still see a path to as100 but this path will now be across the exchange point to airs 130 and then using es130s link to the customer as100 which means that traffic from as120 to as100 crosses the exchange point and as130 traffic from as100 will go to as120 via as130 and the exchange point if we look at the whole traffic flow including traffic from the global internet we will see that traffic to the internet will exit via as130 upstream link it will go from as100 to as130 and straight out the link to the global internet traffic from the internet though will enter via as120 and as130 but the latter path will likely be higher volume due to the shorter airs path length visible on the global internet traffic 2 as120 crosses the ixp via as130 and traffic from as120 will cross the ixp via as130 the diagram shows the traffic flow with the color-coded arrows we have some of the observations about this failure mode if as130 implements packet filtering by source address on the peering link then this will seriously affect the connectivity experienced by as100 incoming traffic from the internet via as120 and the exchange point will be dropped multi-home customers of ixp members will result in this unusual traffic flow we saw earlier and this is a side effect of the customer having redundant connections to the upstream providers and there's nothing wrong with it and it's one reason why it is very important for a network operator to set higher local preference on routes heard directly from a bgp customer versus the same rights heard via peering or transit links failure to set the local preference properly could result in peer or transit traffic going over the exchange point rather than over the direct links customer traffic engineering could also cause transit traffic during the failure case to transit as120 across the ixp and then via as130 to the customer for example the customer could have asked as130 to announce its address space to the global internet with a large preprint as shown in the diagram the global internet will then see best path to as130 via as120 across the exchange point across es130 and down to as100 outbound traffic would still go directly s100 to as130 out to the global internet this would have seemed a little bit unusual from the internet point of view but again as a perfectly normal situation given the failure mode that we're currently sitting in another situation that could happen is if as120 tags routes it hears from its exchange point peers with the no export community as we've learned elsewhere in the series the bgp no export community means do not advertise this prefix to ebgp peers so when the link to its as100 customer fails as100's prefix will be withdrawn from the bgp announcements made by as120 to the internet during steady state the best path to as100 is on the direct link but when the direct link fails the bgp announcement disappears and the only remaining path is via the exchange point but this prefix will be tagged no export and means it will be withdrawn from bgp announcements made by as120 to the internet so the diagram shows the resulting traffic flow incoming traffic from the global internet will come in via as130 upstream link outgoing traffic will go out through as130's upstream link so this is a common scenario for when a customer is multi-homed onto members of an exchange point steady-state traffic flow works as expected and if either customer transit link fails then it's quite likely that incoming transit traffic will cross the exchange point it's not unusual nor is it a problem if you want to avoid having transit traffic crossing the ixp then tag the routes heard from the ixp peers with no export direct customer routes will only be announced to transits when the direct link to the customer is active as soon as the direct link to the customer fails the only bgp paths heard will be across the exchange point they'll be tagged with no-export and therefore no longer announced to the global internet.