Example: Micro and Macro Segmentation using Group Based Policy in a VXLAN

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

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

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]

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

Assigning SGTs for 802.1X GBP Tag Assignment

In this example we configure SGTs on a RADIUS server and then use 802.1X access control on the GBP-enabled access switches to receive the SGTs when a matching endpoint connects to the switch. RADIUS servers are commonly used in campus environments for access control and, for example, to govern the assignment of VLANs.

Note:

• 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 port-based.

• IP address, VLAN-ID, and VLAN-ID+interface matches are not supported with 802.1X.

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's 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 the EX4400, EX4100, 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 VSA's:

• 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.

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

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

Table 9: 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:

GBP-based filters are used as classifiers for GBP tagging. These filters classify incoming streams and assign a GBP tag.

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 and is derived from the source address (IP/MAC/port and so on) lookup, while the destination tag is derived at the egress tunnel or ingress endpoint from the destination (IP/MAC/port and so on), according to the configured tag assignment.

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

Let's say we have this configuration (shown below) on both the ingress and egress endpoints. We recommend that you have same GBP tag assignment configuration across the system. 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 port based assignments as well.

In Junos OS Release 23.2R1 and later, the EX4100, EX4400, EX4650, QFX5120-32C, and QFX5120-48Y switches support additional L4 matches for GBP policy filters for MAC and IP-based GBP filters. See Table 7. Configuring the L4 filters can reduce the supported GBP scale. These matches are supported by default, however on the EX4650 series, QFX5120-32C, and QFX5120-48Y switches, you can use the set forwarding-options evpn-vxlan gbp tag-only-policy to allow only gbp source and destination tags as matches in GBP policy.

Let's look at another example, this time using a GBP source tag of 300, and with packets from IPv4 address 172.16.1.0/24:

Starting in Junos OS Release 23.4R1, the EX4400, EX4650, and QFX5120 switches support multiple entries in VLAN, port, and port+VLAN type GBP filters of same type in a term using the list and range options while the EX4100 switches support multiple entries in port type GBP filters only.

See examples below:

In this example for packets with GBP tag 300, it matches the term t1 on VLAN ID addresses ranging from 10 to 30.

In this example, for packets with GBP tag 300, it matches on the term t1 for a list of interfaces 101 to 104, where 101 to 104 are the contiguous internal interface index allocated for respective interfaces.

Note:

The priority of GBP tagging is as follows with ip-version being the highest priority:

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

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

• mac-address<mac address>

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

• vlan-id<vlan id>

• interface<interface_name>

Note that by default policy enforcement is done on the egress endpoint. If you want to do policy enforcement on the ingress leaf, see the section below.

You can enable VXLAN-GBP by selecting one of the three profiles that best meets your network needs. Each UFT profile is configured with different maximum values for each type of address. See Understanding GBP Profiles for more information on when to use these profiles. See vxlan-gbp-profile, vxlan-gbp-l2-profile, and vxlan-gbp-l3-profile to view the scales supported by these profiles.

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 Port, among others.

For example, if you configure tag assignment based on Port, and a packet from a new host is received on that Port, then the tag assigned for that Port 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 Port, 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.

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:

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.

• This feature is only supported for the EX4400, EX4650, and QFX-5120 Series switches listed in Table 1.

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 is supported on the specific EX4100, EX4400, EX4650, and QFX5120 series switches shown in Table 1.

To enable MAC/IP inter-tagging:

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

Planning Your SGT Assignments

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. The table below can be used to further simplify the logic and clarify your rules.

Table 10: 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 11: 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

Topology

For the sake of simplicity, all the configuration in this example is done on a single Juniper EX4400 series switch running Junos OS Release 22.4.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.

• Requirements
• Configuration
• Configuring a Stand-Alone Juniper EX4400 Switch for VXLAN-GBP
• Limitations for EX switches and QFX switches:

Assigning SGTs with a RADIUS Server

In this example we configure SGTs on a RADIUS server, and then use 802.1X access control on the EX4400 to receive them. RADIUS servers are commonly used in campus environments for access control and, for example, to govern 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 port 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:

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 12: 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 13: 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

Topology

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.

• Requirements
• Configuration
• Configuring a Stand-Alone Juniper EX4400 Switch for VXLAN-GBP

Starting with Junos Release 21.4R1, VXLAN-GBP is supported on the following switches as well: QFX5120-32C, QFX5120-48T, QFX5120-48Y, QFX5120-48YM, EX4650, and EX4650-48Y-VC.