So the next example we're going to look at is where the network operator has two connections to one internet exchange point. In the previous multihoming examples we demonstrated just a single router connecting to the i-x land but as the iock screws it becomes critical infrastructure for the local internet economy more members join it more traffic flows across the i-x and maybe the Ethernet switch either runs out of capacity or the members are requesting that the iyx provides redundancy for members and the second Ethernet switch will be on the same layer to infrastructure as the original switch so how do we configure BGP and the traffic engineering for two connections to this IX the diagram shows the two Ethernet links from separate switches to the two routers in the IXP member is 100 the second connection for the IXP line is on the same subnet as an IXP this is quite common in many internet exchange points where quite often the exchange point would assign two or three IP addresses from the one subnet to each member so setting a BGP is easy enough we set up a second ebgp session and that will be established with the exchange point route server or route service if they are present it will be set up with other ixb members with their second router if they have one and it will be set up with ixb services infrastructure if the exchange point offers services for the good of all members so let's look at how the outbound traffic engineering would be configured by default the link chosen will follow BGP best path rules in the absence of any other member policy for example members might send multi exit discriminators or meds the best path will basically come down to the lowest neighbor P address on the exchange point land which most likely means that one link will carry all the traffic and the other link will remain relatively empty s100 good lord balance over the physical links by setting local preferences on particular announcements from peers or using any BGP community policy implemented by other members inbound traffic engineering by default would follow the link chosen according to BGP best path rules in the absence of any local policy again for example meds sent to other peers the best path will be the lowest IP address on the i-x lam es-100 good balance over the two physical links by setting meds on particular announcements to peers half the peers could have announcements of Med 10 on one link and med 20 on the other link another half of the peers could have the med values reversed and this all assumes that the peers even respect meds which is getting less and less likely these days although the way we could do it is by implementing a BGP community policy which is available for other members to use sometimes internet exchange points recommend what a community policy might be we could try using s path pre plans but for this we need to be careful because we don't want the i-x path to be longer than that we have paid transit links otherwise we could well end up with peering traffic coming over our expensive and maybe long-haul transit connections another thing we could do is bond the two Ethernet connections together in some circumstances the i-x beam may offer the facility of creating an aggregated link it's called a lag a link aggregation group this provides redundancy at layer two for example two gigabit ethernet links will effectively present as two gigabits per second on a single connection on the router the BGP session is established over the lag rather than an individual links load-balancing is at layer 2 contained within the lag itself now this is only possible if the member provisions one router for the ixp connection and we're getting to the point now where the member probably wants to implement two connections from two separate routers and it's not desirable if the IXP provisions the two links on separate switches unless the switch vendor supports creating a lag that shared over two switches which starts getting to be quite a complex configuration and probably isn't really worth the extra complexity.

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