Multiprotocol BGP (MP-BGP) Configuration

[lagapidis (Lazarus Agapidis)]

Hello David

@davidilles

First of all, what’s up with these unicast/multicast address families?

In situations where you want to run multicast services across multiple ASes, you can use MP-BGP to ensure that multicast routing information is propagated from AS to AS. PIM is the protocol used inside an AS for routing of multicast traffic. It establishes multicast distribution trees and propagates multicast traffic along these trees within the AS. MP-BGP, on the other hand, is an extension of BGP that supports multicast. It’s used to carry multicast routing information between different ASes.

@davidilles

I can see the IPv4 next-hop (R2) but what’s up with the ::FFFF before it? What does it mean? Is it really necessary to configure an IPv6 Next-Hop if there already is an IPv4 one?

When you see an IPv6 address starting with ::FFFF: followed by an IPv4 address, this is an example of an IPv4-mapped IPv6 address. This special type of address is used to represent an IPv4 address in an IPv6 format. These mapped addresses are used in a dual-stack environment where both IPv4 and IPv6 are deployed. IPv4-mapped IPv6 addresses provide a mechanism for IPv6 applications to communicate with IPv4 applications and vice versa.

When exchanging IPv6 prefixes over an IPv4 peering link, the next hop address for IPv6 routes will be indicated using an IPv4-mapped IPv6 address. This is because the BGP session itself is established using IPv4, so the next hop for IPv6 routes must be represented in a form that’s compatible with the underlying IPv4 transport, hence the use of IPv4-mapped IPv6 addresses. For Cisco devices this should work fine, however, it is not ideal, and this is the reason Rene added the IPv6 addresses on the interfaces.

@davidilles

So we can basically carry IPv4 prefix information within an IPv6 BGP session and vice-versa. However, it’s for the best to have a separate session for both address families, correct?

It is preferable to do so yes, primarily to keep things organized and manageable from an administrative point of view. It is much easier to understand and to troubleshoot such a configuration.

@davidilles

Also, isn’t it better to set the link-local address as the next hop instead of the GUA?

Either global unicast or link-local addresses can be used for this purpose. However, it is generally preferable to use the global unicast, and here are some reasons why:

1. Link-local addresses are only locally significant. Therefore you can only create BGP peerings with directly connected peers. That means that you cannot use them for iBGP, nor for multi-hop eBGP.
2. Link-local addresses are auto-generated based on the interface MAC address, and can change if the interface or hardware is replaced. (one resolution to this is to statically configure the link-local address, but the rest of the problems persist)
3. Using global unicast addresses makes it easier to manage and troubleshoot the network since you can ping BGP peer addresses from several hops away.

These are just some thoughts. TEchnically, you can use the link-local addresses as long as your BGP peer is directly connected, however, generally, it is preferrable to use the global unicast.

Great to hear that your studies of BGP are complete here, and glad to hear that the site and the forum have all been helpful to you! Looking forward to seeing you in other areas of the forum as well!

I hope this has been helpful!

Laz