[cisco-bba] VRFs, VPDN and Virtual Access Interfaces

[Oliver Boehmer (oboehmer)]

Dermot Williams <mailto:dermot.williams at irishbroadband.ie> wrote on
Monday, August 13, 2007 12:47 PM:

>>> 
>>> My main issue is that all of the VRF users are given a Virtual
>>> Access interface and not a Virtual Access sub-interface. I know why
>>> this is happening - I am using RADIUS to send
>>> "lcp:interface-config= ... " attributes back for the VRF users.
>>> However, I also know that Virtual Access interfaces have a larger
>>> memory/CPU overhead than VA sub-interfaces.
>> 
>> this is correct, the impact, however, depends on the number of
>> sessions and also the session setup rate. So full VAI are no "bad"
>> per se, it depends on the environment. Can you describe your
>> environment a bit more? 
>> 
> [Dermot Williams]
> 
> I have this working in a lab environment at the moment so I have
> complete control over both the LNS and the LAC. In this lab scenario I
> am working with just one 'subscriber', an 800 series router.
> Obviously, in this case, I don't really have to worry too much about
resource
> consumption by VRF forwarded subscribers.
> 
> However, in our production it won't be so clear-cut. We resell DSL
> connections using the local incumbent's wholesale DSL product so we
> don't have any control over the LAC. On the production 7301 we have
> approximately one thousand subscribers currently - these subscribers
> are all internet-bound so we aren't doing anything fancy. Our
intention is
> to start offering L3VPN services over DSL so eventually there will be
> a mix of subscribers who are destined for the internet and subscribers
> who are dumped into a VRF.

I wouldn't be that concerned with a thousand subscribers using full
VAIs. Can you tell how much sessions/sec you get with your user base? I
guess the only time you would see a difference is when the connection to
the incumbent goes down and all the sessions will need to be
re-established more or less at the same time. This can take longer with
full VAI..

>> In latest 12.2SB, you have two additional options:
>> 
>> 1) Use Cisco-avpair = "ip:vrf-id=<vrf-name>" and
>> "ip:ip-unnumbered=Loopback<n>", which are subinterface-capable
>> 
>> 2) Use Cisco-avpair = "lcp:allow-subinterface=yes" and use the
>> "lcp:interface-config" commands you've mentioned. This is a
>> workaround for those lcp:interface-config config statements which
>> are actually subinterface-capable, which I think is the case for all
>> the ones you sent (vrf, unnumbered, pool). Other, non sub-VAI
>> compatible config commands will be ignored, as far as I know.
>> 
>> Please try this in the lab first, haven't really worked with this
>> for a while now. 
>> 
> [Dermot Williams]
> 
> This is all benched in the lab at the moment so I can chop and change
> as I want for the moment. We're actually running 12.4(11)T so I'll
have
> to download a 12.2SB image to test these AVPairs. Does it matter what
> order 
> I send the 'lcp:allow-subinterface=yes' VSa in? I.e., should it be
> sent before the other VSAs? Incidentally, is there anywhere that I can
> find a list of AVPairs for each IOS version?

Not sure, I'd send it first before the other attributes. There is also a
CLI "aaa policy inteface-config allow-subinterface" which enables this
globally..

	oli