BGP has been extended to support
multiple protocols.
In the early days BGP was developed purely for the IPv4
internet in mind,
and to carry just unicast IPv4 prefixes.
But in the
intervening years, the folks who've been using multicast
have developed
extensions to BGP so it can be used for a distribution of multicast prefixes.
And
with the development of IPv6 in 1995 and 1996
BGP was also extended to carry IPv6.
Rather than the, I suppose, incremental addition of support for extra protocols,
this was all refined and the resulting RFC4760
document defines how multiple
protocols will be handled within BGP itself.
So now BGP has been extended to carry routing information of protocols other
than v4.
So we've seen MPLS of course, and IPv6 as I mentioned, as well as multicast.
All these can now be handled with ease within BGP itself.
The exchange of these
multiprotocol network layer reachability information
is negotiated
when the BGP session starts up.
So if you look at the detail of a BGP neighbor being
established,
it will ask a series of questions with its immediate neighbor
about which extensions are actually supported.
And you can find these out,
again it depends on your implementation.
You can find out which of the various BGP
extensions
you and your neighbor will actually support, just from the CLI.
RFC2545, that describes the use of BGP multiprotocol extensions for v6
inter-domain routing.
So that's, in other words, how BGP can handle the
distribution of v6 prefixes across the internet.
Now to support multiple
protocols, each one operates independently.
So for example for IPv4,
the IPv4 destinations are held in BGP's IPv4 RIB.
IPv6 destinations are held in BGP's IPv6 RIB.
And there is no interaction between these two RIBs at all.
Each
protocol can have its own policies. You can implement one policy for IPv4 and
another policy for IPv6.
It's most common on the internet today as we'll discuss
throughout the series,
for network operators to implement both the same
policies for v4 and for v6.
but should there be a need for us not to do that, we
can have separate policies if we wish.
And one thing that's very very important
and a lot of people actually mistake is that,
if you have a v4 destination, the
next router to get to that destination must be
basically of the same address
family, so the same type of address, so for example
if you have a v4 destination,
the next router to get to that destination
must be reachable over IPv4.
And likewise for v6. If you have a v6 destination, the next router to get to
that destination
must be a reachable over IPv6.
We're going to look at the
"nexthop" attribute a little bit later on, and we can discuss this in a little bit
more detail then.
But this is actually a fundamentally important part,
we cannot
have a destination in one address family
that's reachable through a neighboring
router that's in a different address family.
Now for supporting multiple
protocols, most router implementations today
will have v6 turned on by default,
and make no real assumption
about any particular neighbor.
if you're still
using Cisco IOS, the older versions of IOS,
they assume that all BGP neighbors
will be exchanging v4 unicast prefixes.
Even if these neighbors have v6 addresses.
So, if you're using IOS you'll
need to remove that assumption as shown in the slides.
If you don't do that it's
not going to cause any problem,
it's just going to make the configuration look
very messy.
You end up with a configuration that shows a lot of v6
neighbors
appearing as though they have been set up to exchange v4 unicast prefixes.
And well,
this isn't actually happening, they appear in the
configuration, it makes it more cluttered
and generally it just makes
troubleshooting, and fault diagnosis
just that little bit harder.
Probably the last thing you want
when you're trying to deal with a network outage or some other
network emergency that you need to fix pretty quickly.
For operational
simplicity, what we really want is for v4 neighbors to exchange v4 prefixes,
and v6
neighbors to exchange v6 prefixes; and then we just don't have any
dependency
of one protocol on another.
© 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.