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

Mon Aug 13 06:46:51 EDT 2007

> -----Original Message-----
> From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
> Sent: 11 August 2007 09:36
> To: Dermot Williams; cisco-bba at puck.nether.net
> Subject: RE: [cisco-bba] VRFs, VPDN and Virtual Access Interfaces
> 
> Dermot Williams <> wrote on Friday, August 10, 2007 1:48 PM:
> 
> > I'm new to the list so I apologise in advance if any of the
questions
> > that I am asking have been asked and answered ad nausea. In my
> > defence, I did search the archives first and have already found
> answers to
> > other questions that I had.
> >
> > I'm doing some testing with L2TP-based VPDNs and VRFs for a future
> > L3VPN product. My goal is to switch certain users into a VRF
> configured on
> > the LNS and to continue to allow other users access to the internet.
> I
> > have this working but I do have some questions about my
> implementation.
> >
> > 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.

> > To mitigate against this I can pre-clone the VAIs but my
> understanding
> > is that if there are pre-cloned VAIs, none of my users will be
> > allocated VA sub-interfaces and I would like to avoid this if
> possible. I don't
> > want to use VAIs unless absolutely necessary and my assumption is
> that
> > if I were to pre-clone 50 VAIs, only 50 users would be allowed
online
> > at a given time.
> 
> No, this is not correct, if the system needs more VAIs, it allocates
> them as needed.
> 
> > Instead of using RADIUS attributes to create a user-specific VAI, is
> > there anyway that I could use them to force the VPDN session to use
a
> > Virtual-Template interface that already has the correct config on
it?
> 
> Yes, this is one of the two options. But you would need the LAC to
> forward these sessions in a different tunnel (and you can then use
> "terminate-from hostname <foo>" to map those to a vpdn-group  (i.e.
one
> vpdn-group per vrf). This could be a problem if the LAC is not owned
by
> you, or if the LAC doesn't know which vrf the user belongs to.
> 
[Dermot Williams] 

Unfortunately, as I say, we don't have control over the LAC.

> 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?

Thanks for your help,

Dermot

Note: 
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.


Irish Broadband Internet Services Ltd, Registered in Ireland, Number: 357181, Registered Office: Burton Court, Burton Hall Road, Sandyford Industrial Estate, Dublin 18.<o:p></o:p>