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

Fri Aug 17 04:33:29 EDT 2007

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

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>