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

[Oliver Boehmer (oboehmer)]

Dermot,

you didn't say how much calls/sec you get on this box? If this is low (a
few per second), the overhead will possibly so low that you won't even
notice it. You'll really benefit from VAI subinterfaces when you deal
with several thousands of sessions and or a very high call load (guess
more than 20 or so calls/sec).
Do you see significant load in vtemplate backgr mgr (or similar)
process? Any process using up a considerable amount of CPU?

	oli

Dermot Williams <mailto:dermot.williams at irishbroadband.ie> wrote on
Friday, August 17, 2007 10:33 AM:

> Oliver,
> 
> Thanks for your help - I've installed c7301-a3jk91s-mz.122-28.SB8.bin
> on 
> the (lab) router and I now have sub-interfaces working. I suppose the
> next question I have to answer is whether or not the resource savings
> that I can make by running this version of the code rather than the
> 12.4T line that we're running on the production 7301 is worth the
> maintenance outage required to swap it!
> 
> Regards,
> 
> Dermot
> 
>> -----Original Message-----
>> From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
>> Sent: 13 August 2007 18:38
>> To: Dermot Williams; cisco-bba at puck.nether.net
>> Subject: RE: [cisco-bba] VRFs, VPDN and Virtual Access Interfaces
>> 
>> 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
> 
> 
> 
> 
> 
> <p class=MsoNormal><span lang=EN-GB
> style='font-size:10.0pt;font-family:"Arial","sans-serif";
> color:#808080'>  
> Note:<br>
> This message is for the named person's use only. It may contain
> confidential, proprietary or legally privileged information. No
> confidentiality or privilege is waived or lost by any
> mistransmission. If you receive this message in error, please
> immediately delete it and all copies of it from your system, destroy
> any hard copies of it and notify the sender. You must not, directly
> or indirectly, use, disclose, distribute, print, or copy any part of
> this message if you are not the intended recipient. Irish Broadband
> and any of its subsidiaries each reserve the right to monitor all
> e-mail communications through its networks. Any views expressed in
> this message are those of the individual sender, except where the
> message states otherwise and the sender is authorized to state them
> to be the views of any such entity. </span> <em><span lang=EN-GB
> style='font-size:7.5pt;font-family:"Arial","sans-serif";
> color:#808080'>            
> Irish Broadband Internet Services Ltd, Registered in Ireland, Number:
> 357181, Registered Office: Burton Court, Burton Hall Road, Sandyford
> Industrial Estate, Dublin 18.</span></em><span
> lang=EN-GB><o:p></o:p></span></p>