Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

SUMMARY VXLAN-GBP

Overview

You can achieve micro and macro segmentation, for example to secure data and assets, in a VXLAN architecture using Group Based Policy (GBP). GBP leverages underlying VXLAN technology to provide location-agnostic endpoint access control. GBP allows you to implement consistent security policies across the 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. VXLAN-GBP works by leveraging reserved fields in the VXLAN header for use as a Scalable Group Tag (SGT). You can use the SGTs as match conditions in firewall filter rules. Using an SGT is more robust than using port or MAC addresses to achieve similar results. SGTs can be assigned statically (by configuring the switch on a per port 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.

You can find more detailed information on the VXLAN-GBP standard in the IEEE RFC, I-D.draft-smith-vxlan-group-policy. For the purposes of this example, suffice to say, VXLAN-GBP leverages reserved fields in the VXLAN header as Scalable Group Tag, as shown in the illustration.

Figure 1: VXLAN Header Fields VXLAN Header Fields

Table 1 provides the details of the switches that support VXLAN-GBP based on the Junos releases from when the support is provided.

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
  • EX9204 series (with EX9200-15C)

  • EX9208 series (with EX9200-15C)

  • EX9214 series (with EX9200-15C)

Starting with Junos OS Release 22.4R1, the GBP configuration has changed as shown in Table 2.

Table 2: Differences in the GBP Implementation in the Junos OS Releases
GBP in Junos OS Release 21.1R1 and Later GBP in Junos OS Release 22.4R1 and later

GBP tagging statements:

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-des-tag tag

GBP tagging statements:

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

  • The 'gbp-tag' term replaced the 'gbp-src-tag' and ' gbp-dst-tag' terms

Supported GBP match conditions:

interface<interface_name>

source-mac-address<mac address>

Supported GBP match conditions:

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

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

  • mac-address<mac address>

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

  • vlan-id<vlan id>

  • interface<interface_name>

Policy enforcement

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

Policy enforcement

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 supported on both the ingress and the egress endpoints. By default, policy enforcement is supported on the egress node .

  • CLI statement to enable GBP:

    set chassis forwarding-options vxlan-gbp-profile
  • 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

GBP in Junos OS Release 22.4R1 and Later

Starting with Junos OS Release 22.4R1, you can perform policy enforcement at the ingress endpoint and perform GBP-tagging on additional match conditions.

Table 3 shows the supported GBP-tagging match conditions:

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

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

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

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

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.

Note:

Junos OS Release 23.4R1 and later also allows you to configure this match condition alongside the vlan-id match condition (where the vlan-id match condition is supported) in a single firewall filter term.

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.

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.

Junos OS Release 23.2R1 and later supports the vxlan-gbp-l2-profile and vxlan-gbp-l3-profile. See Table 4.

Table 4: Supported VXLAN-GBP UFT Profiles
Profiles Supported Switches
vxlan-gbp-profile
  • EX4100 series

  • EX4400 series

  • EX4650 series

  • QFX5120-32C and QFX5120-48Y switches

vxlan-gbp-l2-profile and vxlan-gbp-l3-profile
  • EX4400 series

  • EX4650 series

  • QFX5120-32C and QFX5120-48Y switches

GBP policy filters use GBP source and/or GBP destination tag as matches to either allow or discard traffic. Starting with Junos OS Release 23.2R1, the EX4100, EX4400, EX4650, QFX5120-32C, and QFX5120-48Y switches support new GBP policy filter (IPv4 and IPv6) L4 matches. These matches help you keep specific rules that help block only application traffic, see Table 5.

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

These L4 matches are not supported on the EX9204, EX9208, and EX9214 switches.

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 6: 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 5. 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 code sample, this time using a GBP source tag of 300, and with packets from IPv4 address 172.16.1.0/24. As you can see below, GBP source tag 300 is assigned and in egress direction, and 300 is also GBP destination group tag.

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 Overview on the Ingress Endpoint

Starting with Junos Release 22.4R1, you can also perform the policy enforcement on the ingress endpoint. Ingress enforcement optimizes the network bandwidth. To support policy enforcing on the ingress, we have a mechanism to propagate the MAC and IP-MAC based tags across the network using Type 2 and Type 5 routes. See EVPN Type 2 and Type 5 routes for more information. With this, the destination GBP-based policy is enforced in nodes closer to the ingress for MAC and IP-based GBP matches. Tag propagation is always in context of MAC and IP-based GBP. For VLANs, Port, and Port+VLAN matches this is not applicable.

Note:

If the host route is installed with the type 2 route that has the GBP tag, then the GBP tag is added in the type 5 route. Type 2 to Type 5 GBP tag propagation is supported but Type 5 route to Type 2 route 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.

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:

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 7: 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 8: 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.

Figure 2: VXLAN GBP on an EX4400 SwitchVXLAN GBP on an EX4400 Switch

Requirements

Enhanced GBP is supported in Junos OS 22.4R1 on the following switches: EX4100, EX4400, EX4650, QFX5120-32C, and QFX5120-48Y.

Configuration

VXLAN-GBP based segmentation:

  • 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.
    • First enable chassis forwarding-options vxlan-gbp-profile on the device.

    • 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. Starting with Junos OS Release 23.2R1, in addition to the source and destination tags, new GBP policy filter IPv4 and IPv6 L4 matches like protocol, source ports, destination ports, tcp-flags and others matches are supported. See Table 5.
    • If you want policy enforcement to take place at the ingress endpoint, you need to enable the set fowarding-options evpn gbp ingress-enforcement option.

Configuring a Stand-Alone Juniper EX4400 Switch for VXLAN-GBP

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 taken 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 using the Juniper-Switching-Filter or the Juniper-Group-Based-Policy-Id :Or
  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.

Limitations for EX switches and QFX switches:

  • EX9204, EX9208, and EX9214 switches: for transit traffic coming over EVPN-VXLAN Type 2 Tunnel, GBP tag-based policy enforcement at egress PE works correctly only if the source GBP tag stamped on ingress PE in VxLAN header is carried in the underlay network without any compromise.

  • SGTs configured through RADIUS/802.1X are not supported on the EX9204, EX9208, and EX9214 switches.

  • Tag propagation and policy enforcement on the ingress endpoint are not supported on the EX9204, EX9208, and EX9214 switches.

  • GBP UFT profiles are not supported on the EX9204, EX9208, and EX9214 switches.

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

  • The interface and VLAN GBP matches are not be 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 Port-based (interface) 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.

  • ARP packets are not subjected to GBP policies. However, subsequent packets between hosts are subjected to GBP policing.

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

  • Different match criteria of GBP filters (MAC, PORT & PORT+VLAN) are not part of same filter.

GBP Junos OS Release 21.1R1 and later

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 9: 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 10: 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.

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

Requirements

VXLAN-GBP is supported in Junos OS Release 21.1R1 on the following switches: EX4400-24P, EX4400-24T, EX4400-48F, EX4400-48P, and EX4400-48T. Let us consider an EX4400 switch in this example.

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.

Configuration

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.

Configuring a Stand-Alone Juniper EX4400 Switch for VXLAN-GBP

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.