Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Micro and Macro Segmentation using Group Based Policy in a VXLAN

Learn how to use Group Based Policies to support micro and macro segmentation in your network.

Overview

You can use Group Based Policy (GBP) to achieve micro and macro segmentation to secure data and assets in both Centrally Routed Bridging (CRB) and Edge Routed Bridging (ERB) VXLAN architectures. GBP leverages underlying VXLAN technology to provide location-agnostic endpoint access control. GBP allows you to implement consistent security policies across enterprise network domains. You can simplify your network configuration by using GBP, avoiding the need to configure large numbers of firewall filters on all your switches. GBP blocks lateral threats by ensuring consistent application of security group policies throughout the network, regardless of the location of endpoints or users.

GBP uses Scalable Group Tags (SGTs) to mark traffic and to enforce policy. You create a GBP tag assignment filter to assign tags to incoming frames and you create a GBP policy enforcement filter to enforce policy on tagged frames.

VXLAN-GBP leverages reserved fields in the VXLAN header to carry the SGT assigned to the frame. This is the 16-bit Group Policy ID field in Figure 1. You can find more information on VXLAN-GBP in I-D.draft-smith-vxlan-group-policy.

Figure 1: VXLAN Header Fields VXLAN Header Fields

You can apply GBP policy at both the ingress and the egress. By default, policy enforcement is only performed at the egress because that is where both the source and destination GBP tags are known. As a configurable option, you can also enforce policy at the ingress for certain types of tagged traffic. Ingress enforcement requires tag propagation of the destination tag to the ingress enforcement point so that the ingress enforcement point becomes aware of the destination tag that would be assigned at the egress. See Policy Enforcement at the Ingress and Tag Propagation.

Using an SGT is more robust than using interfaces or MAC addresses directly. SGTs can be assigned statically (by configuring the switch on a per interface or per MAC basis), or they can be configured on the RADIUS server and pushed to the switch through 802.1X when the user is authenticated.

The segmentation enabled by VXLAN-GBP is especially useful in campus VXLAN environments because it gives you a practical way to create network access policies that are independent of the underlying network topology. It simplifies the design and implementation phases of developing network-application and endpoint-device security policies.

Table 1 shows the VXLAN-GBP support for the different switches and Junos OS releases.

Table 1: VXLAN-GBP Supported Switches
Junos Release VXLAN-GBP Supported Switches

Starting with Junos OS release 21.1R1

EX4400-24P, EX4400-24T, EX4400-48F, EX4400-48P, and EX4400-48T

Starting with Junos OS release 21.2R1

EX4400-24MP and EX4400-48MP

Starting with Junos OS release 21.4R1

  • QFX5120-32C and QFX5120-48Y

  • EX4650
Starting with Junos OS release 22.4R1

  • EX4100 Series
Starting with Junos OS release 23.2R1

  • EX4400-24X

  • EX9204/9208/9214 (with EX9200-15C)
Starting with Junos OS release 24.2R1

  • MX240/480/960 (with MPC-10E)

  • MX304

  • MX10004

  • MX10008
Starting with Junos OS release 24.4R1

  • EX4100-H Series

  • EX4400-48XP and EX4400-48MXP

  • QFX5120-48T and QFX5120-48YM

Table 2 through Table 4 summarize the VXLAN-GBP implementation differences between Junos OS releases.

Table 2: Differences Between Junos OS Releases - GBP Tagging
GBP in Junos OS Releases Prior to Junos OS Release 22.4R1 GBP in Junos OS Releases 22.4R1 and Later 
set firewall family ethernet-switching filter filter_name term term_name from match_conditions
set firewall family ethernet-switching filter filter_name term term_name then gbp-src-tag/gbp-dst-tag tag
 
set firewall family any filter filter_name micro-segmentation
set firewall family any filter filter_name term term_name from match_conditions
set firewall family any filter filter_name term term_name then gbp-tag tag
Note:

  • The family name 'any' replaced the family name ' ethernet-switching'.

  • The term 'micro-segmentation' was added to indicate a GBP tagging filter.

  • The 'gbp-tag' term replaced the 'gbp-src-tag' and ' gbp-dst-tag' terms.
Table 3: Differences Between Junos OS Releases - GBP Match Conditions
GBP in Junos OS Releases Prior to Junos OS Release 22.4R1 GBP in Junos OS Releases 22.4R1 and Later

interface <interface_name>

source-mac-address <mac_address>

  • ip-version ipv4 address <ip address> | prefix-list <prefix-list>

  • ip-version ipv6 address <ip address> | prefix-list <prefix-list>

  • mac-address <mac address>

  • vlan-id <vlan id> interface <interface_name>

  • vlan-id <vlan id>

  • interface <interface_name>
Table 4: Differences Between Junos OS Releases - Policy Enforcement and Other Actions
GBP in Junos OS Releases Prior to Junos OS Release 22.4R1 GBP in Junos OS Releases 22.4R1 and Later 
set firewall family ethernet-switching filter filter_name term term_name from gbp-dst-tag gbp_tag 


set firewall family ethernet-switching filter filter_name term term_name from gbp-src-tag gbp_tag 


set firewall family ethernet-switching filter  filter_name term term_name then discard
Note:

Policy enforcement is supported on the egress endpoint only. CLI statement to enable GBP:

set chassis forwarding-options vxlan-gbp-profile
 
set firewall family any filter filter_name term term_name from gbp-dst-tag gbp_tag 


set firewall family any filter filter_name term term_name from gbp-src-tag gbp_tag 


set firewall family any filter filter_name term term_name then discard
Note:

The family name 'any' replaced the family name 'ethernet-switching'.
Note:

Policy enforcement is always enabled at the egress if GBP is enabled, but is optional at the ingress.

  • CLI statement to enable GBP:

    set chassis forwarding-options vxlan-gbp-profile
    Note: See the available GBP profiles in GBP Profiles that you can configure to enable GBP.

  • CLI statement to perform policy enforcement on the ingress endpoint:

    set fowarding-options evpn-vxlan gbp ingress-enforcement
 

Junos OS Release 23.2R1 and later:

  • Additional IPv4 and IPv6 L4 matches are supported for policy enforcement.

  • Support for vxlan-gbp-l2-profile and vxlan-gbp-l3-profile
 

Junos OS Release 24.2R1 and later:

  • Ability to add an explicit discard action for packets that do not match any condition.

  • Ability to enforce MAC-based GBP filters on routed traffic and IP-based GBP filters on switched traffic.

  • Support for GBP tag propagation for IP prefix routes in EVPN Type 5 advertisements.
 

Junos OS Release 24.2R2-S2 and later releases:

  • Support for vxlan-gbp-mc-profile. This profile enables the device to seamlessly support GBP unicast traffic flows together with multicast flows that use enhanced optimized intersubnet multicast (OISM) across the VXLAN tunnels.

 

Junos OS Release 24.4R1 and later:

  • Support for filter-based forwarding of GBP-tagged traffic for EX4xxx Series and QFX Series switches.

  • Longest prefix match takes precedence by default over firewall term ordering for IP address terms in a GBP tagging filter.
 

Junos OS Release 25.2R1 and later:

  • Support for filter-based forwarding of GBP-tagged traffic for EX92xx Series switches and MX Series routers.

GBP in Junos OS Releases 22.4R1 and Later

Basic Match Conditions

Table 5 shows the supported GBP match conditions starting in Junos OS Release 22.4R1:

Table 5: Match Conditions (Junos OS Release 22.4R1 and Later)
Match Conditions Description

ip-version ipv4 address <ip address> | prefix-list <prefix-list>

ip-version ipv6 address <ip address> | prefix-list <prefix-list>

 Match IPv4/IPv6 source or destination addresses/prefix-lists.
Note:

Starting in Junos OS Release 24.4R1, you can specify whether you want IP address terms to be evaluated in term order or by longest prefix match. By default, IP address terms are evaluated by longest prefix match in Junos OS Release 24.4R1 and later. In releases prior to Junos OS Release 24.4R1, IP address terms are evaluated in term order only. See Example of Matching on IP Address.

mac-address <mac address>

 Match source or destination MAC address.

interface <interface_name>

 Match interface name.
Note:

Junos OS Release 23.4R1 and later supports multiple interface <interface_name> match conditions within a single firewall filter term. For example:

set firewall family any filter test term t1 from interface ge-0/0/0
set firewall family any filter test term t1 from interface ge-0/0/1
set firewall family any filter test term t1 from interface ge-0/0/2
Note:

Junos OS Release 23.4R1 and later also allows you to configure this match condition alongside the vlan-id match condition in a single firewall filter term when you use Service Provider-style configuration on supported EX4400, EX4650, and QFX5120 switches. For example:

set firewall family any filter test term t1 from interface ge-0/0/0.1
set firewall family any filter test term t1 from vlan-id 2000

where VLAN 2000 is a VLAN created using Service Provider-style configuration. This is not supported if you use Enterprise-style configuration.

For more information on Service Provider-style and Enterprise-style configuration, see Flexible Ethernet Services Encapsulation.

vlan-id <vlan id> | [<vlan_list>] | <vlan_range>

Match VLAN IDs.
Note:

Not supported on the EX4100 switches

Note:

Junos OS Release 23.4R1 and later supports the <vlan_list> and <vlan_range> options. For example:

set firewall family any filter test term t1 from vlan-id 2000-2100
set firewall family any filter test term t1 from vlan-id [3000 3010 3020]
Note:

Junos OS Release 23.4R1 and later also allows you to configure this match condition alongside the interface match condition in a single firewall filter term when you use Service Provider-style configuration on supported EX4400, EX4650, and QFX5120 switches This is not supported if you use Enterprise-style configuration.

For more information on Service Provider-style and Enterprise-style configuration, see Flexible Ethernet Services Encapsulation.

We recommend that you have the same GBP tag assignment configuration everywhere (at both the ingress and egress).

Example of Matching on MAC Address

Here's an example of GBP tag assignment using MAC addresses:

At the ingress in the above example, packets from MAC address 00:00:5E:00:53:10 are assigned tag 100, packets from MAC address 00:00:5E:00:53:20 are assigned tag 200, and packets from MAC address 00:00:5E:00:53:30 are assigned tag 300.

The same tag assignment is used to map the destination MAC address to the destination tag at the egress. At the egress in the above example, packets to MAC address 00:00:5E:00:53:10 are assigned tag 100, packets to MAC address 00:00:5E:00:53:20 are assigned tag 200, and packets to MAC address 00:00:5E:00:53:30 are assigned tag 300.

Example of Matching on IP Address

Here's an example of GBP tag assignment using IP addresses:

Here's an example of multiple IP address terms in a GBP tagging filter:

Note:

The default behavior of the above filter has changed in Junos OS Release 24.4R1. Prior to Junos OS Release 24.4R1, an incoming packet with IP address 10.0.0.231 (for example) would be assigned GBP tag 10 because the incoming packet matches the first term (t1) in the filter. Starting in Junos OS Release 24.4R1, that same incoming packet would be assigned GBP tag 20 because the second term (t2) provides a more specific match.

If you don't like this new default behavior and want to retain the legacy behavior of strictly following firewall term order, then configure the filter as follows:

Set the no-longest-prefix-match parameter when you first create the GBP tagging filter. Don't toggle this parameter on an existing GBP tagging filter.

Note that Group Based Policy classification firewall filter cannot have IPv4 and IPv6 matches together as part of the same firewall filter.

Example of Matching on VLANs and Interfaces

Here's an example of matching on a VLAN ID:

Starting in Junos OS Release 23.4R1:

  • The EX4400, EX4650, and QFX5120 switches in Table 1support:

    • VLAN lists and ranges in a GBP filter

    • multiple VLAN entries in a single term in a GBP filter

    • multiple interface entries in a single term in a GBP filter

    • an interface and VLAN combination in a single term in a GBP filter when using Service Provider-style configuration. For more information on Service Provider-style and Enterprise-style configuration, see Flexible Ethernet Services Encapsulation.

  • The EX4100 switches in Table 1 support multiple interface entries in a single term in a GBP filter.

For example:

L4 Match Conditions

Starting in Junos OS Release 23.2R1, we've extended match conditions in GBP filters to include L4 matches (Table 6. This provides you with additional granularity to control application traffic.

Table 6: Support for Additional L4 Policy Matches (Junos OS Release 23.2R1 and Later)
Policy Enforcement Matches for MAC and IP GBP-Tagged Packets Description
ip-version ipv4 destination-port dst_port

Match TCP/UDP destination port.
ip-version ipv4 source-port src_port

Match TCP/UDP source port.
ip-version ipv4 ip-protocol ip-protocol

Match IP protocol type.
ip-version ipv4 is-fragment

Match if the packet is a fragment.
ip-version ipv4 fragment-flags flags

Match the fragment flags (in symbolic or hex formats).
ip-version ipv4 ttl value

Match the MPLS/IP TTL value.
ip-version ipv4 tcp-flags flags

Match the TCP flags (in symbolic or hex formats) - (Ingress only).
ip-version ipv4 tcp-initial

Match the initial packet of a TCP connection - (Ingress only).
ip-version ipv4 tcp-established

Match the packet of an established TCP connection.
ip-version ipv6 destination-port dst_port

Match the TCP/UDP destination port.
ip-version ipv6 source-port src_port Match the TCP/UDP source port.
ip-version ipv6 next-header protocol Match the next header protocol type.
ip-version ipv6 tcp-flags flags Match the TCP flags (in symbolic or hex formats)Ingress only.
ip-version ipv6 tcp-initial Match the initial packet of a TCP connection.
ip-version ipv6 tcp-established Match the packet of an established TCP connection.
Note:

L4 filters are supported on the EX4100, EX4400, EX4650, and QFX5120 Series switches shown in Table 1. These match conditions are not supported on the EX92xx switches.
Note:

L4 filters are supported by default but can reduce the supported GBP scale. To disable L4 filters on the EX4650, QFX5120-32C, and QFX5120-48Y switches: set forwarding-options evpn-vxlan gbp tag-only-policy.

When you use this set (and corresponding delete) command, the Packet Forwarding Engine (PFE) restarts.

Duplicate Matches

Here's an example with a duplicate matching term:

In the above example, both t1 and t2 match on IP address 172.16.0.0/24, but assign different GBP tags. In this situation, only the first matching term is evaluated. The second and subsequent matching terms are ignored. This is true regardless of whether you configure the filter for longest prefix match or not. Term t1 takes effect and any matching packet will be assigned GBP tag 10.

Match Priority

When an incoming packet matches more than one condition, the match priorities shown in Table 7 take effect:

Table 7: Match Priorities
Priority Match Condition
1 (Highest)

ip-version ipv4 <ip address> | <prefix-list>
2

ip-version ipv6<ip address> | <prefix-list>
3

mac-address<mac address>
4

interface<interface_name> vlan-id <vlan id>
5

vlan-id<vlan id>
6 (Lowest)

interface<interface_name>
Note: If you enable MAC/IP inter-tagging, and an incoming packet matches on both the MAC and IP addresses, the result is indeterminate. The IP address match does not necessarily take priority over the MAC address match in that situation. See GBP MAC/IP Inter-tagging.

Policy Enforcement

Note:

By default, policy enforcement is done at the egress. If you want to enforce policy at the ingress, see Policy Enforcement at the Ingress and Tag Propagation.

Here's an example of GBP policy enforcement:

Packets with GBP source tag 100 and GBP destination tag 200 will match on term t100-200 and be accepted. Packets with GBP source tag 100 and GBP destination tag 300 will match on term t100-300 and be discarded.

Policy Enforcement at the Ingress and Tag Propagation

Starting with Junos Release 22.4R1, you can perform policy enforcement closer to the ingress. Ingress enforcement saves network bandwidth by discarding tagged packets at the ingress that would otherwise be discarded at the egress. To support policy enforcement at or closer to the ingress, we propagate the MAC and IP-MAC based tags across the network using extended BGP communities within EVPN Type 2 and Type 5 routes. See EVPN Type 2 and Type 5 routes for information on these types of routes.

EVPN route advertisement is triggered by the installation (or a change) of an EVPN route, such as through MAC-IP learning when receiving a packet from a new host. In this case, the source IP route is installed in the evpn.0 database and an EVPN Type 2 advertisement (that includes the GBP tag if assigned) is sent to all eBGP peers.

After these advertisements propagate through the network to the remote endpoints, the remote endpoints have sufficient information to make GBP firewall filter decisions on packets received at the remote ingress. When packets are received at their ingress, the remote endpoints can look up the destination route and obtain the destination GBP tag previously received through the EVPN Type 2 advertisement. Armed with the destination GBP tag, the remote endpoints can subsequently make GBP policy enforcement decisions on their ingress packets.

Since GBP tags are propagated using EVPN Type 2 route advertisements, tag propagation is necessarily performed per MAC or IP address. This has no bearing on tag assignment, however, which can continue to be any of the supported methods, such as VLAN or interface, among others.

For example, if you configure tag assignment based on interface, and a packet from a new host is received on that interface, then the tag assigned for that interface is propagated in a Type 2 route advertisement along with the source MAC and IP address of the incoming packet. If a packet from a different host is subsequently received on that same interface, then the same tag is propagated in another Type 2 route advertisement along with the source MAC and IP address of this different host.

Note:

If a border leaf switch receives an EVPN Type 2 advertisement with a GBP tag, the switch installs the Type 2 route and generates an EVPN Type 5 advertisement with that GBP tag to its eBGP peers such as to the border leaf switches in other data centers (for inter-DC traffic). This Type 5 route contains a /32 IP address and a GBP tag.

This Type 2 to Type 5 GBP tag propagation is supported but Type 5 to Type 2 GBP tag propagation is not supported.

For multihoming topologies, keep the configuration identical across multihoming members.

You must enable the following statement to perform the policy enforcement at the ingress node. When ingress enforcement is enabled or disabled, the Packet Forwarding Engine (PFE) restarts.

Tag Propagation for IP Prefix Routes Using EVPN Type 5 Advertisements

Starting in Junos OS Release 24.2R1, we support GBP tag propagation for IP prefix routes using EVPN Type 5 advertisements. Previous to this release, GBP tag propagation was only triggered by MAC-IP learning in the dataplane, which meant that tag propagation only occurred for /32 IP routes.

With support for IP prefix routes, tag propagation can now occur, for example, when you create an interface and enable the advertisement of direct EVPN routes (set routing-instances <instance> protocols evpn ip-prefix-routes advertise direct-nexthop). If you also assign a GBP tag to that IP prefix, then the subsequent EVPN Type 5 advertisement includes the GBP tag, thereby propagating the tag even before MAC-IP learning takes place.

In general, GBP tag propagation within EVPN Type 5 advertisements occurs whenever you create a GBP filter that assigns a tag to an IP prefix and that IP prefix route is installed in the evpn.0 routing database. (You can create the GBP filter before or after the route is installed.)

Even though the switch generates a Type 5 advertisement, if the switch learns of a new host (for example, through MAC-IP learning in the dataplane), the switch will generate a Type 2 advertisement as well. It may be desirable in many instances to suppress these redundant /32 advertisements to reduce EVPN traffic. To do so, create a BGP policy to reject /32 routes.

For example, the following creates a policy called T5_EXPORT with term called fm_v4_host that rejects /32 routes from IPv4 hosts:

Note:

If a switch receives an EVPN advertisement for an IP prefix route and associated GBP tag, and if you've configured a GBP filter that assigns a different tag to that same IP prefix route, the GBP tag in the locally-configured GBP filter prevails. The switch replaces the GBP tag in the received EVPN advertisement with the locally-assigned GBP tag before re-advertising the EVPN route.

IP prefix tag propagation is automatically enabled when you create a GBP filter for an IP prefix and associate the GBP filter to a routing instance. For example:

where <routing-instance> is the name of the routing instance that you want the filter to apply to.

Once an IP prefix route is associated with a GBP tag, the GBP tag is displayed in the output of the show route commands for that IP prefix route. For example:

To see the binding between a routing instance and a GBP filter, use the show evpn gbp-src-tag filter-bind routing-instance command.

To see the IP prefix route to GBP tag mapping, use the show evpn gbp-src-tag ip-prefix inet command.

Limitations of this feature include the following:

  • You can only associate a GBP filter to one routing instance. You cannot associate the same GBP filter to multiple routing instances.

  • You cannot associate two different GBP filters with the same IP prefix match condition to the same routing instance.

  • You can only associate an IP-based GBP filter to a routing instance. Associating other types of GBP filters has no effect.

GBP Profiles

GBP profiles are unified forwarding table (UFT) profiles that allow you to allocate forwarding table resources tailored to your network when you run GBP. This enables you to allocate a higher percentage of memory for one type of address over another depending on your needs. The GBP profile determines the table sizes to allocate for the various GBP filters. Set one of the available profiles at the [edit chassis forwarding-options] hierarchy level that best meets your network needs.

Table 8 shows the supported GBP profiles.

Table 8: Supported VXLAN-GBP Profiles (Junos OS Release 23.2R1 and Later)
Profiles Description Supported Devices Release Introduced
vxlan-gbp-profile Suitable for a balanced configuration that contains a mix of L2 and L3 networks.

  • EX4100

  • EX4400

  • EX4650

  • QFX5120-32C and QFX5120-48Y

 Junos OS Release 21.1R1
vxlan-gbp-l2-profile Suitable when running an edge device in a virtualized network comprised of multiple virtual servers and VMs. You can also use this profile for direct reachability if the edge device needs more space in the mac-table.

  • EX4400

  • EX4650

  • QFX5120-32C and QFX5120-48Y

 Junos OS Release 23.2R1
vxlan-gbp-l3-profile Suitable for an edge device running in an L3-intensive network where more space in the host-table is required.

  • EX4400

  • EX4650

  • QFX5120-32C and QFX5120-48Y

 Junos OS Release 23.2R1
vxlan-gbp-mc-profile

Required for the network to seamlessly support GBP unicast traffic flows together with multicast flows that use enhanced OISM across the VXLAN tunnels.

Note:

In a GBP-enabled network, we support OISM only in enhanced mode (not regular mode). Also, only unicast traffic carries GBP tags in the VXLAN headers; we don't assign GBP tags to multicast traffic.

  • EX4100

  • EX4400

  • EX4650

  • QFX5120-32C, QFX5120-48T, and QFX5120-48Y

 Junos OS Release 24.2R2-S2
Note:

If you set or delete a GBP profile, the Packet Forwarding Engine (PFE) restarts automatically.

Note:

If you set or delete a GBP profile in a virtual chassis, you must reboot all members of the virtual chassis: request system reboot all-members

Explicit Default Discard

When no conditions are matched, the default action is to accept the packet. Starting in Junos OS Release 24.2R1, you can specify an explicit default discard action for packets that don't match any conditions. See Table 9.

Table 9: Explicit Default Discard Action (Junos OS Release 24.2R1 and Later)

Explicit Default Discard

Description

 
set firewall family any filter f1 term t1 from gbp-src-tag 100
set firewall family any filter f1 term t1 from gbp-dst-tag 200
set firewall family any filter f1 term t1 then accept
set firewall family any filter f1 term t2 then discard

You can create a filter term (for example, t2) that contains a discard action but no match conditions. This is useful as a catch-all for packets that do not match any of the conditions in the earlier terms in the sequence.

This explicit default discard action does not apply to broadcast, multicast, host-originated, or unknown unicast packets. These types of traffic are always accepted.

If you don't configure the explicit discard action, then the default action is to accept the packet as is the case in previous releases.
Note:

Explicit default discard is supported on the EX4100, EX4400, EX4650, and QFX5120 Series switches shown in Table 1. Explicit default discard is not supported on the EX92xx switches.

Requirements for CRB and ERB Overlays

GBP configuration differs depending on whether you're running on a Centrally Routed and Bridging (CRB) overlay or an Edge Routed and Bridging overlay. Table 10 shows these differences.

Table 10: CRB and ERB Requirements

GBP Function

Typical Application on CRB

Typical Application on ERB

Example

Tagging

Ingress Leaf

Ingress Leaf

 
set firewall family any filter f1 micro-segmentation
set firewall family any filter f1 term t1 from ip-version ipv4 address 172.16.10.0/24
set firewall family any filter f1 term t1 then gbp-tag 10

Policy Enforcement without GBP Destination Tag

Ingress or Egress Leaf

Ingress or Egress Leaf

 
set firewall family any filter f2 term t1 from gbp-src-tag 10
set firewall family any filter f2 term t1 then discard

Policy Enforcement with GBP Destination Tag

Ingress Spine

Ingress Leaf

 
set forwarding-options evpn-vxlan gbp ingress-enforcement
set firewall family any filter f3 term t1 from gbp-src-tag 10
set firewall family any filter f3 term t1 from gbp-dst-tag 20
set firewall family any filter f3 term t1 then discard

Egress Leaf

Egress Leaf

 
set firewall family any filter f3 term t1 from gbp-src-tag 10
set firewall family any filter f3 term t1 from gbp-dst-tag 20
set firewall family any filter f3 term t1 then discard

Additionally, if you're running on a CRB overlay, then you must configure the following:

Table 11: Additional Configuration for CRB Overlay

Additional Configuration

Switch

Example

Enable crb-proxy-mac.

In a CRB overlay, leaf switches act as Layer 2 gateways. In order for these Layer 2 gateways to manage learning and aging of ARP or NDP entries and advertise EVPN Type 2 MAC-IP routes, we enable the crb-proxy-mac option with an anycast MAC address.

All Leaf Switches

 
set protocols l2-learning crb-proxy-mac family inet <proxy-MAC-address>
where <proxy-MAC-address> is the anycast MAC address that you want to use on all leaf switches. Issue the above command with the same <proxy-MAC-address> on all leaf switches.

Disable proxy-macip-advertisement.

We don't want spine switches to advertise EVPN Type 2 MAC-IP routes on behalf of leaf switches. We therefore disable this proxy-macip-advertisement option.

All IRB interfaces on Spine Switches

 If proxy-macip-advertisement is enabled on an IRB interface, disable it as follows:
delete interfaces irb unit <logical-unit-number> proxy-macip-advertisement

Host-Originated Packets

When packets egress from an integrated routing and bridging (IRB) interface over a virtual tunnel endpoint (VTEP), the kernel inserts a source GBP tag in the VXLAN header and sends the packet. The source GBP tag value is configured using the following statement:

GBP MAC/IP Inter-tagging

By default, a MAC-based GBP filter only applies to switched traffic, and an IP-based GBP filter only applies to routed traffic.

Starting in Junos OS Release 24.2R1, MAC-based GBP filters can also apply to routed traffic, and IP-based GBP filters can also apply to switched traffic. This is called MAC/IP inter-tagging and can be enabled on the specific EX4100, EX4400, EX4650, and QFX5120 series switches shown in Table 1.

When enabled, the switch automatically adds a corresponding entry as follows:

  • If you create a MAC-based GBP filter, the first packet that arrives matching that MAC address will cause the switch to automatically create a corresponding IP-based GBP assignment. This assignment will apply the same tag as the original MAC-based GBP filter but match on the source IP address instead of the MAC address.

  • If you create an IP-based GBP filter, the first packet that arrives matching that IP address will cause the switch to automatically create a corresponding MAC-based GBP assignment. This assignment will apply the same tag as the original IP-based GBP filter but match on the source MAC address instead of the IP address.

Creating a corresponding entry ensures that the desired GBP tag is assigned regardless of whether the flow is subsequently switched or routed.

Note: If you enable this feature, be careful not to create conflicting GBP tag assignments. For example, if you enable this feature and you create two filters as follows:

  • Filter 1: assign GBP tag 100 to traffic with MAC address 52:54:00:00:00:11

  • Filter 2: assign GBP tag 200 to traffic with IP address 172.16.0.11

then make sure that the switch never receives traffic with that MAC/IP combination. Tagging behavior is indeterminate if the switch receives a packet with MAC address 52:54:00:00:00:11 and IP address 172.16.0.11 when you create the above filters and enable MAC/IP inter-tagging.

To enable MAC/IP inter-tagging:

Note:

If you set or delete the mac-ip-inter-tagging option, the Packet Forwarding Engine (PFE) restarts automatically.

Note:

If you set or delete the mac-ip-inter-tagging option in a virtual chassis, you must reboot all members of the virtual chassis: request system reboot all-members

Below you can see the same GBP tag 100 appear in both the MAC and IP tables when you enable MAC/IP inter-tagging.

Filter-Based Forwarding

Filter-based forwarding refers to the ability to forward traffic to a specified next hop if the GBP tags assigned to that traffic match the GBP tags specified in the filter. Use this feature to apply different routing treatment for the specified tagged traffic versus regular traffic.

To create a forwarding filter, specify the source and destination tags that you want to match and the next hop where you want to forward the matched traffic.

The CLI statements for filter-based forwarding are different for different products:

  • Filter-based forwarding of GBP-tagged traffic on the EX4xxx Series and QFX Series Switches in Table 1 is supported starting in Junos OS release 24.4R1. See Table 12 for CLI configuration examples.

  • Filter-based forwarding of GBP-tagged traffic on the EX92xx Series Switches and the MX Series Routers in Table 1 is supported starting in Junos OS release 25.2R1. See Table 13 CLI configuration examples.

Table 12: Filter-Based Forwarding Examples of GBP-Tagged Traffic (EX4xxx Series and QFX Series Switches)

Filter-Based Forwarding Configuration Examples (EX4xxx Series and QFX Series Switches)

Description

 
set firewall family any filter f1 term t1 from gbp-src-tag 100
set firewall family any filter f1 term t1 from gbp-dst-tag 200
set firewall family any filter f1 term t1 then next-ip 10.10.1.1

Use the default routing instance to forward traffic with GBP source tag 100 and destination tag 200 to the next hop for the 10.10.1.1 route.

 
set firewall family any filter f1 term t1 from gbp-src-tag 100
set firewall family any filter f1 term t1 from gbp-dst-tag 200
set firewall family any filter f1 term t1 then next-ip 10.10.1.0/24

Use the default routing instance to forward traffic with GBP source tag 100 and destination tag 200 to the next hop for the 10.10.1.0/24 route.

 
set firewall family any filter f1 term t1 from gbp-src-tag 100
set firewall family any filter f1 term t1 from gbp-dst-tag 200
set firewall family any filter f1 term t1 then next-ip 10.10.1.1 routing-instance VRF-100

Use the VRF-100 routing instance to forward traffic with GBP source tag 100 and destination tag 200 to the next hop for the 10.10.1.1 route.

 
set firewall family any filter f1 term t1 from gbp-src-tag 100
set firewall family any filter f1 term t1 from gbp-dst-tag 200
set firewall family any filter f1 term t1 then next-ip6 2001:db8:4136:e378:8000:63bf:3fff:fdd2

Use the default routing instance to forward traffic with GBP source tag 100 and destination tag 200 to the next hop for the 2001:db8:4136:e378:8000:63bf:3fff:fdd2 route.

 
set firewall family any filter f1 term t1 from gbp-src-tag 100
set firewall family any filter f1 term t1 from gbp-dst-tag 200
set firewall family any filter f1 term t1 then next-ip6 2001:db8:4136::/48

Use the default routing instance to forward traffic with GBP source tag 100 and destination tag 200 to the next hop for the 2001:db8:4136::/48 route.

 
set firewall family any filter f1 term t1 from gbp-src-tag 100
set firewall family any filter f1 term t1 from gbp-dst-tag 200
set firewall family any filter f1 term t1 then next-ip6 2001:db8:4136:e378:8000:63bf:3fff:fdd2 routing-instance VRF-100

Use the VRF-100 routing instance to forward traffic with GBP source tag 100 and destination tag 200 to the next hop for the 2001:db8:4136:e378:8000:63bf:3fff:fdd2 route.

Limitations:

  • Filter-based forwarding is only supported for tags assigned using IPv4/IPv6 address match conditions. It is not supported for tags assigned using other match conditions such as MAC address, interface, VLAN, and interface+VLAN.

  • No checks are made regarding the validity or presence of the next hop. If the next hop is not in the routing table or otherwise not resolved or if the outbound interface is down, filter-based forwarding will not take place and the packet will get dropped.

  • The only action that can coexist with next-ip and next-ip6 is count. For example: 

    set firewall family any filter f1 term t1 from gbp-src-tag 100
set firewall family any filter f1 term t1 from gbp-dst-tag 200
set firewall family any filter f1 term t1 then count num_100_200_packets
set firewall family any filter f1 term t1 then next-ip 10.10.1.1
Table 13: Filter-Based Forwarding Examples of GBP-Tagged Traffic (EX92xx Series Switches and MX Series Routers)

Filter-Based Forwarding Configuration Examples (EX92xx Series Switches and MX Series Routers)

Description

 
set firewall family any filter f1 term t1 from ip-version ipv4
set firewall family any filter f1 term t1 from gbp-src-tag 100
set firewall family any filter f1 term t1 from gbp-dst-tag 200
set firewall family any filter f1 term t1 then next-ip 10.10.1.1/32

Forward traffic with GBP source tag 100 and destination tag 200 to the next hop for the 10.10.1.1/32 route.

 
set firewall family any filter f1 term t1 from ip-version ipv6
set firewall family any filter f1 term t1 from gbp-src-tag 100
set firewall family any filter f1 term t1 from gbp-dst-tag 200
set firewall family any filter f1 term t1 then next-ip6 2001:db8:4136:e378:8000:63bf:3fff:fdd2/128

Forward traffic with GBP source tag 100 and destination tag 200 to the next hop for the 2001:db8:4136:e378:8000:63bf:3fff:fdd2/128 route.

Limitations:

  • Only /32 IPv4 and /128 IPv6 addresses are supported as next hops.

  • No checks are made regarding the validity or presence of the next hop. If the next hop is not in the routing table or otherwise not resolved or if the outbound interface is down, filter-based forwarding will not take place and the packet will get dropped.

  • The actions that can coexist with next-ip and next-ip6 are count, policer, and accept. For example: 

    set firewall family any filter f1 term t1 from ip-version ipv4
set firewall family any filter f1 term t1 from gbp-src-tag 100
set firewall family any filter f1 term t1 from gbp-dst-tag 200
set firewall family any filter f1 term t1 then count num_100_200_packets
set firewall family any filter f1 term t1 then policer CIR-100
set firewall family any filter f1 term t1 then next-ip 10.10.1.1/32

For EX92xx Series Switches and MX Series Routers, since you don't specify the routing table directly in the filter, you need to explicitly attach the forwarding filter to a routing table. See Table 14 for CLI configuration examples.

Table 14: Attaching a Forwarding Filter Examples (EX92xx Series Switches and MX Series Routers)
Attaching the Forwarding Filter Configuration Examples (EX92xx Series Switches and MX Series Routers) Description 
set routing-instances VRF-100 forwarding-options family inet filter output f1
 Apply the f1 forwarding filter after the route lookup in the VRF-100 IPv4 routing table. 
set routing-instances VRF-100 forwarding-options family inet6 filter output f1
 Apply the f1 forwarding filter after the route lookup in the VRF-100 IPv6 routing table.
Note: You can only attach the forwarding filter to a routing instance of type vrf or virtual-router. You cannot attach the forwarding filter to other routing instances or to other attachment points.

Table 15 summarizes the filter-based forwarding platform-specific behaviors for your platforms.

Table 15: Platform-Specific Behavior

Platform

Difference

EX4xxx Series

  • The next hop in the filter can be a prefix route.

  • Specify the applicable routing instance directly in the filter.

EX92xx Series

  • The next hop in the filter must be a /32 IPv4 or /128 IPv6 route.

  • Specify the applicable routing instance by explicitly attaching the filter to the applicable routing instance.

MX Series

  • The next hop in the filter must be a /32 IPv4 or /128 IPv6 route.

  • Specify the applicable routing instance by explicitly attaching the filter to the applicable routing instance.

QFX Series

  • The next hop in the filter can be a prefix route.

  • Specify the applicable routing instance directly in the filter.

Assigning SGTs Using 802.1X

You can configure your RADIUS server to assign SGTs to users during 802.1X authentication. RADIUS servers are commonly used in campus environments for access control and other functions such as the assignment of VLANs.

Note:

  • Only MAC and interface-based SGT assignments are supported with 802.1X.

  • If you configure 802.1X authentication with single-secure or multiple supplicant mode, then GBP tagging is MAC-based. If you configure 802.1X authentication with single supplicant mode, then GBP tagging is interface-based.

To accommodate the use of SGTs on the RADIUS server, we leverage the use of vendor specific attributes (VSAs), as supported by the AAA service framework. These VSAs are carried as part of the standard RADIUS request reply message, and provide a built-in extension to handle implementation-specific information such as our SGTs. The exact syntax on the RADIUS server varies according to whether the authentication scheme is MAC or EAP based.

For MAC based clients, the configuration looks like this:

For EAP based clients, the SGT is pushed from RADIUS server at the time of authentication. The configuration looks like this:

Starting with Junos OS Release 23.4R1, in addition to the existing Juniper-Switching-Filter, a new VSA called Juniper-Group-Based-Policy-Id is supported on the EX4100, EX4400, EX4650, and QFX5120 switches.

Note:

You should not use both the Juniper-Group-Based-Policy-Id VSA and the Juniper-Switching-Filter VSA together for the same client.

The client will not be authenticated if both VSAs exist and contain different GBP tag values.

You can assign GBP tags dynamically from RADIUS through either one of these VSAs:

  • Juniper-Switching-Filter carries the GBP filter and other filter match and action conditions.

  • The Juniper-Group-Based-Policy-Id carries only the GBP tag (available on EX4100, EX4400, EX4650, and QFX5120 switches only).

The Juniper-Group-Based-Policy-Id VSA for MAC and interface-based GBP tag filter looks like this:

The configured GBP tag is a non-zero positive value in the range (1-65535) for GBP tags specified in a VSA (vendor specific attribute) from a RADIUS server.

Starting with Junos OS Release 23.4R1 and later, GBP feature support is also added to the following dot1x configuration statements on the EX4100, EX4400, EX4650, and QFX5120 switches:

Table 16: Configuration Statements with GBP Tag

CLI

Description
set protocols dot1x authenticator interface [interface-names] server-fail gbp-tag gbp-tag

Specify the GBP tag to apply on the interface when the server is inaccessible. If you configure the gbp-tag gbp-tag and the client authenticates in server-fail vlan-name or server-fail permit, then the configured gbp-tag gbp-tag filter is also installed for the client.

You can only configure this option when the server-fail vlan-name or server-fail permit option is configured.
set protocols dot1x authenticator interface [interface-names] server-reject-vlan gbp-tag gbp-tag

Specify the GBP tag to apply when RADIUS rejects the client authentication. If you configure the gbp-tag gbp-tag and the client authenticates in server-reject vlan, then the configured gbp-tag filter is also installed for the client.

You can only configure the server-reject gbp-tag gbp-tag when the server-reject-vlan vlan-id option is configured.

set protocols dot1x authenticator interface [interface-names] guest-gbp-tag gbp-tag

Specify the GBP tag to apply when an interface is moved to a guest VLAN. If the guest-gbp-tag is configured and the client authenticates in guest VLAN, then the configured guest-gbp-tag filter is also installed for the client.

You can only configure the guest-gbp-tag when the guest-vlan vlan-id option is configured.

For more information on guest VLANs, see 802.1X Authentication.

You can use the show dot1x interface detail or the show ethernet-switching table command to verify which GBP tag is received from RADIUS.

Here is example output from the show ethernet-switching table command:

Example: Using GBP to Segment Traffic

This example shows how to configure a pair of switches for GBP-based microsegmentation. The switches (Leaf 1 and Leaf 2) control access for the following users and equipment, as shown in Figure 2:

  • 2 Engineering Staff (ENG)

  • 1 Contractor (CON)

  • 2 Security Staff (SS)

  • 1 Engineering Server (ES)

  • 1 Security Camera (CAM)

Figure 2: GBP Example GBP Example

Table 17 shows the GBP tag values that we'll assign. We'll show how to assign these tags using both the CLI and RADIUS.

Table 17: GBP Tag Assignments

Endpoint

GBP Tag

Engineering Staff (ENG)

10

Contractor (CON)

20

Security Staff (SS)

30

Engineering Server (ES)

40

Security Cam (CAM)

50

Table 18 shows the microsegmentation policies that we'll apply. We use Y to indicate where access is permitted, N to indicate where access is blocked, and - to indicate not applicable (since there is only one contractor, one engineering server, and one security camera).

Table 18: Microsegmentation Policy
  ENG (Tag 10) CON (Tag 20) SS (Tag 30) ES (Tag 40) CAM (Tag 50)
ENG (Tag 10) Y Y N Y N
CON (Tag 20) Y - N N N
SS (Tag 30) N N Y N Y
ES (Tag 40) Y N N - N
CAM (Tag 50) N N Y N -
  1. Follow this step if you're assigning GBP tags using the CLI.
    Add the following assignments to both Leaf 1 and Leaf 2. Instead of tailoring the assignments to each switch individually, we'll use the same assignments on both switches for convenience and consistency.
  2. Follow this step if you're assigning GBP tags using a RADIUS server.
    1. Configure both Leaf 1 and Leaf 2 to use the RADIUS server:
      where 10.0.0.100 is the IP address of the RADIUS server.
    2. Configure the relevant interfaces on both Leaf 1 and Leaf 2 for RADIUS authentication:
      where xe-0/0/46.0 is the interface connecting to the endpoint users and devices on both switches.
    3. Configure the GBP tag assignments on the RADIUS server using the Juniper-Switching-Filter VSA or the Juniper-Group-Based-Policy-Id VSA.
      Juniper-Switching-Filter VSA:Juniper-Group-Based-Policy-Id VSA:
  3. Set the desired GBP profile on both Leaf 1 and Leaf 2.
  4. Enable ingress policy enforcement on both Leaf 1 and Leaf 2.

    Set ingress enforcement on Leaf 1 to allow Leaf 1 to enforce policy for traffic in the Leaf 1 to Leaf 2 direction.

    Set ingress enforcement on Leaf 2 to allow Leaf 2 to enforce policy for traffic in the Leaf 2 to Leaf 1 direction.

    In our example, we're setting ingress enforcement on both switches.

  5. Create firewall filter rules to enforce the microsegmentation policies shown in Table 18.

    Set the following rules on both Leaf 1 and Leaf 2.

    We'll add a default discard rule at the end so that we don't have to configure any of the discard relationships explicitly. The default discard capability was introduced in Junos OS Release 24.2R1. See Explicit Default Discard.

    If you're running a release earlier than Junos OS Release 24.2R1, then you must configure each discard rule explicitly.

    You've now configured the GBP tag assignments and the GBP policies to microsegment traffic in our example.

Limitations for EX switches and QFX switches

  • EX9204, EX9208, and EX9214 switches:

    • SGTs configured through RADIUS/802.1X are not supported.

    • Support for tag propagation of /32 routes and policy enforcement on the ingress endpoint starts in Junos OS release 24.2R1.

    • Support for tag propagation of IP prefix routes using EVPN Type 5 advertisements starts in Junos OS release 24.2R1.

    • GBP UFT profiles are not supported.

  • The number of unique tags for the EX4400 and QFX5120 platforms is restricted to 1K.

  • The interface and VLAN GBP matches are not supported on the EX4100 switches.

  • Multicast IP-based GBP tagging is not supported.

  • IP-based GBP is not applied for Layer 2 switching flows and MAC-based GBP is not applied for access-to-access Layer 3 routing flows.

  • IPACL is not supported when interface-based GBP is configured.

  • Policer and count action is supported only for MAC-based and IP-based GBP policy entries.

  • VLAN-based GBP is not supported for service provider style logical interfaces.

  • GBP tag assignment filters do not support the counter option.

  • Different match criteria of GBP filters (MAC, interface, and interface+VLAN) cannot be part of the same filter.

GBP in Junos OS Releases Prior to Junos OS Release 22.4R1

Assigning SGTs Using 802.1X

You can configure your RADIUS server to assign SGTs to users during 802.1X authentication. RADIUS servers are commonly used in campus environments for access control and other functions such as the assignment of VLANs.

To accommodate the use of SGTs on the RADIUS server, we need to leverage vendor specific attribute (VSA), as supported by the AAA service framework (these VSA are carried as part of the standard RADIUS request reply message, and provide a built-in extension to handle implementation-specific information such as our SGTs). The exact syntax on the RADIUS server varies according to whether the authentication scheme is MAC or EAP based. For MAC based clients, the configuration looks like this:

For EAP based clients, the SGT is pushed from RADIUS server at the time of authentication. The configuration looks like this:

Starting with Junos Release 21.1R1, EX4400 switches introduce a new match condition for use with VXLAN-GBP that allows the firewall to recognize the SGT tags that get passed by the RADIUS server and inserted into the VXLAN header.

You can see how this works in the following code samples. GBP firewall policies are framed on the basis of source and destination GBP tags. A source tag is the 16-bit field in the VXLAN header in the incoming packet, while the destination tag is derived at the egress tunnel endpoint, according to the configured tag assignment.

Let's say we have an egress end point with the configuration shown below. Packets from source MAC address 00:01:02:03:04:10:10 are assigned the tag 100, and packets from source MAC address 00:01:02:03:04:20:20 are assigned 200.

For packets with GBP tag 100 and a destination MAC address of 00:01:02:03:04:10:10, the destination group tag (gbp-dst-tag) will be 100, and it will match on term t10-100. Likewise, for packets with GBP tag 100 and a destination MAC address of 00:01:02:03:04:20:20, the destination group tag will be 200, and it will match term t10-200.

The same tag assignment used to map the source MAC address to the source tag is also used to map the destination MAC address to the destination tag. This is true for interface-based assignments as well.

Let's look at another code sample, this time using a GBP source tag of 300, and with packets ingressing interface ge-0/0/30.0. As you can see below, GBP source tag 300 is assigned and in egress direction, and 300 is also GBP destination group tag.

Note that you need to configure the GBP firewall filter on the egress switch, because there is no way for the ingress switch to know what group tags are used at the egress switch. In addition, you must enable VXLAN-GBP globally on the ingress node, so it can perform the look-up on the matches and add SGT in the VXLAN header, and also on the egress node. Do this with the configuration command shown here:

Example: Using GBP to Segment Traffic

This example shows how to configure a switch for GBP-based microsegmentation.

Before creating any rules, it can be helpful to organize your scheme by creating a table for all your endpoints (users and devices) and the assigned SGT value. Here, we show one such table, the values of which will later be applied in a matrix, that can be used to further simplify the logic and clarify your rules.

Table 19: Endpoints and Their SGT Values

Endpoint

Assigned SGT Value

Permanent Employee (PE)

100

Contractor (CON)

200

Security Staff (SS)

300

Security Cam (CAM)

400

Engineering Server (ES)

500

The relationship between the RADIUS server and SGTs, the EX4400 and VXLAN packet headers, and a central firewall filter to manage the access policy, is such that a matrix becomes a handy way to organize the values. In the following table, we list user roles down the first column and device types across the first row to create an access matrix. Each user role and device type is assigned an SGT and the RADIUS configuration has been updated with the information.

This example uses three types of employees, Permanent Employee (PE), Contractor (CON), and Security Staff (SS). It also uses two types of resources, Eng Server (ES) and security camera (CAM). We use Y to indicate access is permitted, and N to shown when access is blocked. The table serves as a useful resource when creating the various firewall rules in the policy and makes access mapping simple and clear.

Table 20: Access Matrix
  ES (SGT 500) CAM (SGT 400) PE (SGT 100) CON (SGT 200) SS (SGT 300)
PE (SGT 100) Y N Y Y N
CON (SGT 200) N N Y N N
SS (SGT 300) N Y N N Y

For the sake of simplicity, all the configuration in this example is done on a single Juniper EX4400 series switch running Junos OS Release 21.1R1. The switch is connected to a RADIUS server for AAA. This switch functions as egress in this example. Recall that for SGTs you must define the firewall on the egress switch, whereas you would typically do it on the ingress VXLAN gateway for the access layer.

Figure 3: VXLAN GBP on an EX4400 Switch VXLAN GBP on an EX4400 Switch

We can summarize the sequence of events underlying VXLAN-GBP based segmentation, laid out in the paragraphs above, as follows:

  • Users log on to the network and are authenticated by the RADIUS server (on which SGTs are configured for all the endpoints).
  • Using firewall filters, the EX4400 selects traffic on the basis of the 802.1X authentication or MAC address, and then assigns a group tag to matching frames. (for dot1x authenticated clients, the static firewall configuration is not needed). The mechanics of this are performed using firewall, as shown here: and
  • Tagged traffic passing through the EX4400 is evaluated on the basis SGT values, again, using the mechanics of the firewall filter. For this to happen, you first need to enable chassis forwarding-options vxlan-gbp-profile on the switch, then you use the gbp-dst-tag and/or gbp-src-tag match conditions to write your firewall rules, and include them in the routing policy on the egress switch you use for GBP micro segmentation.

Use the following commands to configure VXLAN-GBP segmentation in a sandbox environment. Typically, you would create the firewall filter rules on the switch that serves as the (egress) VXLAN gateway for the access layer, but for the sake of simplicity, we’re using the same stand-alone EX4400 for both the firewall filter rules and the RADIUS server (EAP, here). The values we use in this example are from the previous tables.

The commands below include variables such as profile names and IP addresses, which must be adapted to make sense for your test environment.

  1. Configure the RADIUS server:
  2. Configure the physical ports to support RADIUS authentication:
  3. Set up the SGT tags on the RADIUS server:
  4. Enable VXLAN-GBP on the switch:
  5. Create Firewall filter rules that leverage the SGTs (using values organized in the matrix):
  6. Run a commit check in Junos to verify that the commands and the variables you used are valid.
    When satisfied with your configuration commit the candidate configuration to make it active on the device. These commands are shown below. You can also review your configuration by typing run show configuration.

Related Documentation