Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Appendix: IPv6 Overlay and Underlay eBGP Peering Towards Unmanaged SRX

Note:

We were not able to resolve the issue where vJunos-switch VMs fail to forward default traffic when using a VXLAN IPv6 underlay. As a result, this type of lab should be built entirely with physical devices!

An IPv4/IPv6 dual-stack fabric requires significantly more route resources on the global fabric route table distributed via EVPN. Since each client may use an IPv4 address, an IPv6 local address, and an IPv6 global address, you should plan for up to three times the number of route resources per client.

The use of SLAAC-based IPv6 dynamic address assignment should be avoided in this type of fabric. Clients may request multiple IPv6 addresses, potentially one per application, which further increases route resource consumption, as each address requires both local and global entries. If dynamic IPv6 address assignment is needed for clients using the EVPN fabric, plan to use DHCPv6 relay within the fabric along with a customer-provided DHCPv6 server.

When creating a new campus fabric and there is a possibility of using IPv6 as overlay transport in the future, ensure that IPv6 is also enabled for the underlay during initial setup. This approach provides the advantage of having the necessary GUI configuration options available from the start.

When you enable an IPv6 underlay, several configuration changes occur compared to the IPv4 underlay setting.

  • Instead of using the usual global routing instance called default-switch, the port interfaces configured for the EVPN fabric are moved into a mac-vrf instance called evpn_vs. From there, they may use VTEP communication for Layer 2 forwarding or VRF for Layer 3, depending on the EVPN fabric design. The difference is highlighted below:
  • The system configures both IPv4 and IPv6 for the underlay loopback IP address on the lo0.0 interface, but all BGP signaling and VXLAN data traffic are exchanged using the configured IPv6 lo0.0 address. The IPv4 loopback address can therefore be ignored.
  • You will notice minor configuration changes where additional IPv6 statements are included in the fabric configuration.
Note:

If you plan to use additional features such as multicast through additional Junos CLI configuration, it is preferable to use an IPv6 underlay, as these features may also require mac-vrf binding.

When exchanging routes with the WAN router through BGP, it is best practice to separate the peering configuration by IP version. For each EVPN fabric VRF, this means having one configuration with an IPv4-based neighbor and another with an IPv6-based neighbor. Although the Juniper EVPN fabric internally exchanges all IPv4 information over IPv6, not all WAN router vendors support this behavior. For this reason, the examples intentionally show separate IPv4 and IPv6 BGP peering configurations, even though a Juniper WAN router could operate with a more simplified, combined setup.

The configuration examples in this chapter are based on the following design principles:

  • Two redundant SRX devices are used with chassis clustering enabled.
  • Since WAN Edge for SRX does not currently provide full IPv6 support, the WAN router devices are unmanaged, and the Junos configuration is created and applied manually.
  • Depending on your preference, you can choose between two peering approaches:

Lab and Fabric Creation and Preparation

Note:

At this time, it is not possible to build a virtual lab because the vJunos-switch VM (observed in releases 24.4R1 and 25.2R1) has issues forwarding default traffic over VXLAN to the VRF on the service block function. For now, use a fully physical lab environment for testing until this issue is resolved.

The topology shown below was used for this example lab and is entirely based on physical devices.

Figure 1: The WAN routers consisted of a pair of SRX1500 devices running Junos 23.4R2-S5.5. The fabric switch models and their Junos versions can be found in the image below. Figure : IPv6 Lab devices The WAN routers consisted of a pair of SRX1500 devices running Junos 23.4R2-S5.5. The fabric switch models and their Junos versions can be found in the image below. Figure : IPv6 Lab devices

In this lab, the DHCPv4 and DHCPv6 server was located outside the fabric and was reachable through the WAN interface of the SRX1500. For lab purposes, the WAN interfaces operated at 1 Gbit/s, which is not representative of a production design.

Figure 2: IPv6 Lab Topology IPv6 Lab Topology

Below is a switch template with IPv4 and IPv6 dual stack configuration.

The installation of a Kea DHCPv4 service is described in this JVDE, so it is assumed that this step has already been completed. This section only covers the additional configuration required to enable the DHCPv6 server. Make sure the Kea version is 2.0 or later, as earlier versions do not support listening on an IPv6 socket interface, and the fabric operates solely as a DHCP relay.

First, add IPv6 interface configuration to the DHCP server VM using Netplan, as shown in the example below. Additional adjustments may be required for a production deployment, since the IP addresses 192.168.10.99 and fd00:1234:5678:0010::99 are bound only to WAN router node0 for debugging purposes.

Below is the additional IPv6 configuration for the Kea DHCP server, to be added to the existing DHCPv4 setup for three VLANs in the EVPN fabric, along with basic testing steps. The configuration is relatively straightforward.

As mentioned earlier, using an IPv6 underlay configuration is mandatory if you plan to use IPv6 for overlay traffic. The relevant configuration option is shown in the next image.

If this has not been configured, you will need to schedule a maintenance window for the entire EVPN fabric to transition from an IPv4 to an IPv6 underlay, validate the new IPv6 underlay, and then return the fabric to production. If the fabric was previously using an IPv4 underlay, some of the new fields may appear empty. In that case, refer to the image below and reuse the values shown there to populate those fields.

Figure 3: Required IPv6 underlay configuration Required IPv6 underlay configuration

On the surface, the setup for VLANs and VRFs looks the same as the previous IPv4-only configuration..

Figure 4: Fabric Networks configuration Page Fabric Networks configuration Page

When reviewing the Other IP Configuration for the listed switches, as shown in the example below, you should now see additional IPv6 anycast or static IPv6 VGA IP settings. It is important to verify that this configuration has been applied correctly.

Figure 5: Added IPv6 Gateway configuration Added IPv6 Gateway configuration

Naturally, you also need to add IPv6 DHCP server IP addresses as in the lab example shown below.

Figure 6: Added IPv6 DHCP-Relay configuration Added IPv6 DHCP-Relay configuration

With this complete, your lab should be ready to support an IPv4 and IPv6 dual-stack configuration. The next step is to choose, based on your preference or the capabilities of the WAN router, the approach for connecting the WAN router to the fabric. The recommended method is to use eBGP peering.

We have documented two eBGP peering approaches:

Please select one of the two for your EVPN fabric.

All Links Peering eBGP Scenario Implementation

The approach used in this section is fully described in the Juniper SRX Series Firewall as WAN Router section. As before, AS path prepending is applied to the second WAN router node to make it less preferred. For the full configuration example, refer to that section; here, only the additional IPv6-related configuration elements are shown to keep the focus on the differences.

The table below provides the complete configuration between the service1 and service2 switches in the service block function and the two SRX WAN routers. The IPv6-related configuration items are highlighted for clarity.

Switch Switch AS VRF Service P2P IP Service IF WAN Router WAN Router P2P IP WAN Router AS WAN Router IF VLAN ID
service1 64911 customera

10.255.224.1/31

fd00:1234:5678:224::1/127

xe-0/0/36.1091 node0

10.255.224.0/31

fd00:1234:5678:224::/127

64901 xe-0/0/16.1091 1091
service1 64911 customerb

10.255.224.3/31

fd00:1234:5678:224::3/127

xe-0/0/36.1081 node0

10.255.224.2/31

fd00:1234:5678:224::2/127

64901 xe-0/0/16.1081 1081
service1 64911 devices

10.255.224.5/31

fd00:1234:5678:224::5/127

xe-0/0/36.1031 node0

10.255.224.4/31

fd00:1234:5678:224::4/127

64901 xe-0/0/16.1031 1031
service1 64911 customera

10.255.225.1/31

fd00:1234:5678:224::101/127

xe-0/0/37.1099 node1

10.255.225.0/31

fd00:1234:5678:224::100/127

64901 xe-7/0/16.1099 1099
service1 64911 customerb

10.255.225.3/31

fd00:1234:5678:224::103/127

xe-0/0/37.1088 node1

10.255.225.2/31

fd00:1234:5678:224::102/127

64901 xe-7/0/16.1088 1088
service1 64911 devices

10.255.225.5/31

fd00:1234:5678:224::105/127

xe-0/0/37.1033 node1

10.255.225.4/31

fd00:1234:5678:224::104/127

64901 xe-7/0/16.1033 1033
service2 64911 customera

10.255.226.1/31

fd00:1234:5678:224::201/127

xe-0/0/36.1091 node0

10.255.226.0/31

fd00:1234:5678:224::200/127

64901 xe-0/0/17.1091 1091
service2 64911 customerb

10.255.226.3/31

fd00:1234:5678:224::203/127

xe-0/0/36.1081 node0

10.255.226.2/31

fd00:1234:5678:224::202/127

64901 xe-0/0/17.1081 1081
service2 64911 devices

10.255.226.5/31

fd00:1234:5678:224::205/127

xe-0/0/36.1031 node0

10.255.226.4/31

fd00:1234:5678:224::204/127

64901 xe-0/0/17.1031 1031
service2 64911 customera

10.255.227.1/31

fd00:1234:5678:224::301/127

xe-0/0/37.1099 node1

10.255.227.0/31

fd00:1234:5678:224::300/127

64901 xe-7/0/17.1099 1099
service2 64911 customerb

10.255.227.3/31

fd00:1234:5678:224::303/127

xe-0/0/37.1088 node1

10.255.227.2/31

fd00:1234:5678:224::302/127

64901 xe-7/0/17.1088 1088
service2 64911 devices

10.255.227.5/31

fd00:1234:5678:224::305/127

xe-0/0/37.1033 node1

10.255.227.4/31

fd00:1234:5678:224::304/127

64901 xe-7/0/17.1033 1033

As in the previous sections, the following provides a description of the configuration that needs to be applied on the service1 switch toward the WAN router.

After completing the configuration on the service1 switch, the following provides a description of what needs to be configured on the service2 switch toward the WAN router.

After the changes on the two EVPN fabric switches are made, take a moment to review the changes. You should now see configuration similar to the image below.

The additional IP configuration now has IPv4 and IPv6 addresses.

Figure 7: IPv4 and IPv6 Additional IP Configuration IPv4 and IPv6 Additional IP Configuration

There are no significant differences in the uplink port configuration, so the focus shifts to the BGP peering groups. With three VRFs, each service block function in the fabric peers with two redundant WAN routers. When the BGP peering is separated into IPv4 and IPv6, as recommended, this results in a total of twelve BGP peer groups, as shown below.

Figure 8: BGP-Peering configuration BGP-Peering configuration

Each of the three BGP routing policies now have added IPv6 configuration statements for simplification.

Figure 9: Added BGP Policy Added BGP Policy

For instance, the export-vrf0 policy now includes two final statements to maintain consistency with the IPv6 setup.

Figure 10: Example of added IPv6 policy statements Example of added IPv6 policy statements

The following example illustrates the WAN router configuration to be applied to the SRX chassis cluster.

Testing Your WAN Router EVPN Fabric Integration

The required configuration on both the EVPN fabric and the WAN router has been completed, and testing of the IPv4 and IPv6 dual-stack setup can now begin. The process starts by examining the first service block function, the service1 switch.

Now we look at the SRX chassis cluster WAN router side:

After verifying the route exchanges, the next step is to test client traffic both within the network and through the WAN router. This begins with a Linux desktop client VM configured with static IPv4 and IPv6 addresses.

The next test uses a Linux-based desktop client VM that initially has no assigned IP addresses, aside from the local IPv6 address, and must obtain IPv4 and IPv6 addresses dynamically through DHCP.

Active/Passive LAG eBGP Scenario Implementation

The approach used in this section is already described in Appendix: WAN Edge SSR or SRX Juniper Mist Cloud-managed eBGP Peering via Active/Passive LAG. On the SRX chassis cluster, this requires the use of reth interfaces along with ESI-LAG configuration on the EVPN fabric side. We recommend reviewing the referenced chapter for the complete configuration example; here, only the additional IPv6-related configuration elements are shown to focus on the differences.

The table below shows the full configuration between service1 and service2 in the service block function and the two SRX WAN routers. The IPv6-related configuration items are highlighted for clarity.

Switch Switch AS VRF Service P2P IP Service IF WAN Router WAN Router P2P IP WAN Router AS WAN Router IF VLAN ID
service1 64911 customera

10.255.224.5/29

fd00:1234:5678:224::5/125

irb.101

xe-0/0/36

ae10.0

srx-node0

10.255.224.1/29

fd00:1234:5678:224::1/125

64901

reth3.101

xe-0/0/16

101
service1 64911 customerb

10.255.224.13/29

fd00:1234:5678:224::d/125

irb.102

xe-0/0/36

ae10.0

srx-node0

10.255.224.9/29

fd00:1234:5678:224::9/125

64901

reth3.102

xe-0/0/16

102
service1 64911 devices

10.255.224.21/29

fd00:1234:5678:224::15/125

irb.103

xe-0/0/36

ae10.0

srx-node0

10.255.224.17/29

fd00:1234:5678:224::11/125

64901

reth3.103

xe-0/0/16

103
service1 64911 customera

10.255.224.5/29

fd00:1234:5678:224::5/125

irb.101

xe-0/0/37

ae11.0

srx-node1

10.255.224.1/29

fd00:1234:5678:224::1/125

64901

reth3.101

xe-7/0/16

101
service1 64911 customerb

10.255.224.13/29

fd00:1234:5678:224::d/125

irb.102

xe-0/0/37

ae11.0

srx-node1

10.255.224.9/29

fd00:1234:5678:224::9/125

64901

reth3.102

xe-7/0/16

102
service1 64911 devices

10.255.224.21/29

fd00:1234:5678:224::15/125

irb.103

xe-0/0/37

ae11.0

srx-node1

10.255.224.17/29

fd00:1234:5678:224::11/125

64901

reth3.103

xe-7/0/16

103
service2 64911 customera

10.255.224.6/29

fd00:1234:5678:224::6/125

irb.101

xe-0/0/36

ae10.0

srx-node0

10.255.224.1/29

fd00:1234:5678:224::1/125

64901

reth3.101

xe-0/0/17

101
service2 64911 customerb

10.255.224.14/29

fd00:1234:5678:224::e/125

irb.102

xe-0/0/36

ae10.0

srx-node0

10.255.224.9/29

fd00:1234:5678:224::9/125

64901

reth3.102

xe-0/0/17

102
service2 64911 devices

10.255.224.22/29

fd00:1234:5678:224::16/125

irb.103

xe-0/0/36

ae10.0

srx-node0

10.255.224.17/29

fd00:1234:5678:224::11/125

64901

reth3.103

xe-0/0/17

103
service2 64911 customera

10.255.224.6/29

fd00:1234:5678:224::6/125

irb.101

xe-0/0/37

ae11.0

srx-node1

10.255.224.1/29

fd00:1234:5678:224::1/125

64901

reth3.101

xe-7/0/17

101
service2 64911 customerb

10.255.224.14/29

fd00:1234:5678:224::e/125

irb.102

xe-0/0/37

ae11.0

srx-node1

10.255.224.9/29

fd00:1234:5678:224::9/125

64901

reth3.102

xe-7/0/17

102
service2 64911 devices

10.255.224.22/29

fd00:1234:5678:224::16/125

irb.103

xe-0/0/37

ae11.0

srx-node1

10.255.224.17/29

fd00:1234:5678:224::11/125

64901

reth3.103

xe-7/0/17

103

As in the previous sections, the following provides a description of the configuration that needs to be applied on the service1 switch toward the WAN router.

After completing the configuration on the service1 switch, the following provides a description of what needs to be configured on the service2 switch toward the WAN router.

After the changes on the two EVPN fabric switches are made, take a moment to review the changes. You should now see configuration similar to the image below.

The additional IP configuration now has IPv4 and IPv6 addresses.

Figure 11: IPv4 and IPv6 Additional IP Configuration IPv4 and IPv6 Additional IP Configuration

There are no significant differences in the uplink port ESI-LAG configuration, so the focus shifts to the BGP peering groups. With three VRFs and, following the recommendation to separate BGP peering into IPv4 and IPv6, the result is a total of six BGP peer groups, as shown below.

Figure 12: BGP-Peering configuration BGP-Peering configuration

Each of the two BGP routing policies now have IPv6 configuration statements added for simplification.

Figure 13: Added BGP Policy Added BGP Policy

For instance, the export-vrfs policy now includes two final statements to maintain consistency with the IPv6 setup.

Figure 14: Example of added IPv6 policy statements Example of added IPv6 policy statements

The following example illustrates the WAN router configuration to be applied to the SRX chassis cluster.

Testing Your WAN Router EVPN Fabric Integration

The required configuration on both the EVPN fabric and the WAN router has been completed, and testing of the IPv4 and IPv6 dual-stack setup can now begin. The process starts by examining the first service block function, the service1 switch.

Now we look at the WAN router side:

After verifying the route exchanges, the next step is to test client traffic both within the network and through the WAN router. This begins with a Linux desktop client VM configured with static IPv4 and IPv6 addresses.

The next test uses a Linux-based desktop client VM that initially has no assigned IP addresses, aside from the local IPv6 address, and must obtain IPv4 and IPv6 addresses dynamically through DHCP.