Description
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.
Scope
Each hub and spoke is using two internet circuits consisting of 2 Overlays configured in the scenario below.
Naming Convention used on HUB:
ADVPN1 is referred to as IPSEC.
ADVPN2 is referred to 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, the ADVPN-1 overlay subnet is 10.10.1.0/24, and wanted to advertise routes over the 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 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 the spokes should have additional-path received.
Suppose the subnet 14.0.0.0/24 Behind the Spoke 1 wants to talk to 15.0.0.0/24 behind Spoke 2. When examining the spoke1's routing table, it is possible to observe that two copies are being received, as shown below.
Upon checking from the spoke2 and attempting 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 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)
Solution
On the HUB Side:
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 advertising 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)
It is also possible to filter the routes at the spokes inbound, instead of filtering them outbound on the HUB. Next, another approach is used.
For 'IPSEC', routes are marked with community 65400:1, and for 'IPSEC1', routes are marked with community 65400:2.This is done at the spokes and the hub.
At the spokes, another route-map is used inbound, to accept only the routes with community 65400:1 for the neighbor of the overlay
for 'IPSEC', and another one allowing only routes with community 65400:2 for the neighbor of the overlay for 'IPSEC1'.
This part is only on the spokes.
The configuration is as follows:
Spokes:
config router route-map
edit "IPSEC"
config rule
edit 1
set set-community "65400:1"
next
end
next
edit "IPSEC1"
config rule
edit 1
set set-community "65400:2"
next
end
next
edit "IPSEC-in"
config rule
edit 1
set match-community "IPSEC"
next
end
next
edit "IPSEC1-in"
config rule
edit 1
set match-community "IPSEC1"
next
end
next
end
config router bgp
set as 65400
set ibgp-multipath enable
set additional-path enable
config neighbor
edit "10.10.1.254"
set advertisement-interval 1
set link-down-failover enable
set remote-as 65400
set route-map-in "IPSEC-in"
set route-map-out "IPSEC"
set additional-path receive
next
edit "10.10.2.254"
set advertisement-interval 1
set link-down-failover enable
set remote-as 65400
set route-map-in "IPSEC1-in"
set route-map-out "IPSEC1"
set additional-path receive
next
end
Hub:
config router route-map
edit "IPSEC"
config rule
edit 1
set set-community "65400:1"
next
end
next
edit "IPSEC1"
config rule
edit 1
set set-community "65400:2"
next
end
next
end
config router bgp
set as 65400
set router-id 172.16.100.254
set ibgp-multipath enable
set additional-path enable
config neighbor-group
edit "IPSEC"
set link-down-failover enable
set remote-as 65400
set route-map-out "IPSEC"
set additional-path send
set route-reflector-client enable
next
edit "IPSEC1"
set link-down-failover enable
set remote-as 65400
set route-map-out "IPSEC1"
set additional-path send
set route-reflector-client enable
next
end
config neighbor-range
edit 1
set prefix 10.10.1.0 255.255.255.0
set neighbor-group "IPSEC"
next
edit 2
set prefix 10.10.2.0 255.255.255.0
set neighbor-group "IPSEC1"
next
end
Another issue that may arise is that since the HUB has all the routing information for both overlays, it may receive traffic from one overlay
and send it out via another overlay. This happens because it will perform ECMP. However, at the spoke, it will cause issues due to RPF check failure. To ensure the HUB only forwards traffic over the same overlay, it is possible to use ADVPN overlay stickiness. Refer to this article for more information: Technical Tip: Usage of overlay stickiness in multiple overlay links in an ADVPN/SDWAN setup.
