Examples of configuring BGP sessions using hardware from various manufacturers
April 17, 2024
ID 205378
See the topology below:
Example topology
The Customer has two PI networks:
- 8.8.8.0/24
- 8.8.9.0/24
Only one of these will be protected: 8.8.8.0/24.
The second network must always be routed directly through the ISP.
The Customer uses two routers for fault-tolerant connections to two ISPs.
The customer receives Full View from both ISPs and announces the prefix /24 to both of them.
Tunnels with a full mesh topology were created for a fault-tolerant connection to Kaspersky DDoS Protection. A full mesh topology in this case means that there is a tunnel from each of the Customer's routers to two Kaspersky DDoS Protection sites.
Dynamic routing must be organized to ensure the following:
- Traffic of network 8.8.8.0/24 is symmetrically routed through Kaspersky DDoS Protection.
- Traffic of other networks is not affected.
- The priority route for outbound traffic from the network 8.8.8.0/24 is selected based on the BGP MED attribute (commonly known as the BGP metric).
Cisco equipment
BDR1:
interface GigabitEthernet0/0
description CORE
ip address 192.168.1.1 255.255.255.0
interface GigabitEthernet0/1
description BDR2-iBGP
ip address 10.100.1.1 255.255.255.252
interface Tunnel1
description KDP1
ip address 10.42.10.2 255.255.255.252
interface Tunnel2
description KDP2
ip address 10.42.10.6 255.255.255.252
(the terminal points of tunnels are omitted here because they are irrelevant in this example)
BGP router:
Customer AS: 10000
AS Kaspersky DDoS Protection: 209030
We receive from Kaspersky DDoS Protection: 5.5.5.5/32 (the purpose of receiving this announcement is described in the Policy-Based Routing section)
We announce to Kaspersky DDoS Protection: 8.8.8.0/24
router bgp 10000
no synchronization
bgp deterministic-med
network 8.8.8.0 mask 255.255.255.0
network 8.8.9.0 mask 255.255.255.0
neighbor 10.42.10.1 remote-as 209030 # KDP1
neighbor 10.42.10.1 route-map KDP-OUT out
neighbor 10.42.10.1 route-map KDP-IN in
neighbor 10.42.10.5 remote-as 209030 # KDP2
neighbor 10.42.10.5 route-map KDP-OUT out
neighbor 10.42.10.5 route-map KDP-IN in
neighbor 10.100.1.2 remote-as 10000 # iBGP with BDR2
Configure the filters:
ip prefix-list PL-KDP-IN seq 10 permit 5.5.5.5/32
ip prefix-list PL-PROTECTED seq 10 permit 8.8.8.0/24
route-map KDP-IN permit 10
match ip address prefix-list PL-KDP-IN
route-map KDP-OUT permit 10
match ip address prefix-list PL-PROTECTED
Policy-Based Routing (PBR)
By applying PBR, we simultaneously accomplish multiple tasks:
- Change the route for one network only.
- Apply it regardless of the presence of specific prefixes for the entire Internet (Full View) in the routing table.
ip access-list standard KDP-PBR
permit 8.8.8.0 0.0.0.255
# the "standard" access-list is always applied to source addresses.
route-map KDP-PBR permit 10
match ip address KDP-PBR
set ip next-hop recursive 5.5.5.5
# 5.5.5.5/32 – prefix that is announced via BGP from Kaspersky DDoS Protection. The "recursive" directive shows that this next-hop is not on the connected network.
# A route to 5.5.5.5/32 will be recursively found and selected as the real next-hop. In other words, this is one of the "ends" of GRE tunnels from Kaspersky DDoS Protection.
# The PBR policy is applied to the interface that "sees" within the network, and the traffic to be routed on this interface is inbound
# (outbound from Protected servers):
interface GigabitEthernet0/0
description CORE
ip policy route-map KDP-PBR
Juniper equipment
BDR1:
interfaces {
ge-0/0 {
description CORE;
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
ge-0/1 {
description BDR2-iBGP;
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
gr-0/2 {
unit 0 {
description KDP1;
tunnel {
source x.x.x.x;
destination y.y.y.y;
}
family inet {
address 10.42.10.2/30;
}
}
unit 1 {
description KDP2;
tunnel {
source x.x.x.x;
destination y.y.y.y;
}
family inet {
address 10.42.10.6/30;
}
}
}
(the terminal points of tunnels are omitted here because they are irrelevant in this example)
BGP router:
Customer AS: 10000
AS Kaspersky DDoS Protection: 209030
We receive from Kaspersky DDoS Protection: 5.5.5.5/32
We announce to Kaspersky DDoS Protection: 8.8.8.0/24
protocols {
bgp {
group KDP {
type external;
import KDP-IN;
export KDP-OUT;
peer-as 209030;
neighbor 10.42.10.1 {
description KDP-1;
}
neighbor 10.42.10.5 {
description KDP-1;
}
family inet {
unicast {
rib-group RIB-KDP;
/* Import routes to an alternative table. More details are provided in the FBF section*/
}
}
}
group iBGP {
type internal;
peer-as 10000;
neighbor 10.100.1.2 {
description iBGP with BDR2;
}
}
}
}
Configure the filters:
policy-options {
prefix-list PL-KDP-IN {
5.5.5.5/32;
}
prefix-list PL-PROTECTED {
8.8.8.0/24;
}
policy-statement KDP-IN {
term ACCEPT {
from {
prefix-list PL-KDP-IN;
}
then {
accept;
}
then reject;
}
policy-statement KDP-OUT {
term ACCEPT {
from {
prefix-list PL-PROTECTED;
}
then {
accept;
}
then reject;
}
}
Policy-Based Routing (PBR)
Policy-Based Routing (PBR) in Cisco terminology is equivalent to Filter-Based Forwarding (FBF) in Juniper terminology.
By applying PBR, we simultaneously accomplish multiple tasks:
- Change the route for one network only.
- Apply it regardless of the presence of specific prefixes for the entire Internet (Full View) in the routing table.
Create an alternative routing table. Add to it a default route pointing to the IP address 5.5.5.5. The route to this IP address was previously relayed from the Scrubbing Center via established BGP sessions.
routing-instances {
RIB-KDP {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 5.5.5.5 resolve;
}
}
}
}
Import connected routes; policy for importing from BGP.
routing-options {
rib-groups {
FBF-GROUP {
import-rib [ inet.0 RIB-KDP.inet.0];
import-policy KDP-IN;
}
interface-routes {
rib-group inet FBF-GROUP;
}
}
Firewall rules:
firewall {
family inet {
filter KDP-FBF {
term FBF {
from {
source-prefix-list {
PL-PROTECTED;
}
}
then {
routing-instance RIB-KDP;
}
then accept;
}
}
}
}
The PBR policy is applied to the interface that "sees" within the network. The traffic arriving at this interface is inbound traffic. From the perspective of the Protected resources, this traffic is outbound. Perform the necessary configuration:
interfaces {
ge-0/0 {
unit 0 {
description CORE;
family inet {
filter input KDP-FBF;
}
}
}
}
