Examples of configuring BGP sessions using hardware from various manufacturers

April 17, 2024

ID 206484

See the topology below:

примеры_настройки_bgp_сессий_2

Example topology

IP addresses requiring protection:

  • 8.8.8.10
  • 8.8.8.11

To protect these resources, Kaspersky DDoS Protection allocates IP addresses from its own address space to the Customer.

IP addresses of Protected resources

Original IP address of the Protected resource

IP address issued for Kaspersky DDoS Protection

8.8.8.10

82.202.190.100

8.8.8.11

82.202.190.101

Allocated IP addresses must be assigned to Protected resources as additional IP addresses.

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.

For this purpose, dynamic routing must be organized to ensure the following:

  • Traffic from 82.202.190.x IP addresses is symmetrically routed through Kaspersky DDoS Protection.
  • Traffic for 82.202.190.x IP addresses is delivered to the appropriate servers.
  • The priority route for outbound traffic from the IP addresses 82.202.190.x 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: 65000
AS Kaspersky DDoS Protection: 200107
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
82.202.190.100/32
82.202.190.101/32

router bgp 65000

no synchronization

bgp deterministic-med

network 82.202.190.100 mask 255.255.255.255

network 82.202.190.101 mask 255.255.255.255

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 65000 # 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 82.202.190.100

ip prefix-list PL-PROTECTED seq 20 permit 82.202.190.101

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 only for specific (protected) IP addresses to maintain symmetry in the tunnel.
  • Apply it regardless of the presence of more specific routes in the routing table.

    ip access-list standard KDP-PBR

    permit host 82.202.190.100

    permit host 82.202.190.101

# 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

Traffic addressed to Protected IP addresses is delivered to servers via static routes:

ip route 82.202.190.100 255.255.255.255 8.8.8.10

ip route 82.202.190.101 255.255.255.255 8.8.8.11

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: 65000, AS Kaspersky DDoS Protection: 200107
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:
82.202.190.100
82.202.190.101

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 below in the FBF section*/

}

}

}

group iBGP {

type internal;

peer-as 65000;

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 {

82.202.190.100/32;

82.202.190.101/32;

}

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 only for specific (protected) IP addresses to maintain symmetry in the tunnel.
  • Apply it regardless of the presence of more specific routes 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 indicated route is in turn announced via BGP from Kaspersky DDoS Protection.

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, and the traffic to be routed on this interface is inbound (outbound from the Protected servers):

interfaces {

ge-0/0 {

unit 0 {

description CORE;

family inet {

filter input KDP-FBF;

}

}

}

}

Traffic addressed to Protected IP addresses is delivered to servers via static routes:

routing-options {

static {

route 82.202.190.100/32 next-hop 8.8.8.10;

route 82.202.190.101/32 next-hop 8.8.8.11;

}

}

Did you find this article helpful?
What can we do better?
Thank you for your feedback! You're helping us improve.
Thank you for your feedback! You're helping us improve.