So we're now going to look at the situation where our transit provider is also a peer at the internet exchange point. Now this is a relatively common situation several local ISPs will provide access to the local market and there may be one or two licensed transit providers and these licensed translates also wish to appear at the exchange part they may wish to because they want to do so for business purposes or the maybe local regulations which require all Internet service providers to appear at the internet exchange point so the desired outcome is for the transit provider to peer the domestic traffic at the exchange point but sell transit access for all other destinations so how do we ensure that transit traffic only goes in the transit link and peering traffic only goes on the peering link the diagram shows the situation that we're trying to discuss and resolve the transit provider has the connection to the Internet the router be on the diagram appears at the internet exchange point the local access provider has a router a also peering at the exchange point and the router see is the upstream connection to the transit provider well outbound traffic is straightforward the upstream will send the full BGP table to a s100 on the direct peering link the upstream will also send domestic rights to the IXP peers including to a s100 across the exchange point so a sub 100 will use the IXP for the domestic traffic and we'll use the upstream link for international traffic so I'd ban traffic is straightforward to resolve but what about inbound traffic s100 will send the address block to the IXP piers and the upstream provider will also see that address block coming through the router be at the exchange is 100 we'll send the address block directly to their upstream provider over the direct transit link so the best path from the upstream to s 100 is preferred via the exchange part remember we discussed earlier about the Preferences that operators make you would like peering traffic to appear before transit traffic in the local preference table so the best path from the upstream would be across the exchange point and this best path would include transit traffic bgp hasn't a capability of looking at the source address to try and work out which path to take so the solution to this is to separate the autonomous systems what the upstream provider will have to do is put the domestic network in one autonomous system and the transit network in another autonomous system then we peer the domestic network as150 as shown in the diagram at the exchange point and the transit network is 1/60 as shown in the diagram will be used for customers they sell transit to and if you look at the diagram you now see the s100 has the two connections they can pair with the domestic as150 of the upstream transit provider but they also will get paid transit from as160 through as160 transit service the transit provided needs to separate the network domestic as150 only carries local routes and probably also default to the upstream the transit part of the network is as160 and it is for all the non local routes transit customers connect to s 160 the transit is they receive the default route through bgp if they wanted it and they send just their address blocks the domestic s s 150 peers at the exchange point receipt local rights from other IXPs sends as150 originated rights to 'the IXPs inbound traffic to s 100 now follows the paths we expect s 100 sent the address blocked IXP peers including s 150 yes 100 sends the address blocked upstream as160 best path from the upstream to a s 100 is now over the transit link s 150 the domestic network of the transit provider does not announce a s 100 speared rights to the upstream transit provider transit providers who appear with the customers at an IX for local routes need to split the air sands into two one s for domestic routes one is for transit rights to autonomous system numbers are entirely justifiable because the two air sends have completely different routing policies the domestic s peers at the ixp the transit s connects transit customers and up streams this solution is scaleable and this solution is much easier to implement than other solutions such as complex source address policy routing which some operators have attempted to do in the past do you remember from the start of this whole BGP series that an autonomous system is used for representing a distinct routing policy it doesn't necessarily map onto an organization the common case is for an S to map onto an organization but an autonomous system is there to represent a routing policy a transit business will have a completely different routing policy from a nexus business or a hosting business and therefore will quite likely need a different ASN. In fact, quite a lot of the medium to large providers will have a different ASN for the different functions that they operate their business.

© 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.