Hi,
There is a chance I am going about this design in a sub-optimal way; so if that
is the case feel free to let me know.
We have a facility in location A which hosts some content behind our
core/distribution routers.
We have a facility in location B which is basically just used for peering and
transit connectivity.
The routers in location A announce our public prefixes to the routers in
location B which in turn announce those prefixes to the Internet because there
are 500 miles between location A and location B we would rather not transit
packets for /32s which have no route in our IGP (darknet). (The quantity of
direct connectivity available in location A makes hauling the traffic ourselves
a priority).
To this end when we announce the prefixes from the core to the border the next
hop is set to 192.0.2.1 which is nailed as a static route to null at the border.
When the link between location A and location B fails (which happens
occasionally even though it's protected) IOS XR's next hop tracking immediately
realizes that the routers which originate the prefixes are unreachable.
However, because there is still a static route to 192.0.2.1, the prefixes are
not withdrawn until the regular BGP timer expires and the session falls.
This is what sh bgp nexthops looks like before the link goes down:
RIB Related Information
Gateway: reachable, non-Connected route, prefix length 32
And after:
RIB Related Information
Gateway: unreachable, non-Connected route, prefix length 49374
During the time between when the link fails and the BGP session expires the ASR
obviously continues to announce that it is a valid path for those prefixes to
the Internet, thus essentially creating a black hole for a brief (but not brief
enough) period of time. Although this condition has only happened twice in a
number of years, I would like to avoid it altogether.
Does anyone know of a configurable way to tell IOS XR to immediately withdrawal
prefixes which _originate_ from an unreachable nexthop?
Thanks for any ideas you may have regarding this.
-Drew
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
