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 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
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)
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 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)
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's possible to use a route policy as follows:
config router policy
edit 1
set input-device "IPSEC" << tunnel name
set output-device "IPSEC"
next
edit 2
set input-device "IPSEC1"
set output-device "IPSEC1"
next
end
