Implementation of MPLS and VPN technologies on a network allows for creating a flexible scheme for a controlled rerouting of traffic towards Layer7, URL filtering nodes. The filtering nodes can be integrated into a geographically distributed network of an ISP, a DDoS mitigation provider, or (depends on the characteristics of network topology) a centralized filtering system can be implemented.

The figure below shows a scheme of a typical filtering node:

In the figure, without the L7 filtering mechanism the incoming traffic from WAN goes through forwarding tables default.inet.0 towards Layer 3 and Layer 4 filtering equipment. Clean traffic is routed towards Client network via vrf protected.

In order to reroute traffic towards the L7 filtering, a new routing-instances proxy with RD 65000:200 is created, where routing information is distributed among all routers within a network. Apart from AFI inet-vpn-unicast, AFI inet-vpn-flow in MP-BGP is included into iBGP, which allows to transmit the FlowSpec information into the corresponding vrf.

PE-1> show bgp neighbor 192.168.1.2 | match "NLRI for this session: |Table|Received prefixes:| Accepted prefixes:"
NLRI for this session: inet-unicast inet-vpn-unicast l2vpn inet6-labeled-unicast inet-vpn-flow

Table proxy.inet.0 Bit: b0000
Received prefixes: 4
Accepted prefixes: 4
Table protected.inetflow.0 Bit: c0000
Received prefixes: 1
Accepted prefixes: 1

The configuration of routing-instances proxy is below:

PE-1>show configuration routing-instances proxy
instance-type vrf;
interface ae0.800;
interface ae0.801;
interface ae0.924;
route-distinguisher 65000:200;
vrf-target {
import target:65000:200;
export target:65000:200;
}
vrf-table-label;
routing-options {
static {
route 0.0.0.0/0 {
next-table protected.inet.0;
preference 200;
}
}
flow {
term-order standard;
}
}
protocols {
bgp {
import default-proxy;
export reject-all;
group Redirect {
type external;
passive;
peer-as 65501;
multipath;
neighbor 10.0.2.202 {
local-address 10.0.2.201;
}
neighbor 10.0.2.206 {
local-address 10.0.2.205;
}
}
}
}

Two neighbors devices of the Layer7 filtering are specified in the  BGP routing-instances proxy configuration, for ensuring redundancy of a single node.

The traffic rerouting towards the L7 filtering is carried out as follows:

From Control Server that has an enabled eBGP session with family inet flow inside routing-instances protected, a route with corresponding attributes for traffic rerouting from routing-instances protected into routing-instances proxy is advertised via FlowSpec. Example:

192.168.200.1*,proto=6,dstport=80,dscp=48/term:1
*[BGP/170] 4d 19:59:37, localpref 100, from 10.22.2.2
AS path: 65501 I, validation-state: unverified
Fictitious

This advertisement is distributed among all routers of the network through inet-vpn-flow.

The router's BGP configuration for FlowSpec incorporated with Control Server is listed below:

PE-1> show configuration routing-instances protected protocols bgp group Servers neighbor 10.22.2.2
description "Proxy FlowSpec";
passive;
import Import_proxy_flowspec;
family inet {
flow {
prefix-limit {
maximum 200;
teardown;
}
no-validate Redirect-to-proxy;
}
}
export reject-all;
peer-as 65501;

The no-validate parameter allows the FlowSpec routes to be active without validation of the advertisements in inet.0. Applied to neighbor policy implements match over the transmitted FlowSpec community and redirects traffic into routing-instances proxy. An example of policy and community configuration is below:

PE-1> show configuration policy-options policy-statement Redirect-to-proxy
term 1 {
from community redirect;
to instance proxy;
then accept;
}
term 2 {
then accept;
}
{master}
PE-1> show configuration policy-options community redirect
members redirect:65000:200;
{master}

Not a positive feature is the overall forwarding to all instances participating in the FlowSpec, which leads to permanent cyclical forwarding of packets between instances where they "die" because of ТТL. A solution to this problem became an approach of labeling the traffic with dscp markers upon leaving the Layer3,4 filtering devices, and further discard of the markers upon leaving vrf proxy. This solution is implemented by using the Interface-Specific firewall filters and by advertising match dscp in the FlowSpec, matching the dscp labeling of the output of the Layer3,4 filtering devices. Examples of both filters are given below:

PE-1> show configuration firewall filter mark_dscp_proxy
term 1 {
from {
protocol tcp;
destination-port [ 80 483 ];
}
then {
accept;
dscp cs6;
}
}
term 2 {
then accept;
}

PE-1> show configuration firewall filter clear_dscp
term 1 {
from {
protocol tcp;
destination-port [ 80 483 ];
}
then {
accept;
dscp cs0;
}
}
term 2 {
then accept;
}
{master}
 

In order to route traffic to the Layer7, a BGP session is established with each filter. In this session, all the filters advertise 0.0.0.0/0 route, which is anycast and the main route in the table:

PE-2> show route table proxy.inet.0 0/0 exact
roxy.inet.0: 6 destinations, 9 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 5d 20:56:48, localpref 100, from 192.168.1.4
AS path: 65501 I, validation-state: unverified
> to 10.10.48.1 via ae0.1062, label-switched-path PRIORITY-PE2-PE4
to 10.10.48.1 via ae0.1062, label-switched-path BE-PE2-PE4
to 10.10.68.1 via ae0.1064, label-switched-path PRIORITY-PE2-PE4
[BGP/170] 5d 21:01:12, localpref 100, from 192.168.1.3
AS path: 65501 I, validation-state: unverified
> to 10.10.48.1 via ae0.1062, label-switched-path PRIORITY-PE2-PE3
to 10.10.48.1 via ae0.1062, label-switched-path BE-PE2-PE3
to 10.10.68.1 via ae0.1064, label-switched-path PRIORITY-PE2-PE3
[BGP/170] 5d 21:32:11, localpref 100, from 192.168.1.1
AS path: 65501 I, validation-state: unverified
> to 10.10.68.1 via ae0.1064, label-switched-path PRIORITY-PE2-PE1
to 10.10.48.1 via ae0.1062, label-switched-path PRIORITY-PE2-PE1-1
to 10.10.68.1 via ae0.1064, label-switched-path BE-PE2-PE1
to 10.10.48.1 via ae0.1062, label-switched-path PRIORITY-PE2-PE1
to 10.10.68.1 via ae0.1064, label-switched-path PRIORITY-PE2-PE1-1
[Static/200] 5d 20:54:19
to table protected.inet.0

Inside of this vrf is a static route 0.0.0.0/0 with a higher preference of 200, and with next-table protected.inet.0, which acts as a bypass route in the event of any problems occurred at the Layer7 filtering devices.

Back