Example: Micro and Macro Segmentation using Group Based Policy in a VXLAN
VXLAN-GBP
Overview
You can use Group Based Policy (GBP), for example, 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.
VXLAN-GBP leverages reserved fields in the VXLAN header to use as a Scalable Group Tag (SGT). This 16-bit SGT field carries the (source) GBP tag assigned to the VXLAN frame using GBP firewall filter rules at the ingress.
At the egress, GBP firewall filter rules assign the destination GBP tag and a separate GBP firewall filter uses these tags as match conditions to enforce a policy.
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.
You can find more detailed information on the VXLAN-GBP standard in the IEEE RFC, I-D.draft-smith-vxlan-group-policy.
Figure 1 shows the Scalable Group Tag (Group Policy ID) in the VXLAN header.
Table 1 shows the VXLAN-GBP support for the different switches and Junos OS releases.
| 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 |
|
| Starting with Junos OS release 22.4R1 |
|
| Starting with Junos OS release 23.2R1 |
|
| Starting with Junos OS release 24.2R1 |
|
| Starting with Junos OS release 24.4R1 |
|
Table 2 through Table 4 summarize the VXLAN-GBP implementation differences between Junos OS releases.
| GBP in Junos OS Release 21.1R1 through 22.3Rn | GBP in Junos OS Release 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:
|
| GBP in Junos OS Release 21.1R1 through 22.3Rn | GBP in Junos OS Release 22.4R1 and later |
|---|---|
|
|
|
| GBP in Junos OS Release 21.1R1 through 22.3Rn | GBP in Junos OS Release 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.
|
|
Junos OS Release 23.2R1 and later:
|
|
|
Junos OS Release 24.2R1 and later:
|
|
|
Junos OS Release 24.4R1 and later:
|
GBP in Junos OS Release 22.4R1 and Later
- Match Conditions
- L4 Match Conditions
- GBP Profiles
- Explicit Default Discard
- Policy Enforcement at the Ingress and Tag Propagation
- Requirements for CRB and ERB Overlays
- Host-Originated Packets
- GBP MAC/IP Inter-tagging
- Filter-Based Forwarding
- Assigning SGTs for 802.1X GBP Tag Assignment
- Planning Your SGT Assignments
- Topology
Match Conditions
Table 5 shows the supported GBP match conditions starting in Junos OS Release 22.4R1:
| Match Conditions | Description |
|---|---|
|
|
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. |
|
|
Match source or destination MAC address. |
|
|
Match interface name. Note:
Junos OS Release 23.4R1 and later supports multiple
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 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 |
|
|
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 |
Here's an example of GBP tag assignment using MAC addresses:
set firewall family any filter f1 micro-segmentation set firewall family any filter f1 term tag100 from mac-address 00:00:5E:00:53:10 set firewall family any filter f1 term tag100 then gbp-tag 100 set firewall family any filter f1 term tag200 from mac-address 00:00:5E:00:53:20 set firewall family any filter f1 term tag200 then gbp-tag 200 set firewall family any filter f1 term tag300 from mac-address 00:00:5E:00:53:30 set firewall family any filter f1 term tag300 then gbp-tag 300
We recommend that you have the same GBP tag assignment configuration everywhere (at both the ingress and egress).
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.
Here's an example of GBP tag assignment using IP addresses:
set firewall family any filter f2 micro-segmentation set firewall family any filter f2 term t1 from ip-version ipv4 172.16.1.0/24 set firewall family any filter f2 term t1 then gbp-tag 400
Here's an example of multiple IP address terms in a GBP tagging filter:
set firewall family any filter f3 micro-segmentation set firewall family any filter f3 term t1 from ip-version ipv4 address 10.0.0.0/22 set firewall family any filter f3 term t1 then gbp-tag 10 set firewall family any filter f3 term t2 from ip-version ipv4 address 10.0.0.0/24 set firewall family any filter f3 term t2 then gbp-tag 20
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 firewall family any filter f3 no-longest-prefix-match
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.
Here's an example with a duplicate matching term:
set firewall family any filter f4 micro-segmentation set firewall family any filter f4 term t1 from ip-version ipv4 address 172.16.0.0/24 set firewall family any filter f4 term t1 then gbp-tag 10 set firewall family any filter f4 term t2 from ip-version ipv4 address 172.16.0.0/24 set firewall family any filter f4 term t2 then gbp-tag 20
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.
Here's an example of GBP policy enforcement:
set firewall family any filter gbp-policy term t100-200 from gbp-src-tag 100 set firewall family any filter gbp-policy term t100-200 from gbp-dst-tag 200 set firewall family any filter gbp-policy term t100-200 then accept set firewall family any filter gbp-policy term t100-300 from gbp-src-tag 100 set firewall family any filter gbp-policy term t100-300 from gbp-dst-tag 300 set firewall family any filter gbp-policy term t100-300 then discard
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.
Starting in Junos OS Release 23.4R1:
-
The EX4400, EX4650, and QFX5120 switches support VLAN lists and ranges in a GBP filter.
-
The EX4400, EX4650, and QFX5120 switches support multiple VLAN entries in a single term in a GBP filter.
-
The EX4400, EX4650, and QFX5120 switches support multiple interface entries in a single term in a GBP filter.
-
The EX4400, EX4650, and QFX5120 switches support an interface and VLAN combination in a single term in a GBP filter.
-
The EX4100 switches support multiple interface entries in a single term in a GBP filter.
For example:
set firewall family any filter f1 micro-segmentation set firewall family any filter f1 term t1 from vlan-id [10-30] set firewall family any filter f1 term t1 then gbp-tag 100
set firewall family any filter f2 micro-segmentation set firewall family any filter f2 term t1 from interface xe-0/0/1 set firewall family any filter f2 term t1 from interface xe-0/0/2 set firewall family any filter f2 term t1 from interface xe-0/0/3 set firewall family any filter f2 term t1 from interface xe-0/0/4 set firewall family any filter f2 term t1 then gbp-tag 200
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>
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.
L4 Match Conditions
Starting in Junos OS Release 23.2R1, we've extended match conditions in GBP filters to include L4 matches. This provides you with additional granularity to control application traffic. See Table 6.
| 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:
When you use this set (and corresponding delete) command, the Packet Forwarding Engine (PFE) restarts. |
|
GBP Profiles
Junos OS Release 23.2R1 and later supports vxlan-gbp-l2-profile and vxlan-gbp-l3-profile as shown in Table 7.
| Profiles | Supported Switches |
|---|---|
vxlan-gbp-profile |
|
vxlan-gbp-l2-profile and
vxlan-gbp-l3-profile |
|
The UFT profile determines the table sizes to allocate for the various GBP filters. Select the profile that best meets your network needs.
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 for the table size settings.
set chassis forwarding-options vxlan-gbp-profile
set chassis forwarding-options vxlan-gbp-l2-profile
set chassis forwarding-options vxlan-gbp-l3-profile
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 8.
|
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. |
|
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.
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.
set forwarding-options evpn-vxlan gbp ingress-enforcement
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:
set policy-options policy-statement T5_EXPORT term fm_v4_host from route-filter 0.0.0.0/0 prefix-length-range /32-/32 set policy-options policy-statement T5_EXPORT term fm_v4_host then reject
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:
set firewall family any filter f1 micro-segmentation set firewall family any filter f1 term tag300 from ip-version ipv4 172.16.1.0/24 set firewall family any filter f1 term tag300 then gbp-tag 300 set routing-instances <routing-instance> forwarding-options evpn-vxlan gbp ingress-src-tag filter f1
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:
show route match-prefix 5:* extensive
bgp.evpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
Restart Complete
5:10.255.1.1 (1 entry, 1 announced)
<trimmed>
gbp-tag:0L:53 router-mac:52:54:00:00:92:f0
Import Accepted
Route Label: 9100
Overlay gateway address: 0.0.0.0
ESI 00:00:00:00:00:00:00:00:00:00
Localpref: 100
Router ID: 10.255.1.1
Secondary Tables: VRF-100.evpn.0
Thread: junos-main
Indirect next hops: 1
<trimmed>
show route table VRF-100.inet.0 match-prefix 10.1.1* extensive
VRF-100.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
Restart Complete
10.1.1.3/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.1.1.3/32 -> {indirect(1048574)}
Opaque data client: EVPN-Type5
Opaque data: tlv_type :32820
Type5 gbp_tag 53.
Address: 0xa15f928
Opaque-data reference count: 2
Page 0 idx 0, (group DC2_TORS type External) Type 1 val 0xa32fd40 (adv_entry)
Advertised metrics:
Nexthop: Self
AS path: [65201] 65200 I
Communities: gbp-tag:0L:53
Advertise: 00000001
Path 10.1.1.3
<trimmed>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.
-
This feature is only supported for the EX4400, EX4650, and QFX-5120 Series switches listed in Table 1.
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 9 shows these differences.
|
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:
|
Additional Configuration |
Switch |
Example |
|---|---|---|
|
Enable 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
|
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 We don't want spine switches to advertise EVPN Type 2 MAC-IP routes on behalf
of leaf switches. We therefore disable this
|
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:
set forwarding-options evpn-vxlan host-originated-packets gbp-src-tag gbp-src-tag
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:
set forwarding-options evpn-vxlan gbp 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.
show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC,
B - Blocked MAC)
Ethernet switching table : 2 entries, 2 learned
Routing instance : default-switch
Vlan MAC MAC GBP Logical SVLBNH/ Active
name address flags tag interface VENH Index source
vlan100 52:54:00:22:22:22 D 100 xe-0/0/8.0
vlan200 52:54:00:44:44:44 D xe-0/0/9.0 show ethernet-switching mac-ip-table
MAC IP flags (S - Static, D - Dynamic, L - Local , R - Remote, Lp - Local Proxy,
Rp - Remote Proxy, K - Kernel, RT - Dest Route, (N)AD - (Not) Advt to remote,
RE - Re-ARP/ND, RO - Router, OV - Override, Ur - Unresolved, B - Blocked,
RTS - Dest Route Skipped, RGw - Remote Gateway, GBP - Group Based Policy,
RTF - Dest Route Forced, SC - Static Config, P - Probe, NLC - No Local Config,
LD - Local Down)
Routing instance : default-switch
Bridging domain : vlan100
IP MAC Flags GBP Logical Active
address address Tag Interface source
10.100.100.100 52:54:00:22:22:22 DL,K,RT,AD 100 xe-0/0/8.0
10.100.100.101 52:54:00:63:0e:40 S,K irb.100
2001:db8::9300:6463:e40 52:54:00:63:0e:40 S,K irb.100
Filter-Based Forwarding
Starting in Junos OS release 24.3R1, we support filter-based forwarding for GBP-tagged traffic. This is 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. See Table 11.
|
Filter-Based Forwarding Example |
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:
|
|
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.
-
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.
-
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:
001094001199 Cleartext-Password := "001094001199" Juniper-Switching-Filter = "apply action gbp-tag 100
For EAP based clients, the SGT is pushed from RADIUS server at the time of authentication. The configuration looks like this:
PermEmp01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Switching-Filter = "apply action gbp-tag 100"
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.
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-Filtercarries the GBP filter and other filter match and action conditions. -
The
Juniper-Group-Based-Policy-Idcarries only the GBP tag.
The Juniper-Group-Based-Policy-Id VSA for MAC and interface-based GBP
tag filter looks like this:
PermEmp01 Auth-Type = EAP, Cleartext-Password := "gbp"
Juniper-Group-Based-Policy-Id = “100”
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 EX4400, EX4100, EX4650, and QFX5120 switches:
|
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 You can only configure this option when the |
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 You can only configure the |
|
|
Specify the GBP tag to apply when an interface is moved to a guest VLAN. If
the You can only configure the 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:
> show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC,
B - Blocked MAC)
Ethernet switching table : 2 entries, 2 learned
Routing instance : default-switch
Vlan MAC MAC GBP Logical SVLBNH/ Active
name address flags tag interface VENH Index source
vlan200 00:10:94:00:00:05 D 100 xe-0/2/2.0
vlan200 00:10:94:00:00:06 DR 100 vtep.32769 21.2.0.1Planning 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.
|
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.
| 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:
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:
set firewall family any filter name micro-segmentation set firewall family any filter name term name from source-mac-address MAC-Addr
set firewall family any filter name term name then gbp-tag PE-GRP
- 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-profileon the device. - Use the
gbp-dst-tagand/orgbp-src-tagmatch 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 6. -
If you want policy enforcement to take place at the ingress endpoint, you need to enable the
set fowarding-options evpn gbp ingress-enforcementoption.
-
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.
- Configure the radius
server:
set groups dot1xgbp access radius-server 10.204.96.102 port 1812 set groups dot1xgbp access radius-server 10.204.96.102 secret “secret key" set groups dot1xgbp access profile radius_profile_dev12 authentication-order radius set groups dot1xgbp access profile radius_profile_dev12 radius authentication-server 10.204.96.102 set groups dot1xgbp access profile radius_profile_dev12 radius accounting-server 10.204.96.102 set groups dot1xgbp access profile radius_profile_dev12 accounting order radius
- Configure the physical ports to support RADIUS
authentication:
set groups dot1xgbp protocols dot1x authenticator authentication-profile-name radius_profile_dev12 set groups dot1xgbp protocols dot1x authenticator interface xe-0/0/46.0 supplicant multiple set groups dot1xgbp protocols dot1x authenticator interface xe-0/0/46.0 mac-radius
- Set up the SGT tags on the RADIUS server using the Juniper-Switching-Filter or the
Juniper-Group-Based-Policy-Id
:
Contractor01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Switching-Filter = "apply action gbp-tag 100" Contractor01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Switching-Filter = "apply action gbp-tag 200" SecurityStaff01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Switching-Filter = "apply action gbp-tag 300" SecurityCam01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Switching-Filter = "apply action gbp-tag 400" EngServer01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Switching-Filter = "apply action gbp-tag 500"
Contractor01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Group-Based-Policy-Id = "100" Contractor01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Group-Based-Policy-Id = "200" SecurityStaff01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Group-Based-Policy-Id = "300" SecurityCam01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Group-Based-Policy-Id = "400" EngServer01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Group-Based-Policy-Id = "500"
- Enable VXLAN-GBP on the
switch:
set chassis forwarding-options vxlan-gbp-profile
- Create Firewall filter rules that leverage the SGTs (using values organized in the
matrix):
set groups gbp-policy firewall family any filter gbp-policy term pe-to-pe from gbp-src-tag 100 set groups gbp-policy firewall family any filter gbp-policy term pe-to-pe from gbp-dst-tag 100 set groups gbp-policy firewall family any filter gbp-policy term pe-to-pe then accept set groups gbp-policy firewall family any filter gbp-policy term pe-to-pe then count PE-PE set groups gbp-policy firewall family any filter gbp-policy term pe-to-es from gbp-src-tag 100 set groups gbp-policy firewall family any filter gbp-policy term pe-to-es from gbp-dst-tag 500 set groups gbp-policy firewall family any filter gbp-policy term pe-to-es then accept set groups gbp-policy firewall family any filter gbp-policy term pe-to-es then count PE-ES set groups gbp-policy firewall family any filter gbp-policy term pe-to-cam from gbp-src-tag 100 set groups gbp-policy firewall family any filter gbp-policy term pe-to-cam from gbp-dst-tag 400 set groups gbp-policy firewall family any filter gbp-policy term pe-to-cam then discard set groups gbp-policy firewall family any filter gbp-policy term pe-to-cam then count PE-CAM set groups gbp-policy firewall family any filter gbp-policy term con-to-cam from gbp-src-tag 200 set groups gbp-policy firewall family any filter gbp-policy term con-to-cam from gbp-dst-tag 400 set groups gbp-policy firewall family any filter gbp-policy term con-to-cam then discard set groups gbp-policy firewall family any filter gbp-policy term con-to-cam then count CON-CAM set groups gbp-policy firewall family any filter gbp-policy term con-to-es from gbp-src-tag 200 set groups gbp-policy firewall family any filter gbp-policy term con-to-es from gbp-dst-tag 500 set groups gbp-policy firewall family any filter gbp-policy term con-to-es then discard set groups gbp-policy firewall family any filter gbp-policy term con-to-es then count CON-ES set groups gbp-policy firewall family any filter gbp-policy term ss-to-cam from gbp-src-tag 300 set groups gbp-policy firewall family any filter gbp-policy term ss-to-cam from gbp-dst-tag 400 set groups gbp-policy firewall family any filter gbp-policy term ss-to-cam then accept set groups gbp-policy firewall family any filter gbp-policy term ss-to-cam then count SS-CAM set groups gbp-policy firewall family any filter gbp-policy term ss-to-es from gbp-src-tag 300 set groups gbp-policy firewall family any filter gbp-policy term ss-to-es from gbp-dst-tag 500 set groups gbp-policy firewall family any filter gbp-policy term ss-to-es then discard set groups gbp-policy firewall family any filter gbp-policy term ss-to-es then count SS-ES set apply-groups gbp-policy
- 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.commit check configuration check succeeds commit commit complete
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
interfaceandVLANGBP 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 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 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:
001094001199 Cleartext-Password := "001094001199" Juniper-Switching-Filter = "apply action gbp-tag 100"
For EAP based clients, the SGT is pushed from RADIUS server at the time of authentication. The configuration looks like this:
PermEmp01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Switching-Filter = "apply action gbp-tag 100"
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.
set firewall family ethernet-switching filter assign_tag term tag100 from source-mac-address 00:01:02:03:04:10:10 set firewall family ethernet-switching filter assign_tag term tag100 then gbp-src-tag 100 set firewall family ethernet-switching filter assign_tag term tag200 from source-mac-address 00:01:02:03:04:20:20 set firewall family ethernet-switching filter assign_tag term tag200 then gbp-src-tag 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.
set firewall family ethernet-switching filter gbp-policy term t10-100 from gbp-src-tag 100 set firewall family ethernet-switching filter gbp-policy term t10-100 from gbp-dst-tag 100 set firewall family ethernet-switching filter gbp-policy term t10-100 then accept set firewall family ethernet-switching filter gbp-policy term t10-200 from gbp-src-tag 100 set firewall family ethernet-switching filter gbp-policy term t10-200 from gbp-dst-tag 200 set firewall family ethernet-switching filter gbp-policy term t10-200 then discard
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.
set firewall family ethernet-switching filter assign_tag term tag300 from interface ge-0/0/30.0 set firewall family ethernet-switching filter assign_tag term tag300 then gbp-src-tag 300
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:
set chassis forwarding-options vxlan-gbp-profile
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.
|
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.
| 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
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:
set firewall family ethernet-switching filter name term name from source-mac-address MAC-Addr
set firewall family ethernet-switching filter name term name then gbp-src-tag PE-GRP
- 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-profileon the switch, then you use thegbp-dst-tagand/orgbp-src-tagmatch 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.
- Configure the radius
server:
set groups dot1xgbp access radius-server 10.204.96.102 port 1812 set groups dot1xgbp access radius-server 10.204.96.102 secret “secret key" set groups dot1xgbp access profile radius_profile_dev12 authentication-order radius set groups dot1xgbp access profile radius_profile_dev12 radius authentication-server 10.204.96.102 set groups dot1xgbp access profile radius_profile_dev12 radius accounting-server 10.204.96.102 set groups dot1xgbp access profile radius_profile_dev12 accounting order radius
- Configure the physical ports to support RADIUS
authentication:
set groups dot1xgbp protocols dot1x authenticator authentication-profile-name radius_profile_dev12 set groups dot1xgbp protocols dot1x authenticator interface xe-0/0/46.0 supplicant multiple set groups dot1xgbp protocols dot1x authenticator interface xe-0/0/46.0 mac-radius
- Set up the SGT tags on the RADIUS
server:
Contractor01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Switching-Filter = "apply action gbp-tag 100" Contractor01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Switching-Filter = "apply action gbp-tag 200" SecurityStaff01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Switching-Filter = "apply action gbp-tag 300" SecurityCam01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Switching-Filter = "apply action gbp-tag 400" EngServer01 Auth-Type = EAP, Cleartext-Password := "gbp" Juniper-Switching-Filter = "apply action gbp-tag 500"
- Enable VXLAN-GBP on the
switch:
set chassis forwarding-options vxlan-gbp-profile
- Create Firewall filter rules that leverage the SGTs (using values organized in the
matrix):
set groups gbp-policy firewall family ethernet-switching filter gbp-policy term pe-to-pe from gbp-src-tag 100 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term pe-to-pe from gbp-dst-tag 100 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term pe-to-pe then accept set groups gbp-policy firewall family ethernet-switching filter gbp-policy term pe-to-pe then count PE-PE set groups gbp-policy firewall family ethernet-switching filter gbp-policy term pe-to-es from gbp-src-tag 100 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term pe-to-es from gbp-dst-tag 500 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term pe-to-es then accept set groups gbp-policy firewall family ethernet-switching filter gbp-policy term pe-to-es then count PE-ES set groups gbp-policy firewall family ethernet-switching filter gbp-policy term pe-to-cam from gbp-src-tag 100 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term pe-to-cam from gbp-dst-tag 400 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term pe-to-cam then discard set groups gbp-policy firewall family ethernet-switching filter gbp-policy term pe-to-cam then count PE-CAM set groups gbp-policy firewall family ethernet-switching filter gbp-policy term con-to-cam from gbp-src-tag 200 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term con-to-cam from gbp-dst-tag 400 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term con-to-cam then discard set groups gbp-policy firewall family ethernet-switching filter gbp-policy term con-to-cam then count CON-CAM set groups gbp-policy firewall family ethernet-switching filter gbp-policy term con-to-es from gbp-src-tag 200 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term con-to-es from gbp-dst-tag 500 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term con-to-es then discard set groups gbp-policy firewall family ethernet-switching filter gbp-policy term con-to-es then count CON-ES set groups gbp-policy firewall family ethernet-switching filter gbp-policy term ss-to-cam from gbp-src-tag 300 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term ss-to-cam from gbp-dst-tag 400 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term ss-to-cam then accept set groups gbp-policy firewall family ethernet-switching filter gbp-policy term ss-to-cam then count SS-CAM set groups gbp-policy firewall family ethernet-switching filter gbp-policy term ss-to-es from gbp-src-tag 300 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term ss-to-es from gbp-dst-tag 500 set groups gbp-policy firewall family ethernet-switching filter gbp-policy term ss-to-es then discard set groups gbp-policy firewall family ethernet-switching filter gbp-policy term ss-to-es then count SS-ES set apply-groups gbp-policy
- 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.commit check configuration check succeeds commit commit complete