We're now going to look at a few multihoming scenarios. We're gonna look at a stub network. We're going to look at a multi-homde stub network and then just a general multihomed network. So first off the stub network. So here the endsite is connected to its upstream provider. The standard customer to service provider link is usually provided by a single connection. What happens when there's a second connection? In the diagram here we have the second connection running from the customer router to the same router on the upstream provider. Basically it's two parallel links so there's no need for BGP here. All we need to do is point a static default route from the home network, the local network, to the upstream provider. The upstream provider will advertise the stub network like it would advertise any other single connected stub network and the upstream would point routes to the end site as they would do in the standard case. Policy is confined within the upstream ISP policy. The endsite has no capability of doing any policy but not that they would be able to anyway given that they are just two parallel links between them and their upstream. You could use BGP if you wanted to in this case but there's almost nothing to be gained by doing so. So remaining with the simple configuration of using a static default route in the case of an endsite and a static route for the end user address space in the case of the service provider will be sufficient. What about now if the stub network is multihomed, in that the second link connects to either another of the upstream provider router or even to another point of presence. Well in this case we use BGP. There may be a temptation to be a little bit lazy and say "ah we'll just use OSPF or IS-IS", but actually BGP is the correct and only protocol to use. It is an exterior gateway protocol operating between two different autonomous networks. An IGP, if you remember, is an interior gateway protocol and only operates inside an autonomous system. So in this case we use a private AS number. There's no need for a public AS number for only two links out of the same upstream provider, of course if the end site has a public AS number that can be used as well, but the registries normally will not assign an AS number if the end site is simply connecting to one other provider. The upstream ISP will advertise the stub network as it advertises any other customers And again any policy is confined within the upstream ISPs policy. To emphasize it is important not to use an IGP for the multihoming in this example. Consider this case, if you're using OSPF and the upstream provider uses OSPF, how would you stop the leaking of prefixes from upstream provider network into the customer network? And how would you stop the customer prefixes leaking into the upstream provider? OSPF and IS-IS as well have very very rudimentary filtering capabilities and we're never designed to do anything like this. It also would be extremely bad for the upstream provider because they end up with more prefixes, more unnecessary prefixes appearing in their IGP especially after they've spent so much time and effort ensuring that they minimize the number of prefixes in their IGP in the first place. So the strong recommendation here is use BGP. There are plenty of private AS numbers available and there are many well-known configuration examples available to show how this is configured. And will show some of these later on in this series. The final example I want to look at is really the main example that we want to tackle in this series. If you look at the diagram, AS100 is multihomed between AS200 and AS300. The upstream providers connect to the global internet. You have two links from AS100 to AS200. We'll need to balance traffic over those somehow. And the link to AS300, well we want to balance traffic between AS300 and AS200 somehow as well. We could have one AS providing backup to the other one? Or maybe one of the two links between AS100 and AS200 provides backup to the other link? How to tackle this is really the goal of the next set of examples in this series. There is no magic bgp multihome command available in any vendor CLI that will make this work just like that. This is where an understanding of how to implement policies within BGP become very important to give an effective solution to solving this particular problem.
© 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.