Juniper QFX EVPN-VXLAN Migration to OcNOS-DC: Platforms and Cutover

A Juniper QFX EVPN-VXLAN fabric can move to OcNOS-DC on open hardware one leaf at a time, keeping the same design: BGP EVPN as the control plane, VXLAN as the data plane, and all-active multihoming for dual-attached servers. This post maps the QFX roles to OcNOS-DC platforms, translates the main Junos statements, shows a leaf configuration from an OcNOS-DC switch in the IP Infusion lab, and lists the checks to run before each leaf carries production traffic.

요약하면 다음과 같습니다: QFX5120-48Y leaves map to the Edgecore AS7326-56X or the UfiSpace S8901-54XC, and QFX5220-32CD spines map to the Edgecore AS9716-32D. The EVPN design carries over; the VNIs, route targets and Ethernet segments are written in OcNOS syntax and verified leaf by leaf.

Which OcNOS-DC Platforms Replace QFX Leaves and Spines?

The mapping is based on role, ports and capacity. The full port and capacity comparison is in the OcNOS vs Juniper platform mapping.

The OcNOS 기능 매트릭스 lists Layer 2 EVPN for VXLAN on both leaf platforms and EVPN route reflection on the AS9716-32D, which matches how the roles divide: the leaves are the VTEPs and the spines reflect EVPN routes between them.

This mapping assumes the leaves are the only VTEPs. In a centrally routed bridging (CRB) design, the QFX spines also terminate VXLAN and hold the IRB gateways that route between VNIs. If your spines do that today, plan the spine role together with the overlay routing step described after the leaf configuration.

What Should You Count Before Planning the Move?

1. Leaves and their port profile. Count the leaves and note any 100G ports broken out to 4x25G. Breakouts and uplink count decide between the AS7326-56X and the S8901-54XC.
2. Spines. Count them and note whether they run the EVPN route reflectors and whether they also terminate VXLAN with IRB gateways (centrally routed bridging).
3. VNIs and VLANs. List each VNI with its VLAN and route target. This list becomes the OcNOS MAC VRF and VNI configuration.
4. Layer 2 only, or routing in the overlay. A fabric that only bridges in VXLAN (Type-2 and Type-3 routes) has fewer moving parts than one with IRB gateways and Type-5 prefix routes. Note which you run.
5. Ethernet segments. List every ESI and the two leaves that share it. Multihomed pairs decide the order of the move.

How Do Junos EVPN-VXLAN Statements Map to OcNOS-DC?

The Junos column uses statements from Juniper's EVPN-VXLAN centrally routed bridging example and the Juniper esi statement reference. The OcNOS column uses the lines in the lab leaf configuration below.

One difference to plan for: if the Junos fabric uses vrf-target auto, Junos derives the route targets of Type 2 and Type 3 routes from the AS number and the VNI, so those values do not appear in the configuration. Other route types, such as Type 1 and Type 5, still use route targets set in the configuration (see Juniper's auto-derived route targets page). The OcNOS configuration shown here sets each route target explicitly, so record the route targets on the EVPN routes the QFX leaves advertise today and configure the same values on the OcNOS leaves.

What Does an OcNOS-DC Leaf Configuration Look Like?

The configuration below is taken from the running configuration of a UfiSpace S8901-54XC acting as a VXLAN-EVPN leaf on OcNOS-DC 7.0.1 in the IP Infusion lab. It is an excerpt for one VLAN; names, addresses and numeric values are changed.

bridge 1 protocol rstp vlan-bridge
!
vlan database
 vlan 10 bridge 1 state enable
!
nvo vxlan enable
!
evpn vxlan multihoming enable
!
mac vrf vrf_vl10
 evpn-vlan-service vlan-based
 rd 10.10.100.11:10
 route-target both 65000:10
!
nvo vxlan vtep-ip-global 10.10.100.11
!
nvo vxlan id 10010 ingress-replication bridge-vlan 10
 vxlan host-reachability-protocol evpn-bgp vrf_vl10
!
interface po10
 switchport
 bridge-group 1 spanning-tree disable
 switchport mode trunk
 switchport trunk allowed vlan add 10
 access-if-vxlan
 evpn multi-homed system-mac 0000.0000.0010
!
interface xe1
 channel-group 10 mode active
!
interface lo
 ip address 127.0.0.1/8
 ip address 10.10.100.11/32 secondary
!
router bgp 65000
 bgp router-id 10.10.100.11
 neighbor 10.10.100.1 remote-as 65000
 neighbor 10.10.100.1 update-source lo
 neighbor 10.10.100.2 remote-as 65000
 neighbor 10.10.100.2 update-source lo
 !
 address-family l2vpn evpn
  neighbor 10.10.100.1 activate
  neighbor 10.10.100.2 activate
 exit-address-family

How the pieces fit:

• The VLAN is bridged into VNI 10010 with bridge-vlan, and the MAC VRF vrf_vl10 holds the route distinguisher and route target.
• access-if-vxlan on the trunk port-channel makes it an access port of the VXLAN service.
• evpn multi-homed system-mac sets the Ethernet segment. OcNOS derives the ESI from this value, so both leaves of a multihomed pair use the same system MAC on the port-channel to the same server.
• In the lab the leaf peers directly with the other leaves. In a fabric with spines, the BGP EVPN neighbors are the spine route reflectors.

The excerpt covers Layer 2 bridging over VXLAN. If the QFX fabric routes in the overlay with IRB gateways or Type-5 prefix routes, plan those from the OcNOS-DC 7.0 documentation as a separate step of the design.

How Do You Move One Leaf at a Time?

Move the fabric leaf by leaf, and move both leaves of a multihomed pair in the same maintenance window, so the two leaves that serve an Ethernet segment always run the same operating system. EVPN-VXLAN is a standards-based design (RFC 7432 for the EVPN control plane, RFC 8365 for VXLAN). Use the first leaf to confirm that route targets, the EVPN service type (the OcNOS excerpt uses VLAN-based MAC VRFs), ESIs and replication settings line up across the two implementations, in the lab or during a maintenance window before production traffic.

On each new OcNOS-DC leaf, these commands show whether it has joined the fabric. Each command was run on the lab leaf:

1. show bgp l2vpn evpn summary: an established session to each route reflector, with route counts per type (AD, MAC-IP, multicast, ESI, prefix).
2. show nvo vxlan tunnel: one tunnel to every remote VTEP, with the status Installed.
3. show nvo vxlan: each VNI with its VLAN, access ports, ESI and designated forwarder status.
4. show nvo vxlan mac-table: local and remote MAC addresses, each against the VTEP or ESI behind it.
5. show evpn esi all: each Ethernet segment and the leaves that share it. A segment with only one leaf listed means the other leaf of the pair is not advertising the same ESI.
6. show nvo vxlan arp-cache: the ARP entries learned in each VNI.

Then send test traffic between hosts on the new leaf and hosts on the remaining QFX leaves, and compare MTU and reachability with the baseline before moving production VLANs.

Next Steps

The OcNOS vs Juniper comparison covers the full platform mapping for QFX, MX, PTX and ACX. The OcNOS 기능 매트릭스 lists EVPN-VXLAN support per platform and release, and the EVPN-VXLAN 및 EVPN 멀티호밍 pages explain the protocols. For a plan built on your own configuration, contact IP Infusion.

Juniper, Junos and QFX are trademarks of Juniper Networks, Inc. IP Infusion is not affiliated with Juniper Networks.