[c-nsp] IOS XR Null darknet traffic at border without impacting convergence time

[John Neiberger]

If I understand the problem, you can implement selective BGP next hop
filtering. That allows you to use a route policy to determine which next
hops are valid. We use it to ensure that no prefix shorter than a /29 is
used to validate next hops in certain situations.

This is the basic idea:


router bgp <AS>

 address-family ipv4 unicast

  nexthop route-policy NEXT-HOP-TRACKING


 route-policy NEXT-HOP-TRACKING

  if destination in (0.0.0.0/0 ge 29) then

    pass

  endif

end-policy



You can probably tweak that policy to get the desired results.


HTH,

John


On Fri, Sep 6, 2013 at 11:10 AM, Drew Weaver <drew.weaver at thenap.com> wrote:

> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>