This article describes how to deny advertising BGP routes with a next hop that does not belong to the tunnel itself
The concept is to avoid routing traffic over the wrong tunnel.
Each hub and spoke is using two internet circuits consisting of 2 Overlays configured in the below scenario.
Naming Convention used on HUB:
ADVPN1 referred as IPSEC
ADVPN2 referred as IPSEC1
Naming Convention used on Spoke1:
IPSEC1 -Primary Tunnel
IPSEC2 -Secondary Tunnel
Naming Convention used on Spoke2:
IPSEC1 -Primary Tunnel
IPSEC2 -Secondary Tunnel
for example, in this Case: ADVPN-1 overlay subnet is 10.10.1.0/24, and wanted to advertise routes over ADVPN-1 tunnel with next hops in the same subnet only 10.10.1.0/24.
The IPSEC overlay is using the 10.10.1.0/24 subnet and the IPSEC1 overlay is using the Subnet 10.10.2.0/24.
Two routes will be put in the routing table using the commands ibgp-multipath enable and additional-path enable under the config router BGP on the hub and spokes, and using the command additional-path both, both routes will also be broadcast.
To be more specific hub should have additional-path sent and spokes should have additional-path receive
Now Suppose the Subnet 14.0.0.0/24 Behind the Spoke 1 wants to talk to 15.0.0.0/24 behind the Spoke 2, When examining the spoke1's routing table, could observe that two copies are being received as shown below.
Upon checking from the spoke2 and attempt to see the subnet 14.0.0.0/24 that is behind the spoke1, the same thing will occur, and this will result in problems.
SPOKE1 # get router info routing-table details 15.0.0.1
Routing table for VRF=0
Routing entry for 15.0.0.0/24
Known via "bgp", distance 200, metric 0, best
Last update 00:03:39 ago
* vrf 0 10.10.1.4 priority 1 (recursive via IPSEC1 tunnel 192.168.55.2)
* vrf 0 10.10.2.4 priority 1 (recursive via IPSEC2 tunnel 192.168.45.2)
* vrf 0 10.10.1.4 priority 1 (recursive via IPSEC1 tunnel 192.168.55.2)
* vrf 0 10.10.2.4 priority 1 (recursive via IPSEC2 tunnel 192.168.45.2)
SPOKE2 # get router info routing-table details 14.0.0.1
Routing table for VRF=0
Routing entry for 14.0.0.0/24
Known via "bgp", distance 200, metric 0, best
Last update 00:04:27 ago
* vrf 0 10.10.1.3 priority 1 (recursive via IPSEC1 tunnel 192.168.55.2)
* vrf 0 10.10.2.3 priority 1 (recursive via IPSEC2 tunnel 192.168.45.2)
* vrf 0 10.10.1.3 priority 1 (recursive via IPSEC1 tunnel 192.168.55.2)
* vrf 0 10.10.2.3 priority 1 (recursive via IPSEC2 tunnel 192.168.45.2)
HUB Routing table for Both the Subnets:
HUB # get router info routing-table details 14.0.0.1
Routing table for VRF=0
Routing entry for 14.0.0.0/24
Known via "bgp", distance 200, metric 0, best
Last update 00:00:05 ago
* vrf 0 10.10.1.3 priority 1 (recursive is directly connected, IPSEC)
* vrf 0 10.10.2.3 priority 1 (recursive is directly connected, IPSEC2)
HUB # get router info routing-table details 15.0.0.1
Routing table for VRF=0
Routing entry for 15.0.0.0/24
Known via "bgp", distance 200, metric 0, best
Last update 00:00:26 ago
* vrf 0 10.10.1.4 priority 1 (recursive is directly connected, IPSEC)
* vrf 0 10.10.2.4 priority 1 (recursive is directly connected, IPSEC2)
On the HUB Side:
In order to prevent advertising ADVPN1 routes onto ADVPN2 and ADVPN2 routes onto ADVPN1 using 2 Overlays, the best way is to make use of the Prefix list and create the route map to deny one subnet not to advertise it to others and vice versa as below and apply that in the respective Groups with the route-map.
HUB # show router prefix-list
config router prefix-list
edit "IPSEC"
config rule
edit 1
set prefix 10.10.1.0 255.255.255.0
unset ge
set le 32
next
end
next
edit "IPSEC1"
config rule
edit 1
set prefix 10.10.2.0 255.255.255.0
unset ge
set le 32
next
end
next
end
HUB # show router route-map
config router route-map
edit "IPSEC"
config rule
edit 1
set action deny
set match-ip-nexthop "IPSEC1"
next
edit 2
next
end
next
edit "IPSEC1"
config rule
edit 1
set action deny
set match-ip-nexthop "IPSEC"
next
edit 2
next
end
next
end
HUB #
HUB (bgp) # show
config router bgp
set as 65400
set ibgp-multipath enable
set additional-path enable
config neighbor
edit "10.10.1.3"
set advertisement-interval 1
set link-down-failover enable
set soft-reconfiguration enable
set remote-as 65400
set route-map-out "IPSEC"
set additional-path both
set route-reflector-client enable
next
edit "10.10.1.4"
set advertisement-interval 1
set link-down-failover enable
set soft-reconfiguration enable
set remote-as 65400
set route-map-out "IPSEC"
set additional-path both
next
edit "10.10.2.3"
set advertisement-interval 1
set link-down-failover enable
set soft-reconfiguration enable
set remote-as 65400
set route-map-out "IPSEC1"
set additional-path both
set route-reflector-client enable
next
edit "10.10.2.4"
set advertisement-interval 1
set link-down-failover enable
set soft-reconfiguration enable
set remote-as 65400
set route-map-out "IPSEC1"
set additional-path both
next
end
config network
edit 1
set prefix 12.0.0.0 255.255.255.0
next
edit 2
set prefix 11.0.0.0 255.255.255.0
next
end
config network6
edit 1
set prefix6 ::/128
next
end
config redistribute "connected"
end
config redistribute "rip"
end
config redistribute "ospf"
end
config redistribute "static"
end
config redistribute "isis"
end
config redistribute6 "connected"
end
config redistribute6 "rip"
end
config redistribute6 "ospf"
end
config redistribute6 "static"
end
config redistribute6 "isis"
end
end
After making the above changes on the HUB Side, one Copy is visible on the Spoke1 and spoke2 as below:
SPOKE1 # get router info routing-table details 15.0.0.1
Routing table for VRF=0
Routing entry for 15.0.0.0/24
Known via "bgp", distance 200, metric 0, best
Last update 01:26:33 ago
* vrf 0 10.10.1.4 priority 1 (recursive via IPSEC1 tunnel 192.168.55.2)
* vrf 0 10.10.2.4 priority 1 (recursive via IPSEC2 tunnel 192.168.45.2)
SPOKE2 # get router info routing-table details 14.0.0.1
Routing table for VRF=0
Routing entry for 14.0.0.0/24
Known via "bgp", distance 200, metric 0, best
Last update 01:27:22 ago
* vrf 0 10.10.1.3 priority 1 (recursive via IPSEC1 tunnel 192.168.55.2)
* vrf 0 10.10.2.3 priority 1 (recursive via IPSEC2 tunnel 192.168.45.2)
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.