Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

MAC-VRF Routing Instance Type Overview

Use the MAC-VRF routing instance type to configure multiple customer-specific EVPN instances (EVIs), each of which can support a different EVPN service type. You configure a MAC-VRF instance with the mac-vrf statement at the [edit routing-instances mac-vrf-instance-name instance-type] hierarchy. With this configuration, you can create customer-specific virtual routing and forwarding (VRF) tables.

Benefits of the MAC-VRF Routing Instance Type

  • Customer-specific VRF tables
  • Consistent configuration across supported router and switch platforms within an EVPN-VXLAN network or an EVPN-MPLS network.
  • Configuration alignment with RFC 7432

MAC-VRF Instances Enable Customer-Specific VRF Tables

When you configure a MAC-VRF routing instance, you can isolate or group routing and forwarding traffic by customer. In fact, you can manage MAC-VRF instances around multiple schemes within an organization, including by department, division, or geographic location. The traffic belonging to any one MAC-VRF instance cannot interact with traffic from any other MAC-VRF instances.

MAC-VRF Instance Service Types

MAC-VRF instances follow the EVPN instance design in RFC 7432, which includes the three service types in Table 1. When you create a MAC-VRF instance, you must configure one of the supported service types using the service-type statement at the [edit routing-instances mac-vrf-instance-name] hierarchy level.

CAUTION:

When you want to change a traffic impacting option under a routing instance, use the following procedure.

  1. Deactivate the routing instance configuration.

  2. Change the traffic impacting option.

  3. Reactivate the updated routing instance configuration.

For example, follow this procedure if you need to change settings such as:

  • The service-type in a MAC-VRF routing instance-- When you change the service type of a running instance, the device might incorrectly change the VLAN ID if it is not deactivated prior to making the change.

  • The vlan-id in an EVPN routing instance-- Changing the vlan-id on the fly, without first deactivating the associated EVPN routing instance would be catastrophic.
Table 1: MAC-VRF Instance Service Type Options
Service Type Option Description

vlan-aware

You can configure the MAC-VRF EVPN instance to correspond to one or more VLANs. The MAC-VRF instance maintains one bridging table per VLAN.

Note:

By default in EVPN-VXLAN MAC-VRF instances with this service type, the device extends all VXLAN network identifiers (VNIs) in the instance. You don't need to explicitly configure the extended-vni-all statement. You can configure the extended-vni-list statement if you want to extend only a subset of the VNIs in the instance.

vlan-based

You can configure the MAC-VRF EVPN instance to correspond to a single VLAN and corresponding bridging table.

Note:

If the VLAN maps to different VLAN IDs per Ethernet segment, then you must configure each device in the EVPN fabric to perform VLAN ID translation on packets destined for the Ethernet segment.

vlan-bundle

You can configure the MAC-VRF EVPN instance to correspond to multiple VLANs that share the same bridging table. MAC addresses must be unique across all VLANs in the instance. This service type also doesn't support VLAN translation (you can configure each VLAN with one unique VLAN ID).

Note:

If all VLANs for a port are part of the same VLAN bundle service, the service is called a port-based service.

Flexible Configuration Options at Layer 2 and Layer 3

With MAC-VRF instances, you have more flexible configuration options for customers at both Layer 2 (L2) and Layer 3 (L3):

  • At L2: You can configure different service types in different MAC-VRF instances on the same device.

  • At L3: You can configure a VRF instance that corresponds to the VLAN or VLANs in a single MAC-VRF instance. You can also configure a VRF instance that spans the VLANs in multiple MAC-VRF instances.

For example, the following figure shows an edge-routed bridging (ERB) EVPN-VXLAN fabric. The leaf devices establish VXLAN tunnels that maintain L2 and L3 separation between a customer on VLAN 1 and VLAN 2, and a customer on VLAN 3. MAC-VRF 12 and MAC-VRF 3 separate the customers at L2. VRF 12 and VRF 3 separate the customers at L3. The figure also shows that you can configure multiple MAC-VRF instances on the same device with different service types.

Figure 1: EVPN-VXLAN Fabric with MAC-VRF and VRF Instances for L2 and L3 Customer SeparationEVPN-VXLAN Fabric with MAC-VRF and VRF Instances for L2 and L3 Customer Separation

MAC-VRF Instances Enable Common EVPN Configuration across Platforms

On devices that support EVPN configurations, the configuration methods vary from platform to platform. For example:

  • On MX Series routers, before MAC-VRF instance support, you could configure EVPN instances using instances of type virtual-switch with statements in the following hierarchies:

    • bridge-domains
    • routing-instances

  • On QFX Series switches, before MAC-VRF instance support, you could configure EVPN instances using the default switch instance with statements in the following hierarchies:

    • ethernet-switching
    • routing-instances

  • On ACX Series, QFX Series, and PTX series platforms running Junos OS Evolved that support EVPN, on which EVPN feature support was introduced with MAC-VRF EVPN instances, you configure EVPN features using only MAC-VRF instances.

This disparity can be confusing and lead to errors configuring EVPN across different platforms.

We introduced the mac-vrf routing instance type in Junos OS Release 20.4R1 on some Junos OS platforms. Other platforms, including Junos OS Evolved platforms, have gained MAC-VRF instance support in subsequent releases. You can use mac-vrf instances to create a common EVPN configuration on all supported platforms. This common configuration hierarchy also adheres to RFC 7432.

Note:

Platforms that support MAC-VRF instances as well as other instance types to configure EVPN instances can have different instance configurations coexist in an active network. EVPN fabrics can comprise a combination of devices that support MAC-VRF instances and devices that use other instance types for EVPN.

Some mac-vrf show commands apply only to specific platforms. For example, the MAC-VRF command show mac-vrf mac-table age (and the corresponding show bridge mac-table age command) applies only to MX Series routers. If you issue the show mac-vrf mac-table age command on a QFX Series switch, the output is blank without any error indication.

See Table 2 and Table 3 for references to the commands that provide information about EVPN instances. The common MAC-VRF forms of these commands are aliases for the platform-specific commands. Use the listed commands as follows:

  • You can use the MAC-VRF versions of these commands in the first column to display EVPN instance information on any platforms with MAC-VRF EVPN configurations.

  • Use the MAC-VRF commands in the first column on ACX Series, QFX Series, and PTX series platforms running Junos OS Evolved, which support EVPN only with MAC-VRF instance configurations.

  • Use the commands in the second column on MX Series routers and the EX9200 line of switches running Junos OS, for example, when you configure EVPN instances using instance type virtual-switch.

  • Use the commands in the third column on QFX Series and EX Series switches running Junos OS, for example, when you configure EVPN instances using the default switch instance.

Table 2: List of MAC-VRF Forwarding Commands by Platform
MAC-VRF Command MX Series Routers and the EX9200 Line of Switches QFX Series and EX Series Switches
show mac-vrf forwarding flood show bridge flood show ethernet-switching flood
show mac-vrf forwarding flood-group show l2-learning flood-group show ethernet-switching flood-group
show mac-vrf forwarding global-information show l2-learning global-information show ethernet-switching global-information
show mac-vrf forwarding global-mac-count show l2-learning global-mac-count show ethernet-switching global-mac-count
show mac-vrf forwarding global-mac-ip-count show l2-learning global-mac-ip-count show ethernet-switching global-mac-ip-count
show mac-vrf forwarding instance show l2-learning instance show ethernet-switching instance
show mac-vrf forwarding instance-mapping – –
show mac-vrf forwarding interface show l2-learning interface show ethernet-switching interface
show mac-vrf forwarding mac-ip-table show bridge mac-ip-table show ethernet-switching mac-ip-table
show mac-vrf forwarding mac-table show bridge mac-table show ethernet-switching table
show mac-vrf forwarding mgrp-policy show l2-learning mgrp-policy show ethernet-switching mgrp-policy
show mac-vrf forwarding statistics

show bridge statistics

show evpn statistics

 show ethernet-switching
show mac-vrf forwarding vlans show bridge domains show ethernet-switching vlans
show mac-vrf forwarding vxlan-tunnel-endpoint esi show l2-learning vxlan-tunnel-end-point esi show ethernet-switching vxlan-tunnel-end-point esi
show mac-vrf forwarding vxlan-tunnel-endpoint remote show l2-learning vxlan-tunnel-end-point remote show ethernet-switching vxlan-tunnel-end-point remote
show mac-vrf forwarding vxlan-tunnel-endpoint svlbnh show l2-learning vxlan-tunnel-end-point svlbnh show ethernet-switching vxlan-tunnel-end-point svlbnh
Table 3: List of MAC-VRF Routing Commands
MAC-VRF Command Equivalent show evpn Commands
show mac-vrf routing database show evpn database
show mac-vrf routing igmp-snooping database show evpn igmp-snooping database
show mac-vrf routing instance show evpn instance
show mac-vrf routing mld-snooping database show evpn mld-snooping database
show mac-vrf routing multicast-snooping status show evpn multicast-snooping status
show mac-vrf routing p2mp show evpn p2mp
Note:

We have integrated the syntax of the commands from the show mac-vrf routing hierarchy into the existing show evpn command documentation. The links in Table 3 lead to the existing show evpn commands.

MAC-VRF Conforms to RFC 7432

The common configuration hierarchy across routing and switching platforms brings our implementation of MAC-VRF into compliance with https://datatracker.ietf.org/doc/html/rfc7432. RFC compliance enables our MAC-VRF implementation to work well in data center, service provider, and public cloud environments.

Usage and Behavior Notes

Read the following notes to know more about using MAC-VRF routing instances and the observed behaviors of those MAC-VRF routing instances.

Shared VTEP Tunnels in EVPN-VXLAN Fabrics with Multiple MAC-VRF Routing Instances

Lower capacity devices might have problems with VTEP scaling when the configuration uses multiple MAC-VRF instances. To prevent this problem, some platforms, such as QFX5130 switches, QFX5700 switches, and ACX7100 routers, enable the shared VTEP tunnels feature in the default configuration for MAC-VRF instance VXLAN tunnels. With this feature enabled for VXLAN routing, the device minimizes the number of next-hop entries to reach remote VTEPs.

Switches in the QFX5000 line running Junos OS are lower capacity devices that don't enable shared tunnels by default. As a result, when you configure MAC-VRF instances on those devices, we require that you configure the shared tunnels feature. To do this, set the shared-tunnels option at the global [edit forwarding-options evpn-vxlan] hierarchy.

Note:

When you configure the shared-tunnels option, you must reboot the device for the setting to take effect.

This statement is optional on devices that can usually handle higher VTEP scaling, such as the QFX10000 line of switches. This statement is not available on other devices that don't need it in scaled EVPN-VXLAN fabrics, such as MX series routers. The shared VTEP tunnel feature operates locally on the device, so different platforms in the same network can interoperate whether they use this option or not.

MAC-VRF show commands display shared tunnel VTEP interfaces as vtep-index.shared-tunnel-unit, where:

  • index is the VTEP index associated with the MAC-VRF routing instance.

  • shared-tunnel-unit is the unit number associated with the shared tunnel remote VTEP logical interface.

For example:

VLANs, Forwarding Instances, and Overlapping VLANs with MAC-VRF Routing Instances

Each supported platform has its own support framework for VLANs and forwarding instances, and how VLANs can overlap.

  • EX4400, QFX5100, QFX5110, QFX5120, QFX5200, QFX5130-32CD, and QFX5700 switches, and PTX10001-36MR, PTX10004, PTX10008, PTX10016 routers

    These devices support only one forwarding instance (default-switch). You can't configure overlapping VLANs within a single MAC-VRF routing instance or across different MAC-VRF routing instances.

    However, on some of these platforms, you can alternatively use VLAN translation to support overlapping VLANs. See vlan-rewrite and Overlapping VLAN Support Using VLAN Translation in EVPN-VXLAN Networks.

  • ACX7100-32C and ACX7100-48L routers, and the QFX10000 line of switches

    The QFX10000 line of switches supports multiple forwarding instances using the forwarding-instance identifier option at the [edit routing-instances mac-vrf-instance-name] hierarchy. This statement maps a MAC-VRF instance to a forwarding instance corresponding to the configured identifier. Starting in Junos OS Evolved Release 22.3R1, ACX7100-32C and ACX7100-48L routers also support multiple routing instances using the forwarding-instance identifier option.

    On these platforms, you can configure overlapping VLANs across multiple MAC-VRF routing instances if you've mapped each routing instance to a unique forwarding instance. You can also configure multiple MAC-VRF routing instances to use one forwarding instance. You can't configure overlapping VLANs within a single MAC-VRF routing instance or across routing instances each of which maps to the same forwarding instance. If you don't configure the forwarding instance, the MAC-VRF routing instance uses the default forwarding instance (default-switch).

    ACX7100-32C and ACX7100-48L routers alternatively support overlapping VLANs using explicit or implicit VLAN normalization. You can also use VLAN normalization to support overlapping VLANs on these routers in releases before Junos OS Evolved Release 22.3R1. See Overlapping VLAN Support Using Multiple Forwarding Instances or VLAN Normalization.

  • MX Series routers and the EX9200 line of switches

    You can configure overlapping VLANs across multiple MAC-VRF routing instances. You cannot configure overlapping VLANs within a single MAC-VRF routing instance.

    On these platforms, each MAC-VRF routing instance that you configure automatically maps to its own forwarding instance. We don't support the forwarding-instance option.

Note:

In the default configuration, devices include a default VLAN with a VLAN ID value of 1 associated with the default forwarding instance. Because VLAN IDs must be unique in a forwarding instance, if you want to configure a VLAN with VLAN ID 1 in a MAC-VRF instance that uses the default forwarding instance, you must reassign the VLAN ID of the default VLAN to a value other than 1. For example:

Extended VNI List Behavior

You can configure extended virtual network identifier (VNI) lists within any MAC-VRF routing instance at the edit routing-instances mac-vrf routing instance name protocols evpn hierarchy level. The extended-vni-list keyword is an optional configuration element. By default, the device extends all VNI (whether in a VNI list or not) within the MAC-VRF routing instance. If you configure a specific VNI list, then you can extend only those VNIs that are in the list.

Related Documentation