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