1. RBFS Subscriber Filters
1.1. Overview
RBFS Subscriber Filters, also referred to as subscriber ACLs, consist of a set of rules defining packet match criteria and actions. There are separate rules for IPv4 and IPv6 downstream (egress to subscriber) and upstream (ingress from subscriber) packets. These rules support various match criteria and actions, some of which are specific to address families or directions. Each rule is assigned a priority, and the decision between multiple matching rules is based on these priorities, where lower values take precedence.
The available actions include accept, drop, or http-redirect where the last one refers to the RBFS HTTP Redirect Service. When the action is drop, matching traffic is silently discarded. The filters are categorized into two primary types, namely l3v4 for IPv4 and l3v6 for IPv6, applicable to either ingress or egress direction.
To apply these filters to subscribers, there are two ways. They can be applied through the access service-profile or directly using the corresponding RADIUS attributes with the second method taking priority.
1.2. About the Match Criteria
When multiple match criteria are defined within a single rule, they are treated as a logical AND operation, requiring all criteria to be met for the rule to be considered as a match. However, using unsupported match criteria, such as destination-ipv4-subscriber-prefix in ingress (upstream), can potentially lead to session termination. In the case of CoA (Change of Authorization), the filter assignment is rejected using CoA NAK, if such unsupported criteria are encountered.
Even if filters are assigned to a subscriber, those filters are applied globally, indicating that all traffic from all interfaces and subscribers is evaluated against all rules. Consequently, RBFS has introduced specific options to restrict rules to individual subscribers. For ingress (upstream) rules, it is recommended to enable the subscriber-ifl option, ensuring that only traffic received from the corresponding subscriber is matched. With the subscriber-ifl option, packets are matched based on incoming subscriber IFL. However, this option is not supported in egress(downstream), requiring the limitation of traffic using subscriber address prefix information. Thus, RBFS introduced the options source-ipv4-subscriber-prefix, source-ipv6-subscriber-prefix, destination-ipv4-subscriber-prefix, destination-ipv6-subscriber-prefix, source-ipv6-delegated-subscriber-prefix, and destination-ipv6-delegated-subscriber-prefix. With these options enabled, the dynamically assigned subscriber address prefix is automatically integrated into the corresponding filter instance to constrain those rules to a specific subscriber.
|
Improperly configured filters assigned to one subscriber may create a negative impact on other subscribers as well. |
2. Subscriber Filters Configuration
The configuration hierarchy for Subscriber ACL is illustrated in the diagram.
2.1. Configure Subscriber Filters
Syntax:
set forwarding-options subscriber-acl <l3v4|l3v6> rule <rule-name> ordinal <ordinal-value> <option> <attribute> <value>
| Attribute | Description |
|---|---|
<l3v4 | l3v6> |
Specify |
<rule-name> |
Subscriber ACL rule name. |
<ordinal-value> |
The mandatory ordinal value is used to differentiate multiple rules within the rule set. |
action |
The desired action, which can be either |
priority <priority-value> |
The priority of the rule, where the lower value has a higher priority. |
match |
The match criteria. |
2.1.1. Configuring Subscriber Filter Match Criteria
Syntax:
set forwarding-options subscriber-acl <l3v4|l3v6> rule <rule-name> ordinal <ordinal-value> match <attribute> <value>
| Attribute | Description |
|---|---|
destination-ipv4-prefix <destination-ipv4-prefix> |
Packets are matched when the IPv4 destination address is within the defined prefix. |
destination-ipv4-prefix-list <destination-ipv4-prefix-list> |
Packets are matched when the IPv4 destination address is within one of the prefixes listed in the defined prefix list. |
destination-ipv4-subscriber-prefix <true> |
Packets are matched when the IPv4 destination address is within the dynamically assigned subscriber IPv4 address prefix (sometimes, referred to framed prefix). Consequently, this option shares similarity to the |
destination-ipv6-prefix <destination-ipv6-prefix> |
Packets are matched when the IPv6 destination address is within the defined prefix. |
destination-ipv6-prefix-list <destination-ipv6-prefix-list> |
Packets are matched when the IPv6 destination address is within one of the prefixes listed in the defined prefix list. |
destination-ipv6-subscriber-prefix <true> |
Packets are matched when the IPv6 destination address is within the dynamically assigned subscriber IPv6 address prefix (sometimes, referred to framed prefix). Consequently, this option shares similarity to the destination-ipv4-prefix, where the prefix is automatically set to the dynamic subscriber prefix. This option is allowed only in the egress (downstream) direction. |
destination-ipv6-delegated-subscriber-prefix <destination-ipv6-delegated-subscriber-prefix> |
This option is similar to the |
source-ipv4-prefix <source-ipv4-prefix> |
Packets are matched when the IPv4 source address is within the defined prefix. |
source-ipv4-prefix-list <source-ipv4-prefix-list> |
Packets are matched when the IPv4 source address is within one of the prefixes listed in the defined prefix list. |
source-ipv4-subscriber-prefix <source-ipv4-subscriber-prefix> |
Packets are matched when the IPv4 source address is within the dynamically assigned subscriber IPv4 address prefix (sometimes, referred to framed prefix). Consequently, this option shares similarity to |
source-ipv6-prefix <source-ipv6-prefix> |
Packets are matched when the IPv6 source address is within the defined prefix. |
source-ipv6-prefix-list <source-ipv6-prefix-list> |
Packets are matched when the IPv6 source address is within one of the prefixes listed in the defined prefix list. |
source-ipv6-subscriber-prefix <source-ipv6-subscriber-prefix> |
Packets are matched when the IPv6 source address is within the dynamically assigned subscriber IPv6 address prefix (sometimes, referred to framed prefix). Consequently, this option shares similarity to |
source-ipv6-delegated-subscriber-prefix true |
This option is similar to the |
source-l4-port <source-l4-port> |
Packets are matched based on the layer 4 source port (TCP or UDP port). |
destination-l4-port <destination-l4-port> |
Packets are matched based on the layer 4 destination port (TCP or UDP port). |
ip-protocol <ip-protocol> |
Packets are matched depending on the IP protocol (TCP or UDP). However, this option is not compatible with the MPLS-encapsulated traffic. Consequently, filtering based on IP protocol is not possible for MPLS traffic received from the core. For instance, it is feasible to drop all traffic to port 80, but it is not possible to selectively drop only TCP traffic while permitting UDP traffic when receiving traffic with an MPLS label. |
subscriber-ifl <true> |
Packets are matched based on incoming subscriber IFL. This option is allowed only in the ingress (upstream) direction. |
2.1.2. Configuring Subscriber Filter Actions
Syntax:
set forwarding-options subscriber-acl <l3v4|l3v6> rule <rule-name> ordinal <ordinal-value> action <attribute> <value>
| Attribute | Description |
|---|---|
permit |
Forward packets. |
drop |
Silently discard packets. |
http-redirect true |
Specify true to enable the redirect service. Note: To disable http-redirect, use the |
The following example shows an IPv4 subscriber filter configuration in which the applied ACL is ipv4-acl-in.
supervisor@rtbrick: cfg> show config forwarding-options subscriber-acl l3v4
{
"rtbrick-config:l3v4": {
"rule": [
{
"rule-name": "ipv4-acl-in",
"ordinal": [
{
"ordinal-value": 1,
"match": {
"destination-l4-port": 80,
"ip-protocol": "TCP"
},
"action": {
"http-redirect": "true"
},
"priority": 1001
}
]
}
]
}
}2.1.3. Attaching the ACL Rule
Syntax:
set access service-profile profile-name <profile-name> <attribute> <value>
| Attribute | Description |
|---|---|
<profile-name> |
Service profile name. |
<http-redirect> |
HTTP redirect service configuration. |
<url> |
HTTP redirect target URL. |
<acl> |
Subscriber ACL (filter) configuration. |
<ipv4-acl-in> |
IPv4 upstream ACL (ingress from subscriber). |
<ipv4-acl-out> |
IPv4 downstream ACL (egress to subscriber). |
<ipv6-acl-in> |
IPv6 upstream ACL (ingress from subscriber). |
<ipv6-acl-out> |
IPv6 downstream ACL (egress to subscriber). |
3. Operational Commands
3.1. Subscriber Filter Show Commands
The show commands provide detailed information about the subscriber filter.
3.1.1. Subscriber ACL (Filter) Information
The show subscriber <id> acl command provides a comprehensive list of all ACL instances initiated for the subscriber, including RBFS Subscriber Filters and Ascend Data Filters (ADF). Additionally, this command provides the option to view detailed information for each filter instance by appending the corresponding filter name. Consequently, the filters are displayed with all variables, such as destination-ipv4-subscriber-prefix, replaced by their actual prefixes for clarity.
Syntax:
show subscriber <subscriber-id> acl <acl-name>
Example:
supervisor@rtbrick: op> show subscriber 1369375761697341441 acl ipv4-acl-in-ipoe-lag-1/1369375761697341441 Rule: ipv4-acl-in-ipoe-lag-1/1369375761697341441 ACL type: l3v4 Ordinal: 1 Priority: 1001 Match: Direction: ingress Destination L4 port: 80 IP protocol: TCP Action: HTTP-redirect: True URL: www.rtbrick.com
©Copyright 2024 RtBrick, Inc. All rights reserved. The information contained herein is subject to change without notice. The trademarks, logos and service marks ("Marks") displayed in this documentation are the property of RtBrick in the United States and other countries. Use of the Marks are subject to RtBrick’s Term of Use Policy, available at https://www.rtbrick.com/privacy. Use of marks belonging to other parties is for informational purposes only.