Chapter 6: BGP Unnumbered for IPv4
Introduction
This chapter explains how an IPv6-only
transport network can provide connectivity between IPv4 networks by using IPv6
link-local addresses as next-hop addresses for IPv4 routes.
The first part of the chapter starts by
showing how to configure interfaces to enable IPv6 and automatically generate
IPv6 link-local addresses. These addresses can then be advertised to IPv6 peers
using Router Advertisement (RA) messages defined by the IPv6 Neighbor Discovery
Protocol (NDP). This provides the IPv6 link-local addressing required to
establish BGP Unnumbered peering. Because the focus of the book is SONiC NOS,
this section also shows how locally configured, interface-specific IPv6 information,
as well as information received from neighboring devices, is represented in the
SONiC Redis databases.
The second part of the chapter introduces how
to configure external BGP peering using IPv6 link-local addresses without
explicitly specifying the neighbor's IPv6 address or ASN. This simplifies
automation by reducing the number of switch-specific configuration parameters. As
in the first part, we examine the relevant Redis database tables after
configuration and verification.
Figure 6-1 depicts the example topology used
in this chapter. The physical topology is based on two-tiers Clos topology,
with a single BGP ASN for the spine switches and a switch-specific ASN for each
leaf switch. All inter-switch links are IPv6-only.
Figure 6-1: Two-Tier, Three-Stages
Clos Topology.
IPv6 Link-Local Address Advertisement
A traditional way of configuring BGP peering
is to define the neighbor's IPv4 or IPv6 address and peer ASN. After the
configuration is complete, the BGP speaker establishes a TCP connection with
the configured peer and then begins BGP session negotiation. With BGP
Unnumbered, the peer's IPv6 address does not need to be explicitly configured
because the directly connected peer can be identified through the interface and
its IPv6 link-local address. Instead, the BGP session can use IPv6 link-local
addresses associated with the directly connected interfaces. IPv6 Neighbor
Discovery (ND) provides the mechanisms used to discover and communicate with
the directly connected IPv6 peer.
Figure 6-2 shows the configuration used to
enable IPv6 on Ethernet 0. We first bring the interface up using the SONiC
command sudo config interface startup Ethernet 0 and then enable the interface
with the no shutdown command in sonic-cli. We then enable IPv6 on Ethernet 0
with the ipv6 enable command.
When IPv6 is enabled, the interface is
assigned an IPv6 link-local address. In this example, the link-local address is
generated from the interface's link-layer address 0c:cb:81:19:00:0a using the
modified EUI-64 format.
To construct the modified EUI-64 interface
identifier, the MAC address is first divided into two 24-bit halves:
0c:cb:81 + 19:00:0a
The value ff:fe is inserted between the two
halves:
0c:cb:81:ff:fe:19:00:0a
The Universal/Local (U/L) bit in the first
byte is then inverted. The first byte 0c is 00001100 in binary. Flipping the
U/L bit changes it to 00001110, which is 0e in hexadecimal. The resulting
modified EUI-64 interface identifier is therefore:
0e:cb:81:ff:fe:19:00:0a
The IPv6 link-local prefix fe80::/64 is then
combined with this interface identifier, producing:
fe80:0000:0000:0000:0ecb:81ff:fe19:000a
or, in compressed IPv6 notation:
fe80::ecb:81ff:fe19:a
After the interface has been enabled and
assigned its link-local address, we enable Router Advertisement (RA) messages
with the no ipv6 nd suppress-ra command. In this example, the RA interval is
also configured to five seconds. The RA messages allow the router to advertise
IPv6 information on the local link, including its link-local address.
After the configuration is applied on both
switches shown in Figure 6-2, each switch periodically sends ICMPv6 Router
Advertisement messages. The RA is sent from the interface's link-local IPv6
address to the IPv6 all-nodes multicast address ff02::1. The corresponding
Ethernet destination MAC address is 33:33:00:00:00:01. IPv6 multicast addresses
are mapped to Ethernet multicast addresses by prepending the 33:33 prefix to
the lower 32 bits of the IPv6 multicast address. The lower 32 bits of ff02::1
are 00:00:00:01, resulting in 33:33:00:00:00:01. The Ethernet source MAC
address is the MAC address of the transmitting interface.
Within the ICMPv6 Router Advertisement
message, the Source Link-Layer Address option can contain the interface MAC
address. This allows a receiving IPv6 node to associate the router's advertised
link-local address with its link-layer address. The receiver can learn both the
router's IPv6 link-local address and the corresponding link-layer address from
the RA.
The IPv6 link-local address and Neighbor
Discovery information established through this process provide the IPv6
connectivity required by the BGP Unnumbered configuration described in the next
section.
Example 6-1, after the figure 6-2, shows a partial
packet capture showing ICMPv6 Router Advertisements messages sent and received
by Leaf-101.
Figure 6-2: Topology.
tcpdump: listening on
Ethernet0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
07:52:37.640210 IP6
(flowlabel 0x0c9b5, hlim 255, next-header ICMPv6 (58) payload length: 24)
fe80::e22:34ff:feb6:a > ff02::1: [icmp6 sum ok] ICMP6, router advertisement,
length 24
hop limit 64, Flags [none], pref
medium, router lifetime 15s, reachable time 0ms, retrans timer 0ms
source link-address option (1),
length 8 (1): 0c:22:34:b6:00:0a
0x0000: 0c22 34b6 000a
07:52:40.874181 IP6
(flowlabel 0x8b676, hlim 255, next-header ICMPv6 (58) payload length: 24)
fe80::ecb:81ff:fe19:a > ff02::1: [icmp6 sum ok] ICMP6, router advertisement,
length 24
hop limit 64, Flags [none], pref
medium, router lifetime 15s, reachable time 0ms, retrans timer 0ms
source link-address option (1),
length 8 (1): 0c:cb:81:19:00:0a
0x0000: 0ccb 8119 000a
Example 6-1: Packet Capture: Router
Advertisement Messages.
Verification
The two examples shown in the upper part of
Figure 6-3, obtained from sonic-cli and the Linux Bash shell, show the IPv6
addressing information for Leaf-101. The show ipv6 interface command displays
the IPv6 configuration and interface state from the SONiC perspective. Ethernet
0 has the IPv6 link-local address fe80::ecb:81ff:fe19:a/64, and both its
administrative and operational states are up. The ip link show Ethernet0
command displays the underlying Linux interface information, including the
interface's link-layer MAC address.
Figure 6-3: Leaf-101 Link-Local and
Link-Layer Address Verification.
The Linux command ip -6 neigh show dev
Ethernet0 verifies that the Leaf-101 Linux kernel has a neighbor entry for
Spine-11's IPv6 link-local address and its corresponding link-layer address.
The neighbor entry is in the REACHABLE state, indicating that the neighbor has
recently been confirmed as reachable by IPv6 Neighbor Discovery. The sonic-cli
command show ipv6 neighbors interface Ethernet0 provides the same information,
displaying both the IPv6 link-local address and its corresponding link-layer
address. The Fwd (Forward) value in the Action field indicates that the
neighbor entry is available for forwarding.
The sonic-cli
command show ipv6 nd ra-interfaces Ethernet0 displays the Router Advertisement
configuration for Ethernet0. The output confirms that Router Advertisements are
sent every five seconds, that 12 Router Advertisements have been sent and none
have been received, and that the advertised Hop Limit is 64. These values can
be compared with the Router Advertisement messages captured with tcpdump in
Example 6-1. The packet capture shows Router Advertisements from both Spine-11
and Leaf-101, with the advertised Hop Limit of 64 visible in each RA.
The packet
capture also shows hlim 255 in the IPv6 header of each Router Advertisement.
This value is different from the advertised Hop Limit of 64 contained in the RA
message. The value 255 is the Hop Limit of the Router Advertisement packet
itself, while the value 64 is the Hop Limit that the router advertises for
hosts to use in subsequently generated IPv6 packets.
Figure 6-4: Leaf-101 IPv6 Peer
Spine-11 IPv6 Link-Local and Link Layer Addressing.
CONFI_DB, APPL_DB Databases and config_db.json file
Figure 6-5 shows the corresponding entries in
CONFIG_DB, APPL_DB, and the config_db.json file after enabling IPv6 and Router
Advertisement (RA) messages on Ethernet0 of Leaf-101.
The configuration updates the CONFIG_DB
INTERFACE|Ethernet0 table with the field/value pair
"ipv6_use_link_local_only": "enable". This specifies that
Ethernet0 uses only an IPv6 link-local address rather than a manually
configured IPv6 address. The ND_CFG_MSG|Ethernet0 table contains the Neighbor
Discovery configuration, showing an RA interval of 5 seconds with RA
suppression disabled. Consequently, Leaf-101 is configured to advertise Router
Advertisement messages on Ethernet 0.
The intfmgrd daemon, SONiC's interface
manager, monitors interface configuration in CONFIG_DB and translates it into
the application-level representation used by APPL_DB. In this example, APPL_DB
contains an INTERFACE_TABLE:Ethernet0 entry corresponding to the interface
configuration. It also contains an INTF_TABLE entry for Ethernet0 with the IPv6
prefix fe80::ecb:81ff:fe19:a/64. The entry identifies the address family as
IPv6, specifies link_local_mode as auto, and indicates that the address has
local scope. This represents Leaf-101's automatically assigned IPv6 link-local
address.
APPL_DB also contains the NEIGH_REFRESH_TABLE:Ethernet0:fe80::
e22:34ff:feb6:a entry. Unlike the interface configuration and local IPv6
address, this entry represents dynamically learned information about the IPv6
neighbor on Ethernet0. The entry identifies the peer's IPv6 link-local address
and its link-layer address, 0c:22:34:b6:00:0a. The isrouter field is set to 1,
indicating that the neighbor is identified as a router.
The neighbor information originates from IPv6
Neighbor Discovery processing in the Linux kernel. The peer's Router
Advertisements identify it as an IPv6 router, while the Linux IPv6 neighbor
table maintains the neighbor's IPv6-to-link-layer address mapping. SONiC
synchronizes the resulting neighbor state into its application-level
processing, where it becomes available in APPL_DB for further processing by
orchagent.
Figure 6-5 also shows the corresponding
entries in the config_db.json file. These entries represent persistent
configuration and correspond to the configuration stored in CONFIG_DB. The
dynamically learned neighbor information is not present in config_db.json
because it originates from IPv6 Neighbor Discovery rather than from the
configured state.
Figure 6-5: CONFIG_DB, APPL_DB Databases
and Config_db.json file.
ASIC_DB
After the IPv6 neighbor information has been
processed by orchagent, the corresponding SAI objects are represented in
ASIC_DB. Figure 6-6 brings these objects together to show how they are related
and how they contribute to forwarding an IPv6 packet toward the neighboring
router, Spine-11.
The easiest way to understand these objects
is to follow the forwarding relationship from the route to the egress port. The
ROUTE_ENTRY identifies the destination prefix and the virtual router in which
the route is installed. For the example in Figure 6-6, the destination prefix
is fe80::/10, and the route belongs to virtual router oid:0x300000000003a.
The route contains the ATTR_NEXT_HOP_ID
attribute, which points to the NEXT_HOP object oid:0x1000000000001. Its
ATTR_PACKET_ACTION is SAI_PACKET_ACTION_FORWARD, indicating that packets
matching the route are forwarded rather than dropped or trapped.
The NEXT_HOP object provides the IPv6 address
of the next hop and identifies the router interface through which the packet is
forwarded:
NEXT_HOP
oid:0x1000000000001
ATTR_IP:
fe80::e22:34ff:feb6:a
ATTR_ROUTER_INTERFACE_ID: oid:0x6000000000a48
The
ATTR_ROUTER_INTERFACE_ID points to the ROUTER_INTERFACE object
oid:0x6000000000a48. This object associates the L3 router interface with the
virtual router and the physical port:
ROUTER_INTERFACE
oid:0x6000000000a48
ATTR_PORT_ID:
oid:0x1000000000002
ATTR_SRC_MAC_ADDRESS: 0C:CB:81:19:00:0A
ATTR_VIRTUAL_ROUTER_ID: oid:0x300000000003a
The ATTR_PORT_ID points to the PORT object
oid:0x1000000000002, which represents Ethernet0. Thus, the router interface
ultimately identifies Ethernet0 as the egress port for the next-hop forwarding
operation.
The NEXT_HOP object also identifies the IPv6
address of the neighboring router, fe80::e22:34ff:feb6:a. ASIC_DB contains a
corresponding NEIGHBOR_ENTRY that associates this IPv6 address and router
interface with the neighbor's destination MAC address:
NEIGHBOR_ENTRY
IP:
fe80::e22:34ff:feb6:a
RIF:
oid:0x6000000000a48
ATTR_DST_MAC_ADDRESS: 0C:22:34:B6:00:0A
The orchagent log shows how the learned IPv6 neighbor information is processed. First, orchagent associates the peer's IPv6 link-local address with its MAC address on Ethernet0. It then creates a next-hop representation for the peer and maintains a MAC-to-neighbor mapping. These operations lead to the corresponding neighbor and next-hop objects being programmed into ASIC_DB.
:-
addNeighborInternal: Created neighbor ip fe80::e22:34ff:feb6:a,
0c:22:34:b6:00:0a on Ethernet0, proto:0, nbr_tbl_add:FALSE
:- addNextHop:
Created next hop fe80::e22:34ff:feb6:a|Ethernet0
:- addMactoIp:
add neighbor fe80::e22:34ff:feb6:a to macToNeigh mapping, key:(Ethernet0,
0c:22:34:b6:00:0a)
These operations result in
the corresponding neighbor and next-hop forwarding state being represented in
ASIC_DB.
This relationship is
important because the NEXT_HOP identifies the IPv6 address of the next hop,
while the NEIGHBOR_ENTRY provides the link-layer destination address required
to construct the Ethernet frame.
Figure 6-6: ASIC_DB Objects Mapping.
Figure 6-7 depicts the forwarding and neighbor resolution as chain:
Figure 6-7: Object Relationship in ASIC_DB.
No comments:
Post a Comment