PBR/PBF Redundancy
This chapter provides information about policy-based routing and policy-based forwarding redundancy.
Topics in this chapter include:
Applicability
This chapter was initially written based on SR OS Release 14.0.R7, but the MD-CLI in the current edition corresponds to SR OS Release 23.7.R1. Secondary actions in IPv4, IPv6, and MAC access control list (ACL) filter policies are supported in SR OS Release 14.0.R1, and later.
Overview
PBR and PBF
Policy-based routing (PBR) and policy-based forwarding (PBF) are used to make forwarding decisions based on filter policies defined by the network administrator. PBR is L3 traffic steering, whereas PBF is L2 traffic steering. For ordinary routing, the destination IP address is looked up in the routing table; for ordinary forwarding in a VPLS, the destination MAC address is looked up in the forwarding database (FDB). However, with PBR, routing decisions are based on IP filters that use more criteria, such as source and destination IP address, port number, DSCP value, and so on. Packets can take paths that differ from the next hop path specified by the routing table. PBF forwarding decisions can be made based on IP filters, but also on MAC filters that use criteria such as source and destination MAC address, inner and outer VLAN tag, dot1p priority, and so on.
The benefits of PBR/PBF are the following:
The forwarding decision can be based on multiple attributes of a packet, not only its destination address
Different QoS treatment can be provided, based on additional criteria
Cost saving: time-sensitive traffic can be sent over higher-speed links at a higher cost, while bulk file transfers are sent over lower-speed links at a lower cost
Load sharing: traffic can be load balanced across multiple and unequal paths
In most situations, PBR/PBF works on inbound unicast packets; therefore, a filter is applied at the ingress of access or network interfaces. In this chapter, examples will be shown for IPv4 filters and MAC filters applied on SAP ingress. IPv6 filters are also supported, but the examples in this chapter are based on IPv4. Filters are also supported on the egress, but that is beyond the scope of this chapter.
An IPv4 filter contains one or more entries, which can be configured with the following command:
[ex:/configure filter ip-filter "IP-1"]
A:admin@PE-1# entry 10 ?
entry
Immutable fields - egress-pbr
action + Enable the action context
apply-groups - Apply a configuration group at this level
apply-groups-exclude - Exclude a configuration group at this level
description - Text description
egress-pbr - PBR that has an effect when this filter is applied on egress
filter-sample - Sample matching traffic if IP interface is set to cflowd ACL mode
interface-sample - Sample matching traffic if IP interface is set to cflowd interface mode
log - Log that is used for packets matching this entry
match + Enter the match context
pbr-down-action- - Action when PBR or PBF target for this entry is not available
override
sample-profile - Cflowd sample profile ID to match packets
sticky-dest - Time before action with available PBR or PBF destination and highest
priority
PBF in the "VPLS-3" service on PE-1 shows the example topology with the "VPLS-3" service configured on the PEs. PBF is applied in the "VPLS-3" service on PE-1.
The following configuration creates an IPv4 filter that forwards all packets matching the source and destination IPv4 addresses, 172.31.10.1/24 and 172.31.10.2/24 respectively, to SAP 1/1/c1/1:3. When SAP 1/1/c1/1:3 is operationally down, the default behavior is to drop the packet. Not every IPv4/v6 filter needs to have match criteria defined, but in this case, only packets with the configured IPv4 SA and IPv4 DA are affected, whereas the other packets are forwarded per the FDB in the "VPLS-3" service on PE-1.
configure {
filter {
ip-filter "IP-1" {
filter-id 1
entry 10 {
match {
src-ip {
address 172.31.10.1
mask 255.255.255.0
}
dst-ip {
address 172.31.10.2
mask 255.255.255.0
}
}
action {
forward {
sap {
vpls "VPLS-3"
sap-id 1/1/c1/1:3
}
}
}
}
In a similar way, an entry in a MAC filter can be configured with the following command:
[ex:/configure filter mac-filter "MAC-2" entry 10]
A:admin@PE-1# ?
action + Enable the action context
apply-groups - Apply a configuration group at this level
apply-groups-exclude - Exclude a configuration group at this level
description - Text description
log - Log that is used for packets matching this entry
match + Enter the match context
pbr-down-action- - Action when PBR or PBF target for this entry is not available
override
sticky-dest - Time before action with available PBR or PBF destination and highest
priority
The following MAC filter forwards all frames with source MAC SA 00:00:5e:00:53:01 to SAP 1/1/c1/1:3:
configure {
filter {
mac-filter "MAC-2" {
filter-id 2
entry 10 {
match {
src-mac {
address 00:00:5e:00:53:01
}
}
action {
forward {
sap {
vpls "VPLS-3"
sap-id 1/1/c1/1:3
}
}
}
}
Instead of defining a specific MAC address, a range of MAC addresses can be defined using a mask. The default mask is all 1s, ff:ff:ff:ff:ff:ff (not shown), which corresponds to an exact match of the configured MAC address.
When the primary SAP 1/1/c1/1:3 is down, the default action is drop. However, PBR/PBF redundancy can be configured, as described in the following section.
PBR/PBF redundancy
PBR/PBF redundancy is supported for MAC filters, IPv4 filters, and IPv6 filters. Within each entry in the IP/MAC filter, a secondary action can be configured; for example, for entry 10 in IPv4 filter "IP-1", as follows:
configure {
filter {
ip-filter "IP-1" {
filter-id 1
entry 10 {
match {
src-ip {
address 172.31.10.1
mask 255.255.255.0
}
dst-ip {
address 172.31.10.2
mask 255.255.255.0
}
}
action {
forward {
sap {
vpls "VPLS-3"
sap-id 1/1/c1/1:3
}
}
secondary {
forward {
sap {
vpls "VPLS-3"
sap-id 1/1/c2/1:3
}
}
}
}
}
The IPv4 filter is applied on the ingress of SAP 1/1/c3/1:3 in the "VPLS-3" service on PE-1. This IPv4 filter only affects packets with IPv4 SA 172.31.10.1/24 and IPv4 DA 172.31.10.2/24. When the primary action SAP 1/1/c1/1:3 is operationally up, the primary action is executed; when SAP 1/1/c1/1:3 is operationally down, the secondary action is executed, until SAP 1/1/c1/1:3 is operationally up again. When both SAPs are down, the default behavior is to drop the packet.
When the primary action SAP 1/1/c1/1:3 is operationally up (PBR Target Status: Up), the primary action is executed (Downloaded Action: Primary), as follows:
[/]
A:admin@PE-1# show filter ip "IP-1"
===============================================================================
IP Filter
===============================================================================
Filter Id : 1 Applied : Yes
Scope : Template Def. Action : Drop
Type : Normal
Shared Policer : Off
System filter : Unchained
Radius Ins Pt : n/a
CrCtl. Ins Pt : n/a
RadSh. Ins Pt : n/a
PccRl. Ins Pt : n/a
Entries : 1
Description : (Not Specified)
Filter Name : IP-1
-------------------------------------------------------------------------------
Filter Match Criteria : IP
-------------------------------------------------------------------------------
Entry : 10
Description : (Not Specified)
Log Id : n/a
Src. IP : 172.31.10.1/24
Src. Port : n/a
Dest. IP : 172.31.10.2/24
Dest. Port : n/a
Protocol : Undefined
Dscp : Undefined
ICMP Type : Undefined ICMP Code : Undefined
Fragment : Off Src Route Opt : Off
Sampling : Off Int. Sampling : On
IP-Option : 0/0 Multiple Option: Off
Tcp-flag : (Not Specified)
Option-pres : Off
Egress PBR : Disabled
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:3
Service Id : 3
PBR Target Status : Up
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:3
Service Id : 3
PBR Target Status : Up
PBR Down Action : Drop (entry-default)
Downloaded Action : Primary
Dest. Stickiness : None Hold Remain : 0
Ing. Matches : 205 pkts (21730 bytes)
Egr. Matches : 0 pkts
===============================================================================
When the primary action SAP 1/1/c1/1:3 is operationally down, the secondary action is executed. When SAP 1/1/c1/1:3 is down, packets are forwarded to secondary action SAP 1/1/c2/1:3 instead. However, when the primary action SAP 1/1/c1/1:3 is operationally up again, the primary action is executed. This revertive behavior can be disabled by configuring stickiness in the filter entry, as follows:
[ex:/configure filter ip-filter "IP-1" entry 10]
A:admin@PE-1# sticky-dest ?
sticky-dest (<number> | <keyword>)
<number> - <0..65535> - seconds
<keyword> - no-hold-time-up - seconds
Time before action with available PBR or PBF destination and highest priority
When both the primary action SAP 1/1/c1/1:3 and the secondary action SAP 1/1/c2/1:3 are down, the default action is drop, unless the pbr-down-action-override <filter-action> parameter is configured. When the configured filter action is forward, the packets can be forwarded to another object in the service that is up, for example, to another SAP or to an SDP binding, per the packet's destination address. This means that in a VPLS (PBF), the MAC DA is looked up in the FDB; in a VPRN (PBR), the IP DA is looked up in the routing table. The configuration of the pbr-down-action-override parameter is as follows. No specific SAPs or SDP bindings need to be defined.
[ex:/configure filter ip-filter "IP-1" entry 10]
A:admin@PE-1# pbr-down-action-override ?
pbr-down-action-override <keyword>
<keyword> - (drop|forward|filter-default-action)
Action when PBR or PBF target for this entry is not available
In the example, the filter "IP-1" contains two actions that both forward packets to a SAP, but the PBR/PBF target can also be an SDP binding or—for PBR—a next-hop IP address in a VPRN. Primary and secondary forwarding actions shows the allowed primary and secondary forwarding action combinations within a filter entry.
primary forwarding action |
secondary forwarding action |
---|---|
sap <sap-id> |
sap <sap-id> |
sap <sap-id> |
sdp <sdp-id:vc-id> |
sdp <sdp-id:vc-id> |
sdp <sdp-id:vc-id> |
sdp <sdp-id:vc-id> |
sap <sap-id> |
next-hop <ipv4/ipv6-address> router <router-instance> |
next-hop <ipv4-ipv6-address> router <router-instance> |
next-hop indirect <ipv4/ipv6-address> router <router-instance> |
next-hop indirect <ipv4/ipv6-address> router <router-instance> |
Configuration
In this section, the following examples are described:
Example topology shows the example topology with four PEs and two CEs.
The initial configuration is as follows:
Cards, MDAs, ports (all ports are in hybrid mode with dot1q encapsulation)
Router interfaces
IS-IS as IGP between the PEs (alternatively, OSPF could be configured as IGP)
LDP between the PEs
The CEs are emulated using a VPRN on PE-1 or PE-4 with a hairpin to loop the traffic back to the PE.
PBF in a VPLS using an IP filter
PBF in the "VPLS-1" service on PE-1 shows the example topology with the "VPLS-1" service configured on the four PEs. CE-11 is connected with the "VPLS-1" service on PE-1 and CE-14 with the "VPLS-1" service on PE-4. PBF is applied in the "VPLS-1" service on PE-1.
The configuration is shown for PE-1. The following cases are described in this section:
Initial situation: primary action is executed.
Primary action SAP 1/1/c1/1:1 is disabled. The secondary action in the entry in the IPv4 filter is executed.
Both primary and secondary action SAPs 1/1/c1/1:1 and 1/1/c2/1:1 are disabled. The default action is drop.
Both primary and secondary action SAPs 1/1/c1/1:1 and 1/1/c2/1:1 are disabled. The pbr-down-action-override parameter is configured with action forward.
The secondary action SAP 1/1/c2/1:1 is re-enabled. The secondary action is executed.
The primary action SAP 1/1/c1/1:1 is re-enabled. The primary action is executed.
Stickiness is configured with a hold timer of, for example, 120 seconds. At timer expiry, stickiness takes effect. If SAP 1/1/c1/1:1 is up at timer expiry, the primary action is programmed; otherwise, if SAP 1/1/c2/1:1 is up, the secondary action is programmed.
Stickiness is configured without a hold timer and takes effect immediately.
Configure the "VPLS-1" service with IPv4 filter on SAP ingress
IPv4 filter 10 has one entry with primary action to forward to SAP 1/1/c1/1:1 and secondary action to forward to SAP 1/1/c2/1:1. No match criteria are defined. When all action forward SAPs are operationally down, the default action is drop. No stickiness is configured.
# on PE-1:
configure {
filter {
ip-filter "IP-10" {
filter-id 10
entry 10 {
action {
forward {
sap {
vpls "VPLS-1"
sap-id 1/1/c1/1:1
}
}
secondary {
forward {
sap {
vpls "VPLS-1"
sap-id 1/1/c2/1:1
}
}
}
}
}
The "VPLS-1" service on PE-1 is configured with three SAPs and two spoke-SDPs, as follows. IPv4 filter "IP-10" is configured on the ingress of SAP 1/1/c3/1:1 and applies to traffic originating from CE-11.
configure {
service {
sdp 12 {
admin-state enable
delivery-type mpls
ldp true
far-end {
ip-address 192.0.2.2
}
}
sdp 13 {
admin-state enable
delivery-type mpls
ldp true
far-end {
ip-address 192.0.2.3
}
}
vpls "VPLS-1" {
admin-state enable
service-id 1
customer "1"
spoke-sdp 12:1 {
}
spoke-sdp 13:1 {
}
sap 1/1/c1/1:1 {
}
sap 1/1/c2/1:1 {
}
sap 1/1/c3/1:1 {
ingress {
filter {
ip "IP-10"
}
}
}
}
When all SAPs are up, all packets from CE-11 enter SAP 1/1/c3/1:1 and are forwarded to primary action SAP 1/1/c1/1:1. No other traffic is sent and the number of packets received or sent on port 1/1/c1/1 will only slightly exceed the number of packets sent on the SAP, because of signaling between the PEs for IS-IS and LDP. The port statistics are cleared for ports 1/1/c1/1 through 1/1/c3/1 on PE-1. CE-11 sends a series of ICMP echo requests and, afterward, the port statistics on PE-1 are verified.
[/]
A:admin@PE-1# ping 172.31.11.4 router-instance "CE-11" source-address 172.31.11.1
interval 0.01 count 200 output-format summary
PING 172.31.11.4 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!
---- 172.31.11.4 PING Statistics ----
200 packets transmitted, 200 packets received, 0.00% packet loss
round-trip min = 2.20ms, avg = 2.80ms, max = 11.1ms, stddev = 0.966ms
[/]
A:admin@PE-1# show port 1/1/c1/1 statistics
===============================================================================
Port Statistics on Slot 1
===============================================================================
Port Ingress Packets Ingress Octets
Id Egress Packets Egress Octets
-------------------------------------------------------------------------------
1/1/c1/1 203 21545
205 21743
===============================================================================
[/]
A:admin@PE-1# show port 1/1/c2/1 statistics
===============================================================================
Port Statistics on Slot 1
===============================================================================
Port Ingress Packets Ingress Octets
Id Egress Packets Egress Octets
-------------------------------------------------------------------------------
1/1/c2/1 3 315
1 129
===============================================================================
[/]
A:admin@PE-1# show port 1/1/c3/1 statistics
===============================================================================
Port Statistics on Slot 1
===============================================================================
Port Ingress Packets Ingress Octets
Id Egress Packets Egress Octets
-------------------------------------------------------------------------------
1/1/c3/1 200 21200
200 21200
===============================================================================
All traffic is forwarded from ingress SAP 1/1/c3/1:1 to SAP 1/1/c1/1:1 and the reply messages from SAP 1/1/c1/1:1 to SAP 1/1/c3/1:1. No packets are forwarded via SAP 1/1/c2/1:1.
When the primary action SAP 1/1/c1/1:1 is operationally up, the primary action is executed, as follows:
[/]
A:admin@PE-1# show filter ip "IP-10"
===============================================================================
IP Filter
===============================================================================
Filter Id : 10 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
-------------------------------------------------------------------------------
Filter Match Criteria : IP
-------------------------------------------------------------------------------
Entry : 10
---snip---
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Up
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Up
PBR Down Action : Drop (entry-default)
Downloaded Action : Primary
Dest. Stickiness : None Hold Remain : 0
Ing. Matches : 203 pkts (21518 bytes)
Egr. Matches : 0 pkts
===============================================================================
Primary action PBR target down
The primary action SAP 1/1/c1/1:1 is disabled. Therefore, the primary action cannot be executed, and the secondary action is executed instead. When CE-11 sends ICMP echo requests, all packets are forwarded to SAP 1/1/c2/1:1.
# Disable SAP 1/1/c1/1:1 in the "VPLS-1" service on PE-1:
configure {
service {
vpls "VPLS-1" {
sap 1/1/c1/1:1
admin-state disable
[/]
A:admin@PE-1# show filter ip "IP-10"
===============================================================================
IP Filter
===============================================================================
Filter Id : 10 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Entry : 10
---snip---
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Down
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Up
PBR Down Action : Drop (entry-default)
Downloaded Action : Secondary
Dest. Stickiness : None Hold Remain : 0
Ing. Matches : 403 pkts (42718 bytes)
Egr. Matches : 0 pkts
===============================================================================
Secondary action PBR target down
The secondary action SAP 1/1/c2/1:1 is disabled, as follows:
# Disable SAP 1/1/c2/1:1 in the "VPLS-1" service on PE-1:
configure {
service {
vpls "VPLS-1" {
sap 1/1/c2/1:1
admin-state disable
Both SAP 1/1/c1/1:1 and SAP 1/1/c2/1:1 are disabled. Neither the primary nor the secondary action in entry 10 of IPv4 filter 10 can be executed. Therefore, the default action is executed, which is drop; see the following output (PBR Down Action: Drop (entry-default)).
[/]
A:admin@PE-1# show filter ip "IP-10"
===============================================================================
IP Filter
===============================================================================
Filter Id : 10 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Entry : 10
---snip---
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Down
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Down
PBR Down Action : Drop (entry-default)
Downloaded Action : Primary
Dest. Stickiness : None Hold Remain : 0
Ing. Matches : 403 pkts (42718 bytes)
Egr. Matches : 0 pkts
===============================================================================
When CE-11 sends ICMP echo requests, they are all dropped.
[/]
A:admin@PE-1# ping 172.31.11.4 router-instance "CE-11" source-address 172.31.11.1
interval 0.01 count 50 output-format summary
PING 172.31.11.4 56 data bytes
..................................................
---- 172.31.11.4 PING Statistics ----
50 packets transmitted, 0 packets received, 100% packet loss
PBR down action override
Both SAPs remain disabled. The default PBR down action is drop, but that can be overruled by configuring the pbr-down-action-override parameter, as follows:
# on PE-1:
configure {
filter {
ip-filter "IP-10" {
entry 10 {
pbr-down-action-override forward
With this configuration added in entry 10 of the "IP-10" filter, the PBR down action will be forward. No specific next hop needs to be defined. The forwarding is based on the destination address. When CE-11 sends ICMP echo requests to CE-41, the traffic is forwarded, as follows:
[/]
A:admin@PE-1# ping 172.31.11.4 router-instance "CE-11" source-address 172.31.11.1
interval 0.01 count 200 output-format summary
PING 172.31.11.4 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
---snip---
---- 172.31.11.4 PING Statistics ----
200 packets transmitted, 200 packets received, 1 duplicate
round-trip min = 2.29ms, avg = 2.94ms, max = 12.0ms, stddev = 0.752ms
The statistics in the detailed output for spoke-SDP 12:1 in the "VPLS-1" service shows that these packets have been sent over this spoke-SDP. It is possible that spoke-SDP 13:1 in the "VPLS-1" service is used instead.
[/]
A:admin@PE-1# show service id 1 sdp 12:1 detail | match Statistics post-lines 5
Statistics :
I. Fwd. Pkts. : 203 I. Dro. Pkts. : 0
I. Fwd. Octs. : 19818 I. Dro. Octs. : 0
E. Fwd. Pkts. : 207 E. Fwd. Octets : 20020
-------------------------------------------------------------------------------
The PBR down action for entry 10 in IPv4 filter 10 is forward, as defined by the pbr-down-action-override parameter, and the PBR downloaded action is forward, as follows:
[/]
A:admin@PE-1# show filter ip "IP-10"
===============================================================================
IP Filter
===============================================================================
Filter Id : 10 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Entry : 10
---snip---
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Down
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Down
PBR Down Action : Forward (pbr-down-action-override)
Downloaded Action : Forward
Dest. Stickiness : None Hold Remain : 0
Ing. Matches : 653 pkts (69218 bytes)
Egr. Matches : 0 pkts
===============================================================================
Secondary action up - revertive behavior
The primary action SAP 1/1/c1/1:1 remains disabled, whereas secondary action SAP 1/1/c2/1:1 is re-enabled, as follows:
# on PE-1:
configure {
service {
vpls "VPLS-1" {
sap 1/1/c2/1:1 {
admin-state enable
The secondary action in entry 10 of IPv4 filter 10 is executed (Downloaded Action: Secondary), as follows:
[/]
A:admin@PE-1# show filter ip "IP-10"
===============================================================================
IP Filter
===============================================================================
Filter Id : 10 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Entry : 10
---snip---
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Down
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Up
PBR Down Action : Forward (pbr-down-action-override)
Downloaded Action : Secondary
Dest. Stickiness : None Hold Remain : 0
Ing. Matches : 853 pkts (90418 bytes)
Egr. Matches : 0 pkts
===============================================================================
Primary action up - revertive behavior
As well as the secondary action SAP, also the primary action SAP 1/1/c1/1:1 is re-enabled, as follows:
# on PE-1:
configure {
service {
vpls "VPLS-1" {
sap 1/1/c1/1:1 {
admin-state enable
The default PBR/PBF behavior is revertive; therefore, the primary action is executed: the packets are forwarded to SAP 1/1/c1/1:1, as follows:
[/]
A:admin@PE-1# show filter ip "IP-10"
===============================================================================
IP Filter
===============================================================================
Filter Id : 10 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Entry : 10
---snip---
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Up
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Up
PBR Down Action : Forward (pbr-down-action-override)
Downloaded Action : Primary
Dest. Stickiness : None Hold Remain : 0
Ing. Matches : 1053 pkts (111618 bytes)
Egr. Matches : 0 pkts
===============================================================================
Stickiness in IP filter with hold timer
When the primary action SAP becomes up, traffic will be forwarded to this SAP instantaneously, unless stickiness applies. Stickiness can be defined on the IPv4/v6 filter entry level to override this revertive behavior. The following command enables stickiness at timer expiry with a hold remain timer of—in this case—120 seconds for entry 10 in IPv4 filter 10:
# on PE-1:
configure {
filter {
ip-filter "IP-10" {
entry 10 {
sticky-dest 120
The hold remain timer starts counting down when stickiness is configured and at least one PBR target is up. If the primary action SAP 1/1/c1/1:1 remains operationally up for the configured 120 seconds, the primary action will be active, and at timer expiry, stickiness applies. However, if SAP 1/1/c1/1:1 goes down and then up again before timer expiry, the secondary action remains active until the hold remain timer expires, as shown in the following example.
The hold remain timer has not expired. The primary action SAP 1/1/c1/1:1 is disabled, so the secondary action is active, as follows. The hold remain timer keeps counting down.
# on PE-1:
configure exclusive
service {
vpls "VPLS-1" {
sap 1/1/c1/1:1 {
admin-state disable
[/]
A:admin@PE-1# show filter ip "IP-10"
===============================================================================
IP Filter
===============================================================================
Filter Id : 10 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Entry : 10
---snip---
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Down
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Up
PBR Down Action : Forward (pbr-down-action-override)
Downloaded Action : Secondary
Dest. Stickiness : 120 Hold Remain : 91
Ing. Matches : 1253 pkts (132818 bytes)
Egr. Matches : 0 pkts
===============================================================================
The primary action SAP 1/1/c1/1:1 is restored and the secondary action is active until the hold remain timer expires, as follows:
# on PE-1:
configure {
service {
vpls "VPLS-1" {
sap 1/1/c1/1:1 {
admin-state enable
[/]
A:admin@PE-1# show filter ip "IP-10"
===============================================================================
IP Filter
===============================================================================
Filter Id : 10 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Entry : 10
---snip---
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Up
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Up
PBR Down Action : Forward (pbr-down-action-override)
Downloaded Action : Secondary
Dest. Stickiness : 120 Hold Remain : 55
Ing. Matches : 1453 pkts (154018 bytes)
Egr. Matches : 0 pkts
===============================================================================
In the preceding output, the secondary action is active and the hold remain time is 55 seconds. When the hold remain timer expires and the primary action SAP 1/1/c1/1:1 is up, the primary action is activated again and stickiness applies from then onward, as follows:
[/]
A:admin@PE-1# show filter ip "IP-10"
===============================================================================
IP Filter
===============================================================================
Filter Id : 10 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Up
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Up
PBR Down Action : Forward (pbr-down-action-override)
Downloaded Action : Primary
Dest. Stickiness : 120 Hold Remain : 0
Ing. Matches : 1453 pkts (154018 bytes)
Egr. Matches : 0 pkts
===============================================================================
The hold remain timer stays at zero. When the primary action cannot be activated, the secondary action is activated and will remain activated even when the primary action SAP 1/1/c1/1:1 is up again. However, when the secondary action SAP 1/1/c2/1:1 is down, the primary action can be activated again.
The hold remain timer starts counting down when it is first configured, or reconfigured with a different value, and at least one of the PBR/PBF targets is up. The hold remain timer also starts counting down after both the primary and the secondary PBR/PBF targets have been down, for example, after a reboot, and at least one of them transitions to the up status. The secondary action might be available first, even though the primary action is preferred. This situation is automatically resolved when the timer expires: the primary action will be activated if available when the hold remain timer expires.
Force primary action
Stickiness can be enabled without any delay, as follows:
# on PE-1:
configure exclusive
filter {
ip-filter "IP-10" {
entry 10 {
sticky-dest no-hold-time-up
Initially, the primary action was executed, but when the primary action SAP 1/1/c1/1:1 is disabled, the secondary action is executed, as follows:
# on PE-1:
configure {
service {
vpls "VPLS-1" {
sap 1/1/c1/1:1
admin-state disable
[/]
A:admin@PE-1# show filter ip "IP-10"
===============================================================================
IP Filter
===============================================================================
Filter Id : 10 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Entry : 10
---snip---
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Down
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Up
PBR Down Action : Forward (pbr-down-action-override)
Downloaded Action : Secondary
Dest. Stickiness : 0 Hold Remain : 0
Ing. Matches : 1653 pkts (175218 bytes)
Egr. Matches : 0 pkts
===============================================================================
The secondary action is active and will remain active as long as the secondary action SAP 1/1/c2/1:1 is up. The hold remain timer is not enabled (== value 0). When the primary action SAP 1/1/c1/1:1 is operationally up again, the secondary action remains active, as follows:
# on PE-1:
configure {
service {
vpls "VPLS-1" {
sap 1/1/c1/1:1
admin-state enable
[/]
A:admin@PE-1# show filter ip "IP-10"
===============================================================================
IP Filter
===============================================================================
Filter Id : 10 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Entry : 10
---snip---
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Up
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Up
PBR Down Action : Forward (pbr-down-action-override)
Downloaded Action : Secondary
Dest. Stickiness : 0 Hold Remain : 0
Ing. Matches : 1853 pkts (196418 bytes)
Egr. Matches : 0 pkts
===============================================================================
The following tools command forces activation of the primary action in entry 10 of the "IP-10" filter:
[/]
A:admin@PE-1# tools perform filter ip-filter 10 entry 10 activate-primary-action
The result is that the primary action is executed again, as shown in the following output:
[/]
A:admin@PE-1# show filter ip "IP-10"
===============================================================================
IP Filter
===============================================================================
Filter Id : 10 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Entry : 10
---ping---
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Up
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Up
PBR Down Action : Forward (pbr-down-action-override)
Downloaded Action : Primary
Dest. Stickiness : 0 Hold Remain : 0
Ing. Matches : 2053 pkts (217618 bytes)
Egr. Matches : 0 pkts
===============================================================================
This tools command can also be used in combination with a running sticky-destination hold remain timer. In that case, the hold remain timer will stop counting down and the primary action immediately reverts.
PBF in a VPLS using a MAC filter
PBF in a VPLS can use a MAC filter instead of an IPv4 filter, but not both. The following MAC filter is defined on PE-1:
configure exclusive
filter {
mac-filter "MAC-20" {
filter-id 20
entry 10 {
pbr-down-action-override forward
sticky-dest no-hold-time-up
match {
src-mac {
address 00:00:5e:00:53:11
}
}
action {
forward {
sap {
vpls "VPLS-1"
sap-id 1/1/c1/1:1
}
}
secondary {
forward {
sap {
vpls "VPLS-1"
sap-id 1/1/c2/1:1
}
}
}
}
}
MAC filter "MAC-20" cannot be applied next to IPv4 filter "IP-10" on the ingress direction of SAP 1/1/c3/1:1 in the "VPLS-1" service; therefore, an error message is raised, as follows:
[ex:/configure service vpls "VPLS-1" sap 1/1/c3/1:1 ingress filter]
A:admin@PE-1# mac "MAC-20"
*[ex:/configure service vpls "VPLS-1" sap 1/1/c3/1:1 ingress filter]
A:admin@PE-1# info
mac "MAC-20"
ip "IP-10"
*[ex:/configure service vpls "VPLS-1" sap 1/1/c3/1:1 ingress filter]
A:admin@PE-1# commit
MINOR: SVCMGR #12: configure service vpls "VPLS-1" sap 1/1/c3/1:1 ingress filter mac
- Inconsistent Value error - another filter is already configured
The filter that was applied must be removed first, then the MAC filter can be applied, as follows:
# on PE-1:
configure {
service {
vpls "VPLS-1" {
sap 1/1/c3/1:1 {
ingress {
delete filter # remove filter
filter {
mac "MAC-20"
}
When all SAPs in the "VPLS-1" service are up, the primary action is activated, as follows:
[/]
A:admin@PE-1# show filter mac "MAC-20"
===============================================================================
Mac Filter
===============================================================================
Filter Id : 20 Applied : Yes
Scope : Template Def. Action : Drop
Entries : 1 Type : normal
Description : (Not Specified)
Filter Name : MAC-20
-------------------------------------------------------------------------------
Filter Match Criteria : Mac
-------------------------------------------------------------------------------
Entry : 10 FrameType : Ethernet
Description : (Not Specified)
Log Id : n/a
Src Mac : 00:00:5e:00:53:11 ff:ff:ff:ff:ff:ff
Dest Mac : Undefined
Dot1p : Undefined Ethertype : Undefined
DSAP : Undefined SSAP : Undefined
Snap-pid : Undefined ESnap-oui-zero : Undefined
Primary Action : Forward (SAP)
Next Hop : 1/1/c1/1:1
Service Id : 1
PBR Target Status : Up
Secondary Action : Forward (SAP)
Next Hop : 1/1/c2/1:1
Service Id : 1
PBR Target Status : Up
PBR Down Action : Forward (pbr-down-action-override)
Downloaded Action : Primary
Dest. Stickiness : 0 Hold Remain : 0
Ing. Matches : 200 pkts (21200 bytes)
Egr. Matches : 0 pkts
===============================================================================
PBR in a VPRN using an IP filter
PBR in a VPRN shows the example topology used with the "VPRN-2" service configured on each PE and the CEs configured as another VPRN service on PE-1 and PE-4.
The following IPv4 filter is configured on PE-1:
configure {
filter {
ip-filter "IP-30" {
filter-id 30
entry 10 {
action {
forward {
next-hop {
nh-ip-vrf {
router-instance "VPRN-2"
address 172.16.12.2
}
}
}
secondary {
forward {
next-hop {
nh-ip-vrf {
router-instance "VPRN-2"
address 172.16.13.2
}
}
}
}
}
}
The "VPRN-2" service in PE-1 has the "IP-30" filter applied to SAP 1/1/c3/1:2 toward CE-12:
configure {
service {
vprn "VPRN-2" {
admin-state enable
service-id 2
customer "1"
bgp-ipvpn {
mpls {
admin-state enable
route-distinguisher "64496:2"
}
}
interface "int-VPRN-2-PE-1-CE-12" {
ipv4 {
primary {
address 172.31.12.1
prefix-length 24
}
}
sap 1/1/c3/1:2 {
ingress {
filter {
ip "IP-30"
}
}
}
}
interface "int-VPRN-2-PE-1-PE-2" {
ipv4 {
primary {
address 172.16.12.1
prefix-length 30
}
}
sap 1/1/c1/1:2 {
}
}
interface "int-VPRN-2-PE-1-PE-3" {
ipv4 {
primary {
address 172.16.13.1
prefix-length 30
}
}
sap 1/1/c2/1:2 {
}
}
}
The configuration of the "VPRN-2" service on the remaining PEs is similar, except that static route entries are configured for subnets 172.31.12.0/24 (toward CE-12) and 172.31.42.0/24 (toward CE-42). No filters are applied to the "VPRN-2" service on the other nodes.
The primary action forwards packets from CE-12 to next-hop 172.16.12.2, which is an interface in the "VPRN-2" service on PE-2; the secondary action forwards to next-hop 172.16.13.2, an interface in the "VPRN-2" service on PE-3. When all interfaces are up, the primary action is executed and traffic from CE-12 to CE-42 is forwarded from the "VPRN-2" router on PE-1 to the "VPRN-2" router on PE-2 (next hop 172.16.12.2), as follows:
[/]
A:admin@PE-1# show filter ip "IP-30"
===============================================================================
IP Filter
===============================================================================
Filter Id : 30 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Primary Action : Forward (Next Hop VRF)
Next Hop : 172.16.12.2
Router : 2
PBR Target Status : Up
Extended Action : None # optional DSCP remarking for PBR
Secondary Action : Forward (Next Hop VRF)
Next Hop : 172.16.13.2
Router : 2
PBR Target Status : Up
Extended Action : None
PBR Down Action : Drop (entry-default)
Downloaded Action : Primary
Dest. Stickiness : None Hold Remain : 0
Ing. Matches : 201 pkts (21306 bytes)
Egr. Matches : 0 pkts
===============================================================================
The output includes an additional line per action: both the primary and the secondary action in PBR can have DSCP remarking as extended action, but that is not configured in this example. It can be configured using the following command; for example, for the primary action, as follows:
*[ex:/configure filter ip-filter "IP-30" entry 10 action remark]
A:admin@PE-1# dscp ?
dscp <keyword>
<keyword> - (be|cp1|cp2|cp3|cp4|cp5|cp6|cp7|cs1|cp9|af11|cp11|af12|cp13|af13|cp15|cs2|cp17|af21|cp19|af22|
cp21|af23|cp23|cs3|cp25|af31|cp27|af32|cp29|af33|cp31|cs4|cp33|af41|cp35|af42|cp37|af43|cp39|
cs5|cp41|cp42|cp43|cp44|cp45|ef|cp47|nc1|cp49|cp50|cp51|cp52|cp53|cp54|cp55|nc2|cp57|cp58|
cp59|cp60|cp61|cp62|cp63)
'dscp' is: mandatory
Destination SAP
When the primary action cannot be activated, the secondary action is activated, as follows:
# on PE-1:
configure {
service {
vprn "VPRN-2" {
interface "int-VPRN-2-PE-1-PE-2" {
sap 1/1/c1/1:2 {
admin-state disable
*A:PE-1# show filter ip "IP-30"
===============================================================================
IP Filter
===============================================================================
Filter Id : 30 Applied : Yes
Scope : Template Def. Action : Drop
---snip---
Entry : 10
---snip---
Primary Action : Forward (Next Hop VRF)
Next Hop : 172.16.12.2
Router : 2
PBR Target Status : Down
Extended Action : None
Secondary Action : Forward (Next Hop VRF)
Next Hop : 172.16.13.2
Router : 2
PBR Target Status : Up
Extended Action : None
PBR Down Action : Drop (entry-default)
Downloaded Action : Secondary
Dest. Stickiness : None Hold Remain : 0
Ing. Matches : 201 pkts (21306 bytes)
Egr. Matches : 0 pkts
===============================================================================
When both PBR targets are down, the default action is drop, because the IPv4 filter does not have the pbr-down-action-override parameter configured. Stickiness is not enabled in this filter. The configuration of the IPv4/v6 filters is similar for PBR and PBF.
In the preceding PBR example, the primary and secondary next-hop router is the same VRF "VPRN-2", but it can be any mix of VRFs, such as primary next-hop router 100 and secondary next-hop router 200.
PBR can also steer traffic to the base routing instance; for example, with the following IP filter:
configure {
filter {
ip-filter "IP-40" {
filter-id 40
entry 10 {
action {
forward {
next-hop {
nh-ip-vrf {
router-instance "Base"
address 192.0.2.2
}
}
}
secondary {
forward {
next-hop {
nh-ip-vrf {
router-instance "Base"
address 192.0.2.3
}
}
}
}
}
}
Conclusion
Operators can define two targets for L2 and L3 traffic steering (PBF and PBR): primary and secondary. The primary target is used when both targets are up; the secondary target is used when the primary is down. However, when stickiness is enabled, it is possible that the secondary action is executed, even when the primary action PBR target reverts to up. When both targets are down, the default action is drop, unless the pbr-down-action-override parameter is configured. Both 1+1 redundancy and N+1 redundancy are supported.