I am looking to resolve a carrier black hole routing issue with IP SLA rather than deploying a network overlay. We have a number of sites, each with a unique private BGP AS number assigned. We have some issues where the carrier is advertising prefixes to one of our CPE's but the traffic is black holed in the carrier network due to a stale LSP.
Test network:
CPE1 (AS 65003)---CARRIER (AS 1234)---CPE2 (AS 65006)
My plan was to do the following at CPE1 then replicate to the other sites:
1) Assign a unique next hop IP address for each remote BGP AS (e.g. for AS 65006 I would assign next hop 65.0.0.6)
2) Create a static route with an admin distance of 15 pointing to null0 for each next hop assigned in step 1.
3) Create an ip sla and track object which pings the remote routers loopback IP from the local routers loopback IP.
4) Create another static route for the next hop assigned in step 1, this time with admin distance of 10 pointing to the BGP neighbor address. This route would be tied to the track statement created in step 3.
5) Create a route map that matches the AS_PATH of the remote site (ignoring the routers loopbacks) and set the next hop address assigned in step 1.
The routes received from the carrier are re-written with the next hop assigned in step 1 but the next hop is marked as in accessible and therefore not used by BGP (ignore path 2).
#sh bgp xx.xx.165.0
BGP routing table entry for xx.xx.165.0/24, version 23
Paths: (2 available, best #2, table default)
Advertised to update-groups:
6
Refresh Epoch 2
1234 65006
65.0.0.6 (inaccessible) from xx.xx.xx.129 (xx.xx.xx.137)
Origin incomplete, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
1234 65006
xx.xx.xx.29 from 10.255.0.6 (xx.xx.59.130)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Originator: xx.xx.60.70, Cluster list: xx.xx.59.130, xx.xx.59.129
rx pathid: 0, tx pathid: 0x0
#sh ip route 65.0.0.6
Routing entry for 65.0.0.6/32
Known via "static", distance 10, metric 0 (connected)
Routing Descriptor Blocks:
* xx.xx.xx.129, via GigabitEthernet0/14
Route metric is 0, traffic share count is 1
What are the requirements to overcome an "inaccessible" next-hop?
The RFC states:
If the NEXT_HOP attribute of a BGP route depicts an address that is
not resolvable, or if it would become unresolvable if the route was
installed in the routing table, the BGP route MUST be excluded from
the Phase 2 decision function.
Cisco states:
Paths for which the NEXT_HOP is inaccessible
Be sure that there is an Interior Gateway Protocol (IGP) route to the NEXT_HOP that is associated with the path.
Regards
Nick
