|
In a dual-HUB ADVPN environment, a dual-ISP spoke advertises its routes to both HUBs over each ISP connection. The HUBs then readvertise all paths to other spokes due to IBGP route-reflector-client.
A single-ISP spoke receives these routes, including paths with a next-hop IP that corresponds to the dual-ISP spoke's second VPN tunnel. Since the single-ISP spoke has no route to this next-hop IP via its primary VPN, it will perform a recursive lookup and install the route via its physical interface, such as a default route, leading to unexpected routing and traffic loss.
To resolve this, BGP communities are used to tag routes based on the ISP they were learned. Route maps are then applied on the single-ISP spokes to filter incoming advertisements, allowing only routes tagged for ISP1.
Topology Overview:
Routing State Before the Solution:
Before implementing the route filter, the single-ISP spoke (Spoke2) receives and installs all four paths for the network '192.168.1.0/24'. This includes two paths with next-hop IPs via ISP1 ('10.10.10.1', '10.20.10.1') and two paths with next-hop IPs via ISP2 ('10.10.20.1', '10.20.20.1'). The routing table shows recursive lookups for the ISP2 next-hop IPs via a physical interface (port10), which is incorrect.
Spoke2 # get router info bgp network 192.168.1.0
VRF 0 BGP routing table entry for 192.168.1.0/24
Paths: (4 available, best #4, table Default-IP-Routing-Table)
Not advertised to any peer
Original VRF 0
Local
10.20.20.1 from 10.20.10.101 (172.16.10.1)
Origin IGP metric 0, localpref 100, valid, internal
...
Original VRF 0
Local
10.10.20.1 from 10.10.10.100 (172.16.10.1)
Origin IGP metric 0, localpref 100, valid, internal, best
...
Original VRF 0
Local
10.20.10.1 from 10.20.10.101 (172.16.10.1)
Origin IGP metric 0, localpref 100, valid, internal
...
Original VRF 0
Local
10.10.10.1 from 10.10.10.100 (172.16.10.1)
Origin IGP metric 0, localpref 100, valid, internal, best
...
Spoke2 # get router info routing-table details 192.168.1.0
Routing table for VRF=0
Routing entry for 192.168.1.0/24
Known via "bgp", distance 200, metric 0, best
Last update 00:00:31 ago
* vrf 0 10.10.10.1 priority 1 (recursive via H1_ISP1 tunnel 198.18.101.100)
* vrf 0 10.10.20.1 priority 1 (recursive via 192.168.0.254, port10)
* vrf 0 10.20.10.1 priority 1 (recursive via H2_ISP1 tunnel 198.18.201.200)
* vrf 0 10.20.20.1 priority 1 (recursive via 192.168.0.254, port10)
Configuration Steps:
On the Dual-ISP Spoke (Advertising Router-Spoke1):
Create route maps to tag the local LAN subnet with a unique community when advertised via each ISP. The community '6500:1' is for ISP1 and '6500:2' is for ISP2.
```
config router route-map
edit "ISP1-OUT"
config rule
edit 1
set match-ip-address "BR1_LAN"
set set-community "6500:1"
next
end
next
edit "ISP2-OUT"
config rule
edit 1
set match-ip-address "BR1_LAN"
set set-community "6500:2"
next
end
next
end
```
Apply the outgoing route maps to the BGP neighbors for each HUB connection.
```
config router bgp
config neighbor
edit "10.10.10.100"
set route-map-out "ISP1-OUT"
next
edit "10.10.20.100"
set route-map-out "ISP2-OUT"
next
edit "10.20.10.101"
set route-map-out "ISP1-OUT"
next
edit "10.20.20.101"
set route-map-out "ISP2-OUT"
next
end
end
```
On the Single-ISP Spoke (Receiving Router-Spoke2):
Create a BGP community list that permits routes tagged with '6500:1' and denies routes tagged with '6500:2'.
```
config router community-list
edit "ALLOW_ISP1"
config rule
edit 1
set action permit
set community "6500:1"
next
edit 2
set action deny
set community "6500:2"
next
end
next
end
```
Create a route map that uses the community list to filter incoming BGP routes:
```
config router route-map
edit "ALLOW_IN"
config rule
edit 1
set match-community "ALLOW_ISP1"
set action permit
next
edit 2
set action deny
next
end
next
end
```
Apply the incoming route map to the BGP neighbor connections for both HUBs.
```
config router bgp
config neighbor
edit "10.10.10.100"
set route-map-in "ALLOW_IN"
next
edit "10.20.10.101"
set route-map-in "ALLOW_IN"
next
end
end
```
Routing State After the Solution:
After implementing the configuration, the BGP and routing tables on the single-ISP spoke (Spoke2) are clean. Only the two paths tagged with the '6500:1' community are accepted and installed. The recursive lookups now correctly point only to the ISP1 VPN tunnels, resolving the traffic routing issue.
Spoke2 # get router info bgp network 192.168.1.0
VRF 0 BGP routing table entry for 192.168.1.0/24
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Not advertised to any peer
Original VRF 0
Local
10.20.10.1 from 10.20.10.101 (172.16.10.1)
Origin IGP metric 0, localpref 100, valid, internal, best
Community: 6500:1
...
Original VRF 0
Local
10.10.10.1 from 10.10.10.100 (172.16.10.1)
Origin IGP metric 0, localpref 100, valid, internal, best
Community: 6500:1
```
Spoke2 # get router info routing-table details 192.168.1.0
Routing table for VRF=0
Routing entry for 192.168.1.0/24
Known via "bgp", distance 200, metric 0, best
Last update 01:44:16 ago
* vrf 0 10.10.10.1 priority 1 (recursive via H1_ISP1 tunnel 198.18.101.100)
* vrf 0 10.20.10.1 priority 1 (recursive via H2_ISP1 tunnel 198.18.201.200)
|
