We will now look at multiple sessions to an ISP in a little bit more detail and this is the case where an end-user may have multiple links from their router to their neighboring autonomous system or upstream provider. There are several options available and we are going to look at ebgp multihop and bgp multipath as two of the possibilities. ebgp multi-hop has become quite widely used in the internet today for handling bgp sessions between two ASes when there are more than a single link between the two autonomous systems or even if there's some intermediate layer 3 device between the two autonomous systems. In this case we run external bgp between loopback addresses in the two devices. If you look at the diagram router A and router B are physically connected to each other. as we've seen in the examples before. However, we can't really run ebgp on the point-to-point links because the diagram has three point-to-point links. If we just run one session, which link do we use to run the session on? So this is not going to work. So instead we run ebgp between the point-to-point. So in this case we run a BGP on the loopback address. Of course, the loopback interface on router A is not directly connected to the loopback interface on router B. And one of the requirements for eBGP is that the interfaces are directly connected. So how does router A find how to get to the loopback of router B? What we have to do is put an entry in the global RIB pointing router A at the loopback of router B. In this example I have set up three serial connections between AS100 and AS200. So I put a simple static route for router B's loopback into the configuration on router A, pointing to the three serial interfaces going to AS200. A common error that folks make is to point the remote loopback route at an IP address rather than the specific link. The remote IP address could be reachable some other way. Suppose AS100 is connected to AS200 through some other path. That's a perfectly legitimate route and the ebgp-multihop will quite happily function through that other route as well. So the three parallel links shown in the diagram may be down but the bgp session may quite happily continue to function. This is not a situation that we want. The other thing to note and the Cisco IOS configuration snippet shows it, we need to change eBGP's default behavior to tell it that it's external neighbor is not directly connected and that's done by the neighbor address ebgp-multihop command The subcommand of ebgb-multihop specifies how many time to live hops away the remote address is. So we make it 2. ebgp-multihop of 1 means directly connected if the neighboring device. 2 means it's 2 hops away because the loop backs are not directly connected. They are therefore 2 hops away. This TTL value is very important as well. The biggest possible value is 255 and please don't be lazy and simply put 255 in there because that will allow your eBGP session to be established over 255 hops away. You could end up with an eBGP session going all the way around the world rather than the direct link that you had hoped for. In fact there's one serious caveat with ebgp-multihop that should make you really pause and think very hard as to whether you want to use this feature or not. If you look at this diagram, router 1 and router 3 are eBGP peers that are peering, using loopbacks and it's configured with the neighbor ebgp-multihop as we saw earlier. If the R1 to R3 link goes down then the session could establish via rR2 quite easily because R1 to R3 via R2 is still two hops away. Having seen many examples of this happen over the years where network operators and customers have configured ebgp-multihop over a primary and backup type setup and then arguments ending up between the customer and the service provider because of poor service, poor quality of the link, simply because a direct path may have gone down and the eBGP session has happily carried on over a low quality, low bandwidth backup link. And this usually happens when routing to the remote loopback is dynamic rather than static pointing at the link as I mentioned earlier. In fact, I would advise to avoid using ebgp-multihop if at all possible. In fact, the only conditions I would consider using it when there's no other choice. For example there may be a layer 3 device between your router and your peers router. In cases where satellite internet is the only option into the country or the region quite often the satellite modems are layer 3 devices that cannot do BGP. There is no choice apart from using ebgp-multihop. If you need to loadshare over multiple links from your router to your neighbor's router ebgp-multihop is a good and cost-effective solution. Or perhaps you want to get the Team Cymri bgp feed for the bogon route server which was mentioned before or you may be requested by a researcher whose interested in what the BGP table looks like in your part of the world and they will request an e BGP multihop feed so they can get a view of what your BGP table looks like in your part of the Internet. In fact, what I found over my career is many ISPs strongly discourage the use of ebgp multihop and the many documented cases of official statements or otherwise from operators who insist to customers that they will not use ebgp multihop. The second example I want to look at of how to handle multiple parallel connections between a local router and a peers router is BGP multipath. Now when this first appeared it was actually extremely useful. Internet routing table was quite small and this was a good solution to a problem of trying to get enough bandwidth between adjacent networks. If you look at this example AS100 and AS200 again have three parallel links between the router A and router B. What we do in this case is we set up three bgp sessions, one bgp session on each point-to-point link between the two autonomous systems and then turn on a BGP option called maximum paths. It depends which platform you're using. Some platforms have as little as 6 parallel paths possible, others can go up to 16 or even more. and what this does it puts three copies of the BGP table into the FIB and what happens then is the router will load balance it using the FIB to send traffic over the three links between the two autonomous systems. Just note if you're using the full BGP table today and that in October 2017 that was six hundred and seventy thousand prefixes this could get a little unwieldy, if unscalable. Three copies of 670,000 v4 prefixes makes for a rather large FIB. Otherwise the simplest scheme is to use defaults and learn or advertise prefixes for better control. Planning and some work is required to achieve good loadsharing. Pointing default towards one ISP, learning selected prefixes from the second one, modifying the number of prefixes learned to achieve acceptable load sharing. And as I said earlier there's no magic bgp multi- home configuration available on any router. It takes you, the network operator, to understand how to use the BGP attributes and how to manage aggregates and the sub prefixes to achieve the load sharing that you wish for your networking.