[c-nsp] redistribute subscriber route leaking on ASR9k

[Pshem Kowalczyk]

Hi,

We've encountered this bug on our BNGs as well. Initially in 4.3.4, but
it's also present in the 5.2.x train.

To get this going we've put some aggregate hold-down routes on another
(upstream from BNG) routers that cover all the subscriber ranges and run
label-per vrf (to force the L3 lookup). It's not a big problem for us,
since we never have just a BNG in a site. This workaround doesn't work on
the box itself, since it doesn't generate the labels for "local" traffic.

If you don't want to move the traffic further upstream I think you have two
choices:
1. Merge both vrf localy (and use multiple RT and import/export route
policies to manipulate the advertisement of prefixes. This way the rest of
the network sees them still as separate.
2. Run a cable between two interfaces on the same router (instead of
import/export).

kind regards
Pshem


On Mon, 4 May 2015 at 14:54 Nathan Ward <cisco-nsp at daork.net> wrote:

> Hi all,
>
> Very much related to the “Internet in a VRF” discussion.
>
> I’ve got a customer who's running ASR9k BNGs with Internet in VRFs, and
> has a couple of different VRFs that customers terminate in to, depending
> whether the customer needs to go via the NAT farm or not.
>
> On the same BNG, they have another VRF with “services” in it. CDN, DNS,
> etc. that should be able to talk directly to the customers, whether they
> are in the NAT VRF or the normal VRF.
>
> Pretty simple route leaking to get that to work. Services imports the NAT
> and straight Internet RT, and the NAT and straight Internet VRFs import the
> services RT.
>
>
> However, we have found that ASR9k has a bug, where if these three VRFs are
> on the same router, routes advertised with “redistribute subscribers” don’t
> get installed in the “services” VRF. They show in the right place in BGP,
> and in the “sh route” RIB, but they don’t make it in to CEF.
>
> The bug ID is CSCui68943, and Cisco apparently have no plans to fix it any
> time soon. It seems like a pretty big bug, so I’m naturally quite surprised
> that there’s apparently no demand for this feature.
>
>
> Has anyone else hit this issue? Did you find some kind of work around?
> I’ve only come across one other reference to the problem on the Cisco
> forums, with no responses.
> Any workaround we can come up with requires moving reasonably large
> amounts of traffic over extra interfaces, which isn’t really a good
> solution if you ask me.
>
> We can, of course, put the “services” VRF on a different router, but that
> doesn’t work where we have POPs which consist of only a BNG and a CDN
> hanging off it.
>
> --
> Nathan Ward
>
> _______________________________________________
> 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/