BGP IPv6 Configuration

Module Introduction

Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:

student@tour:~/trainings_resources/robot$ robot bgp_ipv6/bgp_ipv6_setup.robot

BGP IPv6 Support

In its original specification, BGP only supported IPv4 route exchange, i.e., the Network Layer Reachability Information (NLRI) only supports IPv4 prefixes.

In order to allow non-IPv4 routes to be exchanged via BGP, RFC2283 introduces a concept called multiprotocol extensions which enables BGP to carry routing information for other network protocols as well. For this purpose, the multiprotocol reachable NLRI (MP_REACH_NLRI) and the multiprotocol unreachable NLRI (MP_UNRECH_NLRI) are introduced, which allow a wide range of network protocols to be supported. BGP uses address family identifier (AFI) and subsequent address family identifier (SAFI) to identify the network protocol that is being advertised. For a complete list of AFIs and SAFIs refer to IANA AFI Values and IANA SAFI Values.

The AFI for IPv6 is 2, and the SAFI for unicast is 1, i.e., we need BGP to exchange MP_REACH_NLRIs with AFI/SAFI=2/1.

Please keep in mind, that BGP uses TCP connections to establish BGP control plane sessions for information exchange. However, the AFI/SAFI of the advertised routes does not have to match the address family of the control plane session, i.e., it is possible to exchange IPv6 routing information across an IPv4 BGP connection.

Configuring Dual Stack across IPv4 Sessions

In the last section we have learned how to configure BGP for IPv4 using an IPv4 transport connection. In order to support IPv4 routing it was necessary to enable IPv4 unicast at the

instance level (set instance <instance> address-family …)
protocol level (set instance <instance> protocol bgp address-family …)
peer-group level (set instance <instance> protocol bgp peer-group <pgname> address-family …)

In order to add IPv6 unicast support on an existing BGP session, we only need to add the corresponding address-family on those levels.

Exercise 1: Configuring BGP Dual Stack with IPv4 Control Plane

On router R1, configure BGP in instance default with ASN 64501. Configure a BGP session to router R2 (IP address 172.16.0.2 ) in AS 64502 with TCP authentication (key-id 1, password rtbrick and type HMAC-SHA-256-128). Both address-families, IPv4 Unicast and IPv6 Unicast, should be supported.

Click to reveal the answer

cfg> set instance default protocol bgp hostname R1
cfg> set instance default protocol bgp local-as 64501
cfg> set instance default protocol bgp router-id 192.168.0.1
cfg> set instance default protocol bgp address-family ipv4 unicast
cfg> set instance default protocol bgp address-family ipv6 unicast
cfg> set instance default tcp authentication BGP type HMAC-SHA-256-128
cfg> set instance default tcp authentication BGP key1-id 1
cfg> set instance default tcp authentication BGP key1-encrypted-text $21e4946e31b406de98b3077aef03ed5a7
cfg> set instance default protocol bgp peer-group ISP2 remote-as 64502
cfg> set instance default protocol bgp peer-group ISP2 address-family ipv4 unicast
cfg> set instance default protocol bgp peer-group ISP2 address-family ipv6 unicast
cfg> set instance default protocol bgp peer ipv4 172.16.0.2 172.16.0.1 authentication-id BGP
cfg> set instance default protocol bgp peer ipv4 172.16.0.2 172.16.0.1 peer-group ISP2
cfg> commit
cfg> show bgp peer
Instance: default
  Peer                       Remote AS    State         Up/Down Time               PfxRcvd              PfxSent
  R2                         64502        Established   0d:00h:01m:13s             12                   12

Now that we have dual stack IPv4 and IPv6 support, let’s have a look at the BGP peer details:

cfg> show bgp peer R2
Peer: R2, Peer IP: 172.16.0.2, Remote AS: 64502, Local: 172.16.0.1, Local AS: 64501, Any AS: False
  Type: ebgp, State: Established, Up/Down Time:
  Discovered on interface: -
  Last transition: Thu Aug 01 10:24:22 GMT +0000 2024, Flap count: 0
  Peer ID        : 192.168.0.2, Local ID  : 192.168.0.1
  Instance       : default, Peer group: ISP2
  6PE enabled    : False
  Timer values:
    Peer keepalive : 30s, Local keepalive: 30s
    Peer holddown  : 90s, Local holddown : 90s
    Connect retry  : 30s
  Timers:
    Connect retry timer : 0s
    keepalive timer     : expires in 17s 965173us
    Holddown timer      : expires in 1m 15s 830031us
  NLRIs:
    Sent           : ['ipv4-unicast', 'ipv6-unicast']      (1)
    Received       : ['ipv4-unicast', 'ipv6-unicast']      (1)
    Negotiated     : ['ipv4-unicast', 'ipv6-unicast']      (1)
<...>

1	Both routers advertise two address-families.

From the output above we can see, that both routers are configured to support both, IPv4 unicast and IPv6 unicast. The routers agree on the common subset.

We have already learned that the show bgp rib-in command can be used to examine the prefixes that were received from the remote peer. An interesting detail is that the nexthop addresses of the IPv6 prefixes is an IPv4 address:

cfg> show bgp rib-in
Instance: default, AFI: ipv4, SAFI: unicast
 Hostname: R2, Peer IP: 172.16.0.2
 Source IP: 172.16.0.1, Received routes: 6
    Prefix                             Next Hop                      MED        Lpref      AS Path    Status
    172.16.102.0/24                    172.16.0.2                    0          -          64502      Valid
    172.16.103.0/24                    172.16.0.2                    0          -          64502, 64503 Valid
    172.16.104.0/24                    172.16.0.2                    0          -          64502, 64504 Valid
    192.168.0.102/32                   172.16.0.2                    0          -          64502      Valid
    192.168.0.103/32                   172.16.0.2                    0          -          64502, 64503 Valid
    192.168.0.104/32                   172.16.0.2                    0          -          64502, 64504 Valid
Instance: default, AFI: ipv6, SAFI: unicast
 Hostname: R2, Peer IP: 172.16.0.2
 Source IP: 172.16.0.1, Received routes: 6
    Prefix                             Next Hop                      MED        Lpref      AS Path    Status
    2001:db8:2::/48                    172.16.0.2                    0          -          64502      Valid
    2001:db8:3::/48                    172.16.0.2                    0          -          64502, 64503 Valid
    2001:db8:4::/48                    172.16.0.2                    0          -          64502, 64504 Valid
    fc00:c0a8::192:168:0:102/128       172.16.0.2                    0          -          64502      Valid
    fc00:c0a8::192:168:0:103/128       172.16.0.2                    0          -          64502, 64503 Valid
    fc00:c0a8::192:168:0:104/128       172.16.0.2                    0          -          64502, 64504 Valid

The Multiprotocol Extensions specification demands that the nexthop field must be encoded with the same address family as the NLRI. Hence, the nexthop is represented as IPv4-embedded IPv6 address in the BGP updates, e.g., 0:0:0:0:0:ffff:172.16.0.2.

Exercise 2: Configuring Redistribution

On router R1, configure the redistribution of static and direct routes into BGP for both, IPv4 and IPv6

Click to reveal the answer

cfg> set instance default protocol bgp address-family ipv4 unicast redistribute direct
cfg> set instance default protocol bgp address-family ipv4 unicast redistribute static
cfg> set instance default protocol bgp address-family ipv6 unicast redistribute direct
cfg> set instance default protocol bgp address-family ipv6 unicast redistribute static
cfg> commit

Configuring Dual Stack across IPv6 Sessions

We have already menetioned that control plane and data plane are separated, thus allowing to establish a BGP session between two peers using an IPv6-based TCP session instead of IPv6. The configuration is alike.

Exercise 3: Configuring BGP Dual Stack with IPv6 Control Plane

On router R1, configure a BGP session to router R3 (IPv6 address fc00:c0a8:0:3:172:16:0:6 ) in AS 64503 with the same TCP authentication as in the previous exercise). Both address-families, IPv4 Unicast and IPv6 Unicast, should be supported.

Click to reveal the answer

cfg> set instance default protocol bgp peer-group ISP3 remote-as 64503
cfg> set instance default protocol bgp peer-group ISP3 address-family ipv4 unicast
cfg> set instance default protocol bgp peer-group ISP3 address-family ipv6 unicast
cfg> set instance default protocol bgp peer ipv6 fc00:c0a8:0:3:172:16:0:6 fc00:c0a8:0:3:172:16:0:5 authentication-id BGP
cfg> set instance default protocol bgp peer ipv6 fc00:c0a8:0:3:172:16:0:6 fc00:c0a8:0:3:172:16:0:5 peer-group ISP3
cfg> commit
cfg> show bgp peer
Instance: default
  Peer                       Remote AS    State         Up/Down Time               PfxRcvd              PfxSent
  R2                         64502        Established   0d:00h:13m:21s             12                   20
  R3                         64503        Established   0d:00h:00m:27s             6                    20

Once again, we look at the peer details and realize that the output is almost identical except the Peer IP and Local address:

cfg> show bgp peer R3
Peer: R3, Peer IP: fc00:c0a8:0:3:172:16:0:6, Remote AS: 64503, Local: fc00:c0a8:0:3:172:16:0:5, Local AS: 64501, Any AS: False
  Type: ebgp, State: Established, Up/Down Time:
  Discovered on interface: -
  Last transition: Thu Aug 01 10:37:16 GMT +0000 2024, Flap count: 0
  Peer ID        : 192.168.0.3, Local ID  : 192.168.0.1
  Instance       : default, Peer group: ISP3
  6PE enabled    : False
  Timer values:
    Peer keepalive : 30s, Local keepalive: 30s
    Peer holddown  : 90s, Local holddown : 90s
    Connect retry  : 30s
  Timers:
    Connect retry timer : 0s
    keepalive timer     : expires in 1111111us
    Holddown timer      : expires in 1m 8s 732447us
  NLRIs:
    Sent           : ['ipv4-unicast', 'ipv6-unicast']
    Received       : ['ipv4-unicast', 'ipv6-unicast']
    Negotiated     : ['ipv4-unicast', 'ipv6-unicast']
<...>

However, from the output of the show bgp rib-in command we notice that there are no IPv4 unicast routes learned!

cfg> show bgp rib-in ipv6 unicast peer R3
Instance: default, AFI: ipv6, SAFI: unicast
 Hostname: R3, Peer IP: fc00:c0a8:0:3:172:16:0:6
 Source IP: fc00:c0a8:0:3:172:16:0:5, Received routes: 6
    Prefix                                   Next Hop                                 MED        Lpref      AS Path    Status
    2001:db8:2::/48                          fc00:c0a8:0:3:172:16:0:6                 0          -          64503, 64502 Valid
    2001:db8:3::/48                          fc00:c0a8:0:3:172:16:0:6                 0          -          64503      Valid
    2001:db8:4::/48                          fc00:c0a8:0:3:172:16:0:6                 0          -          64503, 64504 Valid
    fc00:c0a8::192:168:0:102/128             fc00:c0a8:0:3:172:16:0:6                 0          -          64503, 64502 Valid
    fc00:c0a8::192:168:0:103/128             fc00:c0a8:0:3:172:16:0:6                 0          -          64503      Valid
    fc00:c0a8::192:168:0:104/128             fc00:c0a8:0:3:172:16:0:6                 0          -          64503, 64504 Valid
cfg> show bgp rib-in ipv4 unicast peer R3
cfg>

The reason for this behavior is that the BGP peer address and then therefore the nexthop address is an IPv6 address. We have learned that the NLRI and NEXT_HOP field must belong to the same address-family. In contrast to IPv6, where this problem is solved using IPv4-embedded IPv6 addresses, this is not so easy for IPv4 because there is no corresponding mapping. In addition, the standard NEXT_HOP field is only 32-bit long and therefore does not allow an IPv6 address.

The solution to this problem is to use

an MP_REACH_NLRI with AFI/SAFI=1/1 instead of the standard NLRI, which resolves the restriction on the next hop length
the extended nexthop capability defined in RFC 5549, which allows the BGP peers to use a different address-family for the nexthop.

Exercise 4: Configuring Extended Nexthop for IPv4

On router R1, enable the extended-nexthop feature for address-family IPv4 unicast in the peer-group for R3.

Click to reveal the answer

cfg> set instance default protocol bgp peer-group ISP3 address-family ipv4 unicast extended-nexthop true
cfg> commit
cfg> show bgp rib-in ipv4 unicast peer R3
Instance: default, AFI: ipv4, SAFI: unicast
 Hostname: R3, Peer IP: fc00:c0a8:0:3:172:16:0:6
 Source IP: fc00:c0a8:0:3:172:16:0:5, Received routes: 6
    Prefix                                   Next Hop                                 MED        Lpref      AS Path    Status
    172.16.102.0/24                          fc00:c0a8:0:3:172:16:0:6                 0          -          64503, 64502 Valid
    172.16.103.0/24                          fc00:c0a8:0:3:172:16:0:6                 0          -          64503      Valid
    172.16.104.0/24                          fc00:c0a8:0:3:172:16:0:6                 0          -          64503, 64504 Valid
    192.168.0.102/32                         fc00:c0a8:0:3:172:16:0:6                 0          -          64503, 64502 Valid
    192.168.0.103/32                         fc00:c0a8:0:3:172:16:0:6                 0          -          64503      Valid
    192.168.0.104/32                         fc00:c0a8:0:3:172:16:0:6                 0          -          64503, 64504 Valid

Summary

If you have completed the exercise, you can check the results by executing

student@tour:~/trainings_resources/robot$ robot bgp_ipv6/bgp_ipv6_verify.robot