[cisco-bba] VRFs, VPDN and Virtual Access Interfaces
Oliver Boehmer (oboehmer)
oboehmer at cisco.com
Sat Aug 11 04:35:54 EDT 2007
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
> 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
> 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
> 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
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
> 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.
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
More information about the cisco-bba