Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

GBP Processing

GBP processing includes tag assignment, packet classification, and policy enforcement.

Tag Assignment

Assign GBP tags statically using the CLI or dynamically using RADIUS authentication.

Tag assignment refers to configuring the mapping between a user and their group and programming this mapping into MAC address tables and internal data structures. Note that you don't configure group membership per se. Different users with the same tag assignment implicitly belong to the same group.

You can configure tag assignment statically through the CLI or dynamically through RADIUS authentication. Tag assignment through RADIUS authentication is the preferred approach as this gives you the greatest flexibility.

  • When you configure tag assignment statically using the CLI, you're creating a mapping between a user and a GBP tag, or more accurately, between a proxy of that user (such as their MAC or IP address) and a GBP tag. To make this approach less cumbersome, especially if you have many users, we give you the flexibility to configure tag assignment at different levels, from the interface down to the individual MAC addresses. For example, if you want all users connected to the same interface to be assigned the same tag, you would configure the tag for that interface to apply to all directly connected users. On the other hand, if you want a specific user to be assigned a specific tag, then you would configure tag assignment based on their MAC or IP address.

    The downside of static CLI configuration is that it requires apriori knowledge of the user (where the user is connected, what their MAC or IP address is, etc.). You also need to reconfigure this mapping if the user changes location or device in the future.

    For example, let's say you want to configure GBP tag 10 for a user named John and you want to use his MAC address as the proxy for that user. In this case, you'll need to know John's MAC address before you can map it to GBP tag 10. Once you configure this mapping, the GBP-enabled switch can then program it into its MAC address tables and internal data structures for data plane processing. If John changes device to another MAC address, you'll need to manually reconfigure this mapping.

    We leverage familiar firewall CLI statements to configure tag assignment. Specifically, you create a firewall filter that configures a specific GBP tag when specific criteria (for example, MAC address match) are met. To distinguish between a regular firewall filter and a tag assignment firewall filter, we introduce a new type of filter specific to microsegmentation.

  • When you configure tag assignment dynamically using RADIUS authentication, you don't need prior knowledge of the user's networking configuration. You simply configure RADIUS to offer the desired GBP tag when you authenticate the user.

    In our example above, when John authenticates with the RADIUS server, he is offered GBP tag 10. There is no need for you to determine John's MAC address at all. The GBP-enabled switch, acting as the authenticator, sees both John's MAC address and the offered GBP tag as part of the authentication exchange. The switch can therefore program this mapping into its MAC address tables and internal data structures directly without requiring CLI intervention. If John changes devices, he will re-authenticate with the RADIUS server, and the GBP-enabled switch will automatically reprogram its MAC address tables and internal data structures with the new association.

    Tag assignment using RADIUS is also supported for wireless users when connecting to a Mist AP. In this situation, the Mist AP acts as the authenticator and becomes aware of the mapping between the user's MAC address and their GBP tag. Armed with this information, the Mist AP notifies the upstream GBP-enabled switch of this mapping using proprietary messaging. Upon reception of this notification, the GBP-enabled switch programs its MAC address tables and internal data structures with the new mapping.

Note:

When you use RADIUS to dynamically configure tag assignment on a directly connected wired user, the GBP-enabled switch creates a MAC or an interface-based assignment depending on how you configure RADIUS.

When you use RADIUS to dynamically configure tag assignment on a wireless user attached to a Mist AP, the GBP-enabled switch creates a MAC-based assignment.

When you use the CLI to statically configure tag assignment, you can configure different types of assignments to suit your requirements. This may reduce the amount of configuration needed in some situations.

Assigning Tags Using the CLI

To assign GBP tags using the CLI, you use a special type of firewall filter called a microsegmentation filter. Just like regular firewall filters, you specify the match conditions and the subsequent actions:

For the microsegmentation filter, the supported match conditions are shown in Table 1 and the single supported action is to assign a GBP tag.

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

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

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

 Match IPv4/IPv6 address/prefix-lists. This match is applied to the source IP address on packets arriving on the access link from the attached client.
Note:

Starting in Junos OS Release 24.4R1, you can specify whether you want IP address terms to be evaluated in term order or by longest prefix match. By default, IP address terms are evaluated by longest prefix match in Junos OS Release 24.4R1 and later. In releases prior to Junos OS Release 24.4R1, IP address terms are evaluated in term order only. See Longest Prefix Match versus Strict Firewall Term Order.

mac-address <mac address>

 Match MAC address. This match is applied to the source MAC address on packets arriving on the access link from the attached client.

interface <interface_name>

 Match interface name.
Note:

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

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

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

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

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

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

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

 Match VLAN IDs.
Note:

Not supported on the EX4100 switches

Note:

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

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

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

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

To ensure consistent application of policy, we recommend that you configure the same GBP tag assignments everywhere (at both the ingress and egress).

Example of Matching on MAC Address

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

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

Example of Matching on IP Address

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

Note: Matching on IP addresses is not supported in pure layer 2 deployments.
Note:

Note that microsegmentation filters cannot have both IPv4 and IPv6 matches together as part of the same filter.

Example of Matching on VLANs and Interfaces

Here's an example of matching on a VLAN ID (not supported on EX4100 switches):

Starting in Junos OS Release 23.4R1:

  • The EX4400, EX4650, and QFX5120 switches in Supported Platforms support:

    • VLAN lists and ranges in a GBP filter

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

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

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

  • The EX4100 switches in Supported Platforms support multiple interface entries in a single term in a GBP filter.

Here's an example of matching on VLAN ranges (not supported on EX4100 switches):

Here's an example on matching on interfaces:

Assigning Tags Using RADIUS

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

Note:

Only MAC and interface-based GBP tag assignments are supported when using RADIUS:

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

  • If you configure RADIUS authentication with single supplicant mode, then GBP tagging is interface-based.

To accommodate the distribution of GBP tags during authentication, we leverage the use of vendor specific attributes (VSAs), as supported by the AAA service framework. These VSAs are carried as part of the standard RADIUS request reply message, and provide a built-in extension to handle implementation-specific information such as our GBP tags. 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 GBP tag 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, we support a new VSA called Juniper-Group-Based-Policy-Id on the EX4100, EX4400, EX4650, and QFX5120 switches.

Note:

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

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

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

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

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

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

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

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

Table 2: Dot1x Configuration Statements for GBP

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 dot1x interface detail command:

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

Tag Assignment Priority

This section clarifies the behavior when you create potentially ambiguous match conditions.

Assignment Using Both CLI and RADIUS

You typically configure tag assigment either using the CLI or using RADIUS, but not both. In the event that you do use both and there's a conflicting assignment (for example, CLI assigns GBP tag 10 to a user while RADIUS assigns GBP tag 20 to the same user), then the RADIUS assignment prevails.

Conflicting Match Conditions

Here's an example of a conflicting match condition:

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.

Concurrent Matches

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

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

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

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

mac-address<mac address>
4

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

vlan-id<vlan id>
6 (Lowest)

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

Longest Prefix Match versus Strict Firewall Term Order

You have the option of choosing longest prefix match versus strict firewall term order. For example, here's a microsegmentation filter that contains overlapping IP addresses:

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.

However, 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 want to retain the legacy behavior of strictly following firewall term order, then configure the filter as follows:

Note:

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

Packet Classification

Packet classification in the context of GBP refers to retrieving the configured GBP tag during data plane processing of an incoming packet.

Packet classification occurs at both the ingress and the egress switch. At ingress, the switch classifies the incoming packet from the access link to obtain the GBP tag of the sender (source). At egress, the switch classifies the incoming packet from the network to obtain the GBP tag of the recipient (destination).

Once source and destination tags are retrieved, policy enforcement can take place.

Policy Enforcement

Create microsegmentation policies using GBP tags.

The GBP-enabled switch enforces policy based on rules that you create for the assigned GBP tags. In order to support GBP policy enforcement, we've extended regular firewall filter capability to include matching and acting on GBP tags. Regular firewall actions such as accept or deny are supported.

When running with EVPN-VXLAN, policy enforcement typically takes place at the egress using both the source and destination GBP tags. Ingress enforcement is also supported (see Policy Enforcement at the Ingress and Tag Propagation for EVPN-VXLAN), but we recommend you use egress enforcement in high scale networks. Egress enforcement is the default behavior.

When running without EVPN-VXLAN, policy enforcement typically takes place at the ingress with either source GBP tag and destination IP address or with both source and destination GBP tags depending on your network. See Unified Access Policy for more information.

Enforcement Using GBP Tags

Note:

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

Here's an example of GBP policy enforcement:

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

Enforcement Using Destination IP Address

Starting in Junos OS Release 25.4R1, we allow you to enforce policy based on destination IP address when using the gbp-pure-l2-profile.

In pure L2 deployments, the access switches typically connect up to a WAN router as a layer 3 gateway. The WAN router is not GBP-aware and cannot pass GBP tags. Therefore, policy can only be enforced at the ingress access switch based on the source GBP tag. In this situation, we allow you to augment the policy to include the destination IP address. For example:

For more information on this use case, see Using the GBP Pure L2 Profile.

Enforcement Using L4 Fields

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Explicit Default Discard

Description

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

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

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

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

Explicit default discard is supported on the EX4100, EX4400, EX4650, and QFX5120 Series switches shown in Supported Platforms. Explicit default discard is not supported on the EX92xx switches or MX Series routers

Policy Enforcement at the Ingress and Tag Propagation for EVPN-VXLAN

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 Route Coexistence with EVPN-VXLAN for information on these types of routes.

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

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

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

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

Note:

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

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

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

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

Tag Propagation for IP Prefix Routes Using EVPN Type 5 Advertisements

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

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

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

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

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

Note:

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

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

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

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

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

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

Limitations of this feature include the following:

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

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

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

Filter-Based Forwarding

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

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

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

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

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

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

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

Description

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

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

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

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

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

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

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

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

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

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

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

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

Limitations:

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

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

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

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

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

Description

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

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

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

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

Limitations:

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

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

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

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

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

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

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

Table 9: Platform-Specific Behavior

Platform

Difference

EX4xxx Series

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

  • Specify the applicable routing instance directly in the filter.

EX92xx Series

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

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

MX Series

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

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

QFX Series

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

  • Specify the applicable routing instance directly in the filter.

GBP MAC/IP Inter-tagging

Prior to Junos OS Release 24.2R1, a MAC-based GBP filter only applied to switched traffic, and an IP-based GBP filter only applied to routed traffic.

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

Starting in Junos OS Release 25.4R1, MAC/IP inter-tagging is enabled by default. You don't need to explicitly configure it.

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

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

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

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

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

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

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

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

To enable MAC/IP inter-tagging:

Note: You don't need to configure MAC/IP inter-tagging starting in Junos OS Release 25.4R1. It is enabled by default.
Note:

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

Note:

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

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