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.

GBP 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 GBP 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. See Examples of Matching on IP Address.
Note: Matching on IP addresses is not supported in pure layer 2 deployments.
Note:

IPv4 and IPv6 match conditions cannot co-exist in the same filter.

Note:

The syntax and behavior may be different for different platforms. See Table 2.

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. See Examples of Matching on MAC Address.

interface <interface_name>

 Match interface name. This match is applied to packets arriving on the specified interface(s). See Examples of Matching on Interface.
Note:

Matching on interfaces is not supported on all platforms. See Table 2.

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

 Match VLAN IDs. This match is applied to packets arriving on the specified VLAN ID(s). See Examples of Matching on VLANs.
Note:

Matching on VLAN IDs is not supported on all platforms. See Table 2.

.

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

Table 2 shows the differences from mainline functionality for different platforms.

Table 2: Platform-Specific GBP Tag Assignment Behavior

Platform

Difference

EX4100

  • Matching on VLAN IDs is not supported.

QFX5130, QFX5700

  • Syntax for matching on IP address is as follows:

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

  • You can match on IP address even in a pure layer 2 network.

  • Only IPv4 /32 and IPv6 /128 address matches are supported. Matching on IP prefixes is not supported.

  • Matching on interfaces is not supported.

  • Matching on VLAN IDs is not supported.

  • Filter must contain the global-bind option. For example:

    set firewall family any filter f1 micro-segmentation 
set firewall family any filter f1 global-bind 
set firewall family any filter f1 term t1 from ip-version ipv4 ip-address 10.0.0.101/32 
set firewall family any filter f1 term t1 then gbp-tag 101

Examples of Matching on IP Address

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

See Longest Prefix Match versus Strict Firewall Term Order for behavior when the incoming IP address matches more than one IP address condition.

Examples of Matching on MAC Address

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

Examples of Matching on Interface

Here's an example of GBP tag assignment based on interface:

You can have multiple interface match conditions within a single firewall filter term. For example:

You can combine interface match conditions alongside vlan-id match conditions in a single firewall filter term when you use Service Provider-style configuration. For example:

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.

Examples of Matching on VLANs

Note: Matching on VLAN IDs is not supported on EX4100 devices.

Here's an example of GBP tag assignment using VLAN IDs:

You can have multiple vlan-id match conditions within a single firewall filter term:

You can match on VLAN ranges:

You can match on VLAN lists:

Assigning GBP 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: Assigning GBP tags using RADIUS is not supported on all platforms. See Table 4.
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.

You can assign GBP tags using either of the following VSAs:

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

  • The Juniper-Group-Based-Policy-Id carries only the GBP tag.

Note:

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

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

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:

Here's an EAP example using the Juniper-Group-Based-Policy-Id VSA:

For both VSAs, the configured GBP tag must be a non-zero positive value in the range (1-65535).

You can use dot1x CLI statements to configure GBP tags. This is shown in Table 3.

Table 3: 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.

Additionally, 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:

Table 4 shows the differences from mainline functionality for different platforms.

Table 4: Platform-Specific RADIUS Tag Assignment Behavior

Platform

Difference

QFX5130, QFX5700

Assigning GBP tags using RADIUS is not supported.

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

Concurrent Matches

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

Table 5: 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: For most platforms, 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 Table 6 for exceptions. See GBP MAC/IP Inter-tagging for information on MAC/IP inter-tagging.

Table 6 shows the differences from mainline functionality for different platforms.

Table 6: Platform-Specific Concurrent Matches Behavior

Platform

Difference

QFX5130, QFX5700

The IP address match takes precedence over the MAC address match in all situations, even if MAC/IP inter-tagging is enabled.

Longest Prefix Match versus Strict Firewall Term Order

You have the option of choosing longest prefix match versus strict firewall term order.

Note: The longest prefix match option is not supported on all platforms. See Table 7.

For example, here's a microsegmentation filter that contains overlapping IP addresses:

If you choose to use strict firewall term order, then 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.

If you choose to use longest prefix match, then that same packet would be assigned GBP tag 20 because the second term (t2) provides the more specific match. This is the default behavior.

If you want to change the default behavior and use strict 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.

Table 7 shows the differences from mainline functionality for different platforms.

Table 7: Platform-Specific Longest Prefix Match Behavior

Platform

Difference

QFX5130, QFX5700

Since IP prefix matches are not supported, the longest prefix match option is not applicable. Firewall terms are evaluated strictly in term order.

Packet Classification of GBP-Tagged Traffic

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.

GBP 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 GBP 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 Zero Trust Inline Segmentation 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 GBP 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.

Table 8 shows the differences from mainline functionality for different platforms.

Table 8: Platform-Specific Enforcement Using GBP Tags Behavior

Platform

Difference

QFX5130, QFX5700

  • Both ingress and egress enforcement are automatically supported.

  • Filter must contain the global-bind option. For example:

    set firewall family any filter gbp-policy global-bind
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

  • You can bind only a single GBP policy enforcement filter. You cannot bind multiple GBP policy enforcement filters. All your policies are specified as terms within that single filter.

Enforcement Using Destination IP Address

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.

Note: Not all platforms support or require enforcement using destination IP address. See Table 9.

Here's an example of using the GBP source tag along with the destination IP address:

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

Table 9 shows the differences from mainline functionality for different platforms.

Table 9: Platform-Specific Enforcement Using Destination IP Address Behavior

Platform

Difference

QFX5130, QFX5700

Enforcement using destination IP address is not required because you can assign tags based on IP addresses even in a pure layer 2 network. Simply create a tag assignment based on the IP address and enforce policy on the assigned tag as you normally do.

Enforcement Using L4 Fields

You can enforce policy using the L4 fields shown in Table 10. This provides you with additional granularity to control application traffic.

Table 10: Support for Additional L4 Policy Matches
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 payload-protocol protocol Match the payload protocol.
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 by default but can reduce the supported GBP scale. To disable L4 filters: set forwarding-options evpn-vxlan gbp tag-only-policy.

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

Table 11 shows the differences from mainline functionality for different platforms.

Table 11: Platform-Specific Enforcement Using L4 Fields Behavior

Platform

Difference
EX9200 and MX Series

  • Enforcement using L4 filters is not supported.

QFX5130, QFX5700

  • Only the following L4 fields are supported for enforcement:

    • destination-port

    • source-port

    • ip-protocol (IPv4)

    • payload-protocol (IPv6)

  • tag-only-policy configuration is not supported.

Packets Excluded from Enforcement

Not all packets are subject to GBP policy enforcement. Table 12 shows the differences between platforms.

Table 12: Platform-Specific Excluded From Enforcement Behavior

Platform

Difference

EX4100

  • Policy enforcement is not supported for host-generated packets or broadcast, unknown, and multicast traffic with the exception of certain DHCP security packets, where policy enforcement is supported. See dhcp-security.

  • Policy is not enforced on 802.1X packets. Policy enforcement takes place after authentication.

EX4400, EX4650, EX9200, QFX5120, MX Series

  • Policy enforcement is not supported for host-generated packets or broadcast, unknown, and multicast traffic with the exception of certain DHCP security packets, where policy enforcement is supported. See dhcp-security.

  • Policy is enforced on 802.1X packets. If you create a CLI tag assignment for a specific MAC address and you create a policy that discards packets for that tag, then the 802.1X requests for authentication from that MAC address will be discarded. From the perspective of the end user, authentication has timed out.

QFX5130, QFX5700

  • Policy enforcement is not supported for host-generated packets or broadcast, unknown, and multicast traffic including DHCP security packets.

Explicit Default Discard

When no conditions are matched, the default action is to accept the packet. If you don't want to accept a packet by default, you can specify an explicit default discard action for packets that don't match any conditions.

Note: Explicit default discard is not supported on all platforms. See Table 13.

Here's an example of explicit default discard:

Term t2 contains a discard action but no match conditions. This acts 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.

Table 13 shows the differences from mainline functionality for different platforms.

Table 13: Platform-Specific Explicit Default Discard Behavior

Platform

Difference
EX9200 and MX Series

  • Explicit default discard is not supported.

QFX5130, QFX5700

  • Explicit default discard is supported but unnecessary. The default action is to discard the packet.

  • If the destination GBP tag for a packet arriving at the ingress does not match any GBP policy, the packet is accepted into the network even if the default is to discard the packet. This is to allow the egress to enforce policy.

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

Ingress policy 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.

Table 14 shows the differences from mainline functionality for different platforms.

Table 14: Platform-Specific Ingress Enforcement Behavior

Platform

Difference

QFX5130, QFX5700

  • Ingress enforcement is automatically supported. You do not need to configure ingress enforcement nor can you disable ingress enforcement.

  • If the destination GBP tag for a packet arriving at the ingress does not match any GBP policy, the packet is accepted into the network even if the default is to discard the packet. This is to allow the egress to enforce policy.

Tag Propagation for IP Prefix Routes Using EVPN Type 5 Advertisements

In addition to tag propagation triggered by MAC-IP learning, which results in /32 IP routes, we support GBP tag propagation for IP prefix routes using EVPN Type 5 advertisements.

Note: Not all platforms support tag propagation for IP prefix routes. See Table 15.

With IP prefix routes, tag propagation can 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 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.

Table 15 shows the differences from mainline functionality for different platforms.

Table 15: Platform-Specific Tag Propagation for IP Prefix Routes Behavior

Platform

Difference

EX4100

Tag propagation for IP prefix routes is not supported.

QFX5130, QFX5700

Tag propagation for IP prefix routes is not supported.

Filter-Based Forwarding of GBP-Tagged Traffic

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.

Note: Not all platforms support filter-based forwarding. See Table 19.

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. See Table 16 and Table 17.

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

Filter-Based Forwarding Configuration Examples (EX4xxx and QFX5120 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 17: 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 IPv4 /32 and IPv6 /128 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 18 for CLI configuration examples.

Table 18: 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 19 summarizes the filter-based forwarding platform-specific behaviors for your platforms.

Table 19: Platform-Specific Filter-Based Forwarding Behavior

Platform

Difference

EX4xxx

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

  • Specify the applicable routing instance directly in the filter.

EX92xx

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

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

  • Specify the applicable routing instance directly in the filter.
QFX5130, QFX5700 Filter-based forwarding is not supported.

GBP MAC/IP Inter-tagging

MAC/IP inter-tagging allows MAC-based GBP tag assignments to apply to routed traffic and IP-based GBP tag assignments to apply to switched traffic.

  • With MAC/IP inter-tagging enabled, both MAC-based and IP-based GBP filters apply to switched and routed traffic.

  • With MAC/IP inter-tagging disabled, a MAC-based GBP filter applies only to switched traffic and an IP-based GBP filter applies only to routed traffic.

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

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

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

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

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

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

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

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

To enable MAC/IP inter-tagging:

Note:

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

Note:

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

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

Table 20 shows the differences from mainline functionality for different platforms.

Table 20: Platform-Specific MAC/IP Inter-Tagging Behavior

Platform

Difference

QFX5130, QFX5700

MAC/IP inter-tagging is enabled automatically. You cannot disable it.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
25.4R1
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. See Enforcement Using Destination IP Address.
25.4R1
Starting in Junos OS Release 25.4R1 on EX4100, EX4400, EX4650, and QFX5120 platforms, MAC/IP inter-tagging is enabled by default. See GBP MAC/IP Inter-tagging.
25.2X100-D30
Starting in Junos OS Evolved Release 25.2X100-D30, the QFX5130 and QFX5700 platforms support GBP processing.
25.2R1
Starting in Junos OS Release 25.2R1 on EX9200 and MX platforms, we support filter-based forwarding of GBP-tagged traffic. See Filter-Based Forwarding of GBP-Tagged Traffic.
24.4R1
Starting in Junos OS Release 24.4R1, we support longest prefix match in addition to strict firewall term order in GBP tag assignment filters. See Longest Prefix Match versus Strict Firewall Term Order.
24.4R1
Starting in Junos OS Release 24.4R1 on EX4100, EX4400, EX4650, and QFX5120 platforms, we support filter-based forwarding of GBP-tagged traffic. See Filter-Based Forwarding of GBP-Tagged Traffic.
24.2R1
Starting in Junos OS Release 24.2R1 on EX4100, EX4400, EX4650, and QFX5120 platforms, we support MAC/IP inter-tagging. See GBP MAC/IP Inter-tagging.
24.2R1
Starting in Junos OS Release 24.2R1 on EX4100, EX4400, EX4650, and QFX5120 platforms, we support explicit default discard in GBP policy enforcement filters. See Explicit Default Discard.
24.2R1
Starting in Junos OS Release 24.2R1 on EX4400, EX4650, EX9200, and QFX5120 platforms, we support GBP tag propagation for IP prefix routes using EVPN Type 5 advertisements. See Tag Propagation for IP Prefix Routes Using EVPN Type 5 Advertisements.
23.4R1
Starting in Junos OS Release 23.4R1, we support interface range, interface list, and multiple interface entries in GBP tag assignment filters. See Examples of Matching on IP Address.
23.4R1
Starting in Junos OS Release 23.4R1 on EX4400, EX4650, and QFX5120 platforms, we support VLAN range, VLAN list, and multiple VLAN entries in GBP tag assignment filters. See Examples of Matching on VLANs.
23.4R1
Starting in Junos OS Release 23.4R1 on EX4400, EX4650, and QFX5120 platforms, we support a combination of interface and VLAN match conditions within a single term in GBP tag assignment filters when using Service Provider-style configuration. See Examples of Matching on Interface.
23.4R1
Starting in Junos OS Release 23.4R1, we support the juniper-group-based-policy-id VSA for RADIUS authentication. See Assigning GBP Tags Using RADIUS.
23.4R1
Starting in Junos OS Release 23.4R1, we support gbp-tag options in protocols dot1x authenticator interface CLI statements. See Assigning GBP Tags Using RADIUS.
23.2R1
Starting in Junos OS Release 23.2R1 on EX4100, EX4400, EX4650, and QFX5120 platforms, we support L4 matches in GBP policy enforcement filters. See Enforcement Using L4 Fields.
22.4R1
Starting in Junos Release 22.4R1, you can perform policy enforcement at the ingress. See GBP Policy Enforcement at the Ingress and Tag Propagation for EVPN-VXLAN.