BGP address-family

When to use BGP address-family?
I commonly see BGP configured on a provider (P/PE) router like this (this is a real router snippet just anonymised);

router bgp 12345
neighbour 1.1.1.1 remote-as 12345     ! iBGP peer
address-family ipv4
neighbour 1.1.1.1 remote-as 12345     ! iBGP peer
address-family vpnv4
neighbour 1.1.1.1 remote-as 12345     ! iBGP peer
address-family ipv4 vrf Customer1
neighbour 10.0.0.1 remote-as 67890    ! eBGP peer


I understand the CE peering defined under "address-family ipv4 vrf Customer1" because we are placing their routes into that VRF
I understand that "address-family vpnv4" is used to define provider iBGP peers to which other CE's are going to be attached, carrying this customer VRF
Finally, I understand that a provider router is an iBGP peer so it is defined directly under "router bgp 12345"

What is the need for "address-family ipv4" (without vrf) here, or ever?

What does it provies that "normal" neighbour definitions (those directly under "router bgp 12345") and vpnv4 neighbour definitions, don't provide?

Hello,

The BGP, as you surely know, has a multi-protocol capability - in a single session, it is capable of carrying information about diverse routed protocols (IPv4 Unicast,
IPv4 Multicast, IPv6 Unicast, IPv6 Multicast, VPNv4, CLNP), in BGP's parlance called "address families". With BGP being a true multiprotocol routing protocol, however,
you need some means to tell BGP which address families should be exchanged with a particular neighbor. We are accustomed to the fact that if we define an IPv4
neighbor, we are planning to exchange IPv4 routes with that neighbor - but why should that actually be a rule? Why should we make hasty assumptions about the address
family just because the address of the neighbor is from a particular family itself?

This is the point behind diverse address-family commands. Defining a neighbor under a particular address family means that we want to exchange routes from the
particular address family with that neighbor. Not having a neighbor listed under a particular address family means that we are not planning to exchange information
from that address family with that neighbor.

Now, the address-family ipv4 declares neighbors with whom we want to exchange normal IPv4 unicast routes. This may be surprising because to exchange IPv4 routes with a
neighbor, it is sufficient to simply define that neighbor by its address. The fact is that for backward compatibility with older BGP versions that have not been
multiprotocol-capable, the BGP implicitly assigns all defined neighbors to an invisible address-family ipv4 section. In other words, as soon as you define a neighbor,
it is automatically being added to an invisible address-family ipv4 section so that you don't have to do it manually.

You can change it, however. First of all, if you enter the BGP configuration and issue the command bgp upgrade-cli you will find out that the BGP configuration has
been fully converted to the address family style of configuration. Outside any address-family stanzas, only the basic neighbor settings are configured like their
addresses, AS numbers, update sources. However, all remaining per-address-family commands will be automatically moved into address-family stanzas. The behavior or
operations of BGP do not change with this new style of configuration, only the configuration format is changed.

Furthermore, if you enter the no bgp default ipv4-unicast command in the BGP configuration, you will prevent BGP from automatically assigning each newly defined
neighbor into address-family ipv4 section. You will then be required to add every defined neighbor to each intended address family automatically - it won't be done
automatically for you anymore.

So to wrap it up - the address-family ipv4 is in fact an omnipresent section in the BGP configuration but for backward compatibility purposes, it is not visible by
default. However, the configuration can be converted to a strict per-address-family configuration, and in fact, I would recommend that for all new deployments.

Please feel welcome to ask further!