Let's now have a look at where we need to do traffic engineering when we are connected to two internet exchange points the several variations possible on this theme and so what we're trying to do here is give you general guidelines about what you need to think about we could be peering at to local IXPs should really happen as an IXP is intended to be a collaborative effort between members and participants to peer local traffic to IXP serving the same local market doubles the costs for all operators and makes the traffic engineering more challenging it might be a case where we're peering at a local IXP and a regional IXP this is very common and this is where an ISP will participate in the local exchange point for local traffic and also turns up at one or more regional IXPs for greater peering opportunities or we could also have the case where we're peering at to regional ixps and this occurs in the absence of a local internet exchange point the diagram shows a potential set up we have the exchange point member sitting a s100 the router a connects to one exchange point and their router B connects to the other exchange point this could also be the case where one exchange point operates two independent sites for scaling ixs once we get beyond the case of needing to Ethernet switches members usually request that the i-x sets up two independent physical locations we don't want to join those two IX witches together in the two separate locations but we run the two locations completely independently the second exchange point line configuration will be set up in the same way as that as the connection to the first ixp the member has access to the same facilities they will probably run a route server they will probably offer I Xserve 'us and so on setting up bgp is straightforward we establish ebgp sessions with the ixp right server with other ixp members and with the IXP services infrastructure traffic engineering can be done by load balancing across the IXP links needed when members are present at both IXPs provide bound traffic in engineering by default the link chosen will follow BGP best path rules in the absence of any other member policy for example meds or communities best path will be lowest neighbor IP address which most likely means that link to one IXP carries all the traffic and the link to the other IXP remains relatively empty and we could end up to the situation with outbound traffic going through one eye XP and return traffic coming through the other eye XP especially if some of the other members follow the same default behaviors KS 100 good load balance over the two ixps by setting local preferences on particular announcements from peers or using any BGP community policy implemented by other members inbound traffic engineering by default again will follow BGP best path rules in absence of any local policy the best path will be the lowest neighbor IP address and this becomes entirely dependent on the address block that IX has received from the regional internet registry es-100 good load balance over the two ixb links to other members they could do this by setting meds on particular announcements to peers half the peers could have announcements of may attend and one link and made 20 on the other link to the other iooks another half of the peers of med values reversed and again this assumes that the peers will respect the meds which are being sent or we could implement a BGP community policy which is available for other members to use and again as we saw earlier IX pees quite often recommend what this community policy might be we could use a s path pre pounds as we have seen earlier with the same caveat we need to be sure that the i-x path is not longer than via the paid transit links what about now if one of the I X's is a regional exchange part if you remember back to the peering preferences excerpt you remember you will want to prioritize the local IXP over the regional IXP so the regional ixb line configuration will be set up in exactly the same way as the local ixp providing the same facility as the right serve or the iock services and so forth BGP configuration will be established in the same way with a route server with other members and with the services infrastructure and traffic engineering would be done in the same way as well 'lord balancing if needed especially when members are present at both the local and the regional IXP sideburn traffic engineering again the default will be that we follow BGP best path rules here are setting local preference from BGP routes learned from different classes of neighbors becomes very important we saw the local preferences set before if a member who appearing with appears at both the local IX and the regional IX we would want to send traffic between us and them over the local exchange point not the regional exchange part which probably has greater cost for us to reach in terms of physical infrastructure fibre optics and so on inbound traffic engineering configuration again by default will follow BGP best path rules in absence of any policy it again it could well be by neighbor IP address and again that means dependent on the address block the exchange point is received from the registry as with outbound example a s100 will need to prioritize incoming traffic over the local IX rather than the regional IX for members who are participating in both exchanges we want to consider the regional as the back I bound traffic follows a local preference table in earlier slides and we will probably need to use s path prepend or communities or subdividing address blocks to try and ensure that the returned traffic comes back over the local I X and not over the regional we won't want outbound traffic to go over the local I X and the return from the member to come over the regional IX the third sub case we're looking at is the peering at two regional exchange points and this one could also apply where the IXP operates two independent sites as we saw earlier on this except the second IXP line configuration will be set up in the same way as the first one members access the same facilities the right server exchange point services and so forth BGP configuration with the same infrastructure as we discussed before and the traffic engineering needs to be considered as well but now we need to consider which regional IX we want to give preference to especially again if members are present at both of them because by default the link chosen will follow BGP best path rules especially were going between continents one regional IX might be a lot closer Mille second round trip time than the other one so we don't really want to have outbound traffic going through an IX a regional IX and one continent and returning through the regional IX and another continent we could quite potentially end up with traffic going all the way around the globe in the worst cases and that's really very suboptimal so a s100 could load balance over the I axis by setting local call preferences and particular announcements from peers paying close attention to geographical or regional interconnect issues and by using any BGP community policy implemented by other members in fact in cases like this the use of BGP communities becomes even more and more important to ensure that we can have a symmetric traffic flow as possible for more about bgp community configuration refer to the bgp community slide sets inbound traffic engineering again by default will follow BGP best path rules s100 will need to prioritize incoming traffic between the two regional IXPs according to geographical needs or other issues that come up urban traffic will follow the local preference table we discussed earlier prioritization can be done using s path pre parent again we need to use this carefully subdividing address blocks so da Greg a ting for private peer and regional connections and not subdividing for a transit.

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.