Dial-In access to VRF Lite (MPLS VPN)

Hi,
I'm trying to implement a solution, that gives opportunity to dial-in to some specific customers VPN (VRF Lite)
Configuration of NAS is done using cisco.com guide and seems OK. NAS is using RADIUS to authenticate users, and if authenticated, RADIUS sends a specific users virtual-profile configuration to NAS. So far everything seems OK. I can dial-in, succesfuly authenticate against RADIUS and download the virtual-profile configration (DEBUG is pasted below).
BUT, even there is a command "virtual-profile aaa", and RADIUS sends all info, Virtual-Access interface isn't created or it is created without any configuration.
Maybe this is happening because I'm using dialer-profile ? Some cisco documentation says that if there are dialer-profiles configured, virtual-profile configuration cann't be downloaded from AAA ???
Here is debug, You can see RADIUS to NAS communication:
Aug 24 07:59:59: %LINK-3-UPDOWN: Interface Serial2/0:26, changed state to up
Aug 24 08:00:00: RADIUS(000000A1): Storing nasport 20026 in rad_db
Aug 24 08:00:00: RADIUS(000000A1): Config NAS IP: 0.0.0.0
Aug 24 08:00:00: RADIUS/ENCODE(000000A1): acct_session_id: 247
Aug 24 08:00:00: RADIUS(000000A1): sending
Aug 24 08:00:00: RADIUS/ENCODE: Best Local IP-Address xxx.xxx.xxx.xxx for Radius-Server xxx.xxx.xxx.xxx
Aug 24 08:00:00: RADIUS(000000A1): Send Access-Request to xxx.xxx.xxx.xxx:1645 id 21646/40, len 113
Aug 24 08:00:00: RADIUS: authenticator C9 98 61 51 0F FF 0F C8 - FA A2 3E C1 5E 80 13 0E
Aug 24 08:00:00: RADIUS: Framed-Protocol [7] 6 PPP [1]
Aug 24 08:00:00: RADIUS: User-Name [1] 6 "vrft"
Aug 24 08:00:00: RADIUS: CHAP-Password [3] 19 *
Aug 24 08:00:00: RADIUS: Vendor, Cisco [26] 20
Aug 24 08:00:00: RADIUS: cisco-nas-port [2] 14 "Serial2/0:26"
Aug 24 08:00:00: RADIUS: NAS-Port [5] 6 20026
Aug 24 08:00:00: RADIUS: NAS-Port-Type [61] 6 ISDN [2]
Aug 24 08:00:00: RADIUS: Calling-Station-Id [31] 9 "xxxxxxx"
Aug 24 08:00:00: RADIUS: Called-Station-Id [30] 9 "xxxxxxx"
Aug 24 08:00:00: RADIUS: Service-Type [6] 6 Framed [2]
Aug 24 08:00:00: RADIUS: NAS-IP-Address [4] 6 xxx.xxx.xxx.xxx
Aug 24 08:00:00: RADIUS: Received from id 21646/40 xxx.xxx.xxx.xxx:1645, Access-Accept, len 277
Aug 24 08:00:00: RADIUS: authenticator 8D E7 52 2A 4B 72 88 9E - B8 85 38 CF 70 4A B7 79
Aug 24 08:00:00: RADIUS: Service-Type [6] 6 Framed [2]
Aug 24 08:00:00: RADIUS: Framed-Protocol [7] 6 PPP [1]
Aug 24 08:00:00: RADIUS: Framed-IP-Address [8] 6 10.10.8.5
Aug 24 08:00:00: RADIUS: Framed-IP-Netmask [9] 6 255.255.255.240
Aug 24 08:00:00: RADIUS: Framed-Compression [13] 6 VJ TCP/IP Header Compressi[1]
Aug 24 08:00:00: RADIUS: Vendor, Cisco [26] 54
Aug 24 08:00:00: RADIUS: Cisco AVpair [1] 48 "lcp:interface-config#1= ip vrf forwarding test"
Aug 24 08:00:00: RADIUS: Vendor, Cisco [26] 68
Aug 24 08:00:00: RADIUS: Cisco AVpair [1] 62 "lcp:interface-config#2= ip address 10.10.8.1 255.255.255.240"
Aug 24 08:00:00: RADIUS: Vendor, Cisco [26] 50
Aug 24 08:00:00: RADIUS: Cisco AVpair [1] 44 "lcp:interface-config#3= description horray"
Aug 24 08:00:00: RADIUS: Vendor, Cisco [26] 49
Aug 24 08:00:00: RADIUS: Cisco AVpair [1] 43 "lcp:interface-config#4= encapsulation ppp"
Aug 24 08:00:00: RADIUS: Framed-Routing [10] 6 0
Aug 24 08:00:00: RADIUS(000000A1): Received from id 21646/40
Aug 24 08:00:00: %ISDN-6-CONNECT: Interface Serial2/0:26 is now connected to xxxxxxx vrft
Aug 24 08:00:00: %LINK-3-UPDOWN: Interface Serial2/0:26, changed state to down
Please let me know if any other information is required.

Besides, as I see, virtual-access interface's description is as configured on RADIUS, but all other configuration is from virtual-template. Why? Even if there are no overlapping configuration strings in Vtemplate and on AAA (like ip address etc), configuration string received from RADIUS isn't getting added to virtual-access interface configuration.

Similar Messages

GRE with VRF on MPLS/VPN

Hi.
Backbone network is running MPLS/VPN.
I have one VRF (VRF-A) for client VPN network.
One requirement is to configure another VRF (VRF-B) for this client for a separate public VRF connection.
Sub-interfacing not allowed on CE-to-PE due to access provider limitation.
So GRE is our option.
CE config:
Note: CE is running on global. VRF-A is configured at PE.
But will add VRF-B here for the requirement.
interface Tunnel0
ip vrf forwarding VRF-B
ip address 10.12.25.22 255.255.255.252
tunnel source GigabitEthernet0/1
tunnel destination 10.12.0.133
PE1 config:
interface Tunnel0
ip vrf forwarding VRF-B
ip address 10.12.25.21 255.255.255.252
tunnel source Loopback133
tunnel destination 10.12.26.54
tunnel vrf VRF-A
Tunnel works and can ping point-to-point IP address.
CE LAN IP for VRF-B is configured as static route at PE1
PE1:
ip route vrf VRF-B 192.168.96.0 255.255.255.0 Tunnel0 10.12.25.22
But from PE2 which is directly connected to PE1 (MPLS/LDP running), connectivity doesnt works.
From PE2:
- I can ping tunnel0 interface of PE1
- I cant ping tunnel0 interface of CE
Routing is all good and present in the routing table.
From CE:
- I can ping any VRF-B loopback interface of PE1
- But not VRF-B loopback interfaces PE2 (even if routing is all good)
PE1/PE2 are 7600 SRC3/SRD6.
Any problem with 7600 on this?
Need comments/suggestions.

Hi Allan,
what is running between PE1 and PE2 ( what I mean is any routing protocol).
If No, then PE2 has no ways of knowing GRE tunnel IP prefixes and hence I suppose those will not be in its CEF table...
If Yes, then check are those Prefixes available in LDP table...
Regards,
Smitesh

Filtering methods inside a VRF in MPLS VPN

Hi,
we have a network with MPLS VPN and several VRFs involved.
Inside a certain VRF I need to avoid that two particular networks can talk to each other.
Can you give me a hint of what can be a solution to implement this ?
Thanks
Regards
Marco

Hi Marco,
To prevent connectivity between two networks where a MPLS VPN is involved you can apply the same methods as in a "normal" router network. Just think of the complete MPLS VPN (PE to PE) as being one big "router simulator".
You could either implement ACLs on the interfaces connecting to the PE or filter routing updates between sites - depending on your topology. When filtering routing updates seems the way to go, you should also have a look into selective import or export. With the help of a route-map one can selectively insert single networks into a VPN by selectively attaching route-targets to BGP updates.
Regards, Martin

Could MPLS L3 VPN forward packet which CE configure VRF Lite?

Or does anyone have a lab for my test? Please share.
Diagram:
vrf lite - mplsl3 vpn - vrf lite
Will it have any change on mpls l3vpn configuration?
Thank you very much.

I test lab follow to this document is work. I test with static route and OSPF is work. Now, I’m testing with BGP route. I found the PE doesn’t send the BGP routes from the other sites to the CE. How should I do?
Topology:
BGP vrf lite (vrf v11) CE1 - BGP - MPLS L3VPN (vrf v1) PE1 - PE2 (vrf v1) MPLS L3VPN - BGP - CE2 (vrf v11) vrf lite BGP
PE1#sho ip rou vrf v1
Gateway of last resort is not set
B    10.0.252.1/32 [200/0] via 10.0.0.11 (nexthop in vrf default), 1d22h
B    10.0.252.2/32 [200/0] via 10.0.0.14 (nexthop in vrf default), 1d22h
L    10.0.252.3/32 is directly connected, 1d22h, Loopback101
B    38.0.0.0/24 [200/0] via 10.0.0.11 (nexthop in vrf default), 1d04h
B    39.0.0.0/24 [200/0] via 10.0.0.14 (nexthop in vrf default), 05:13:07
B    40.0.0.0/24 [200/0] via 10.0.0.11 (nexthop in vrf default), 1d04h
C    41.0.0.0/24 is directly connected, 1d22h, GigabitEthernet0/0/1/2.14
L    41.0.0.3/32 is directly connected, 1d22h, GigabitEthernet0/0/1/2.14
B    208.0.0.0/24 [200/0] via 10.0.0.11 (nexthop in vrf default), 00:06:55
B    209.0.0.0/24 [200/0] via 10.0.0.14 (nexthop in vrf default), 00:08:14
B    210.0.0.0/24 [20/0] via 41.0.0.8, 00:11:17
CE1#sho ip bgp vpnv4 vrf v11
BGP table version is 23, local router ID is 172.16.30.5
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 800:1 (default for vrf v11)
*> 10.0.252.1/32    41.0.0.3                               0 18252 ?
*> 10.0.252.2/32    41.0.0.3                               0 18252 ?
*> 10.0.252.3/32    41.0.0.3                 0             0 18252 ?
*> 38.0.0.0/24      41.0.0.3                               0 18252 ?
*> 39.0.0.0/24      41.0.0.3                               0 18252 ?
*> 40.0.0.0/24      41.0.0.3                               0 18252 ?
r> 41.0.0.0/24      41.0.0.3                 0             0 18252 ?
*> 210.0.0.0        0.0.0.0                  0         32768 i
CE1#

MPLS / vrf-lite

Hi
We currently use a BT MPLS network and use BGP on our CE router to peer with the providers PE routers. Currently we only use one VPN for production across the MPLS network.
We are now looking to give access from some of our MPLS sites to a test environment housed in our data centre. We need to do this on a pc by pc basis.
At the moment the plan is to add a Test VPN within the MPLS network. All sites will be a member of the production VPN and those sites that also need access to test environment will be a member of the Test vpn.
This will segregate the traffic over the WAN but the issue i now have is how to segregate the traffic once it leaves the PE router. The link between the CE and PE router is just a layer 3 link so the VPN separation
has disappeared by now. I don't mind the traffic not being separated in terms of VPN's on the CE to PE link but i need to segregate the traffic once it leaves the CE router and enters our LAN.
So finally the questions
1) Is there a way to keep the separation at a VPN level on the CE -> PE link. As i say i don't mind not having it but if there is a way i would be interested.
2) More importantly i have done some limited reading on VRF-lite and was wondering before i go further if that would allow me to segregate the traffic internally within the LAN. Our Lan's in major buildings usually consist
of 4500 at the access-layer and 6500 as distribtion/core. What i would ideally like to do is ensure that only users within the site who need to access the test environment can ie. by adding a site to the TEST vpn this does
not mean that all users within the site should be able to get to it.
I could
i) Use PBR together with access-list and potentially firewalls
ii) use vrf-lite to segregate the traffic.
So is this a good application for vrf-lite or have i missed the point of it ?. if not can anyone suggest a better way ?
Many thanks
Jon

Joseph/Anantha
Thanks to both of you for your replies. If i could just query your expertise a little more.
Attached is a visio of a site that i would like to be able to access both the Test and Production VPN's. The key thing to note is that we are routing from the access-layer down to the distribution 6500 switches.
Now on the 4500 i can have 2 separate VRF's, one for the Prod VPN and one for the Test VPN. I can then assign different vlan interfaces into the relevant vrf.
Am i right in my assumptions so far ?
The problem i am having in taking this further is that a L3 interface can only be in one VRF and as the connections from the 4500 to the 6500 are L3 uplinks i can't allocate the L3 link into 2 separate vrf's (nor would it make sense to do so).
I am not in a position to change the L3 links to L2 links which would solve part of the problem as the vlan interfaces would then be on the 6500 and i could allocate these interfaces into separate VRF's.
So is there any way, bearing in mind that i need to keep L3 links from the access-layer, that i can segregate the routing tables on the 6500 and 7200 router.
If i can't do this then i don't see the advantage of trying to use VRF-lite because the 6500/7200 and 3800 will all have one routing table with both Test and Prod routes in in it and this means without route filtering these routes will get propogated by the 3800 to our remote sites.
If i have to revert to route-filtering i may as well not bother with vrf-lite ?
Jon

Centralize internet access in MPLS VPN

Can i implement Centralize internet access (the Hub CE Router to performs NAT) in cisco MPLS VPN solution?
If so, is there any example about that? i can't find it at CCO~
Thanks a lot~

If you run dynamic routing protocol in PE-CE,like rip2,ospf,bgp,do the following task.
1:set a default route in HUB CE;and generate the default route under its dynamic protocol.
2:in other CEs, make sure they can learn this route.
If you run static route and vrf static route between CE and PE,do the following task.
1.set default route in HUB CE, and set default route in other CEs.
2.In all PEs,redistribute the connected and static rotues to address-family ipv4 of customer vrf.
3.set the customer vrf default route in all PE which connected your all CEs.
Note: make sure all PEs can reach the GW address of vrf deafult route. GW IP address is the interface of which HUB CE towards PE.
command: "ip route vrf 0.0.0.0 0.0.0.0 global.
TRY

Redundant access from MPLS VPN to global routing table

Several our customers have MPLS VPNs deployed over our infrastructure. Part of them requires access to Internet (global routing table in our case).
As I'm not aware of any methods how to dynamicaly import/export routes between VRF/Global routing tables, at the moment there are static routes configured - one inside VRF pointing to global next hop, another one in global routing table, pointing to interface inside VRF.
Task is to configure redundant access to Internet. By redundancy I mean using several exit points (primary and backup), what physically represents separate boxes.
Here comes tricky part - both global static routes (on both boxes, meaning) are valid and reachable in all cases - no matter if specific prefix is reachable in VRF or not. What I'd like to achieve is that specific static route becomes valid only if specific prefix is reachable inside VRF. Yea, sounds like dynamic routing :), I know
OK, hope U got the idea. Any solutions/recommendations ? Running all Internet routing inside VRF isn't an option, at least for now :(

Hi Andris,
I did not mean to have a VRF on the CE. The CE would have both PVCs in the global routing table - his ONLY routing table in fact. One PVC would be used to announce routes into the customer specific VPN (VRF configured on the PE). The other PVC would allow for internet access through the PE (global IP routing table on the PE).
dot1q will be ok as well.
This way the CE can be a normal BGP peer to the PE, i.e. there is no MPLS VPN involved here. This allows all options of customer-ISP connectivity.
Example:
PE config:
interface Serial0/0
encapsulation frame-relay
interface Serial0/0.1 point-to-point
description customer VPN access
ip vrf customer
ip address 10.1.1.1 255.255.255.252
interface Serial0/0.2 point-to-point
description customer Internet access
ip address 192.168.1.1 255.255.255.252
router rip
address-family ipv4 vrf customer
version 2
network 10.0.0.0
no auto-summary
redistribute bgp 65000 metric 5
router bgp 65000
neighbor 192.168.1.2 remote-as 65001
address-family ipv4 vrf customer
redistribute rip
CE config:
interface Serial0/0
encapsulation frame-relay
interface Serial0.1 point-to-point
description VPN access
ip address 10.1.1.2 255.255.255.252
interface Serial0.2 point-to-point
description Internet access
ip address 192.168.1.2 255.255.255.252
router bgp 65001
neighbor 192.168.1.1 remote-as 65000
router rip
version 2
network 10.0.0.0
no auto-summary
Of course you can replace RIP with whatever is suitable for you. And don´t sue me when you do not apply required BGP filters for internet access... ;-)
The other option ("mini internet") would be feasible as well. Just make sure your BGP filters are NEVER messed up and additionally apply a limit on the numbers of prefixes in your VRF mini-internet.
Regards
Martin

VRF lite and MPLS VRFs

We have a CE router connected to PE router. The CE router is connected via 2 links to the PE router, because we need to create two VRFs on the PE for the traffic coming from the CE to separate the traffic, so we have one vrf per link. We are running OSPF between CE and PE.. Now we need to further separate the traffic up to the CE, so Im thinking of using the VRF lite on the CE.. Can MPLS work with the VRF lite, and how to map the VRF lite VRFs on the CE to the MPLS VPN on the PE?
Is there any config examples?
Thanks in advance

VRF Lite and MPLS-VPN act independently so they can work independently. And there is no specific need for mapping. If link is for VRF A on PE so you can make it part of vrf A in CE as well. Both VRFs are independent of each other.
http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configuration_guide_chapter09186a00801cddd9.html#1045190
THis document is for 4500 but logic holds the same.

VRF-Lite versus VLANs at access edge

What would be the advantage in using VRF-Lite at the CE (e.g. a 3750 switch) and trunking a series of /30 pt-pt VLANs (one for each VRF) from the PE to the CE switch, and then defining customer VLANs on the 3750 versus defining the customer VLANs on the PE device and simply trunking the customer VLANs down to the 3750 switch. In the latter scenario, the IP Services feature set would not be required on the 3750 as VRF-Lite would not be necessary at the edge; just VLAN separation, with IP routing disabled.
A couple of possible benefits for using routed /30 links to the CE:
(i) if the routing is complex at the CE site and more subnets need to be advertised towards the PE (i.e. it's more than a single VLAN);
(ii) SP does not need to get involved in customer routing, but in a small Enterprise MPLS scenario, the customer and the provider may be one and the same, so may be less of an issue;
(iii) A dual-homed CE device may need routes advertised towards two separate PEs.

Hello Matthew,
a multi VRF CE also known as VRF lite is a shared device: it can be partitioned between different customers reducing cost of ownership for each of them.
It is typically owned and managed by a service provider.
It can fit to multi-tenant office facilities.
If yours is an enterprise scenario and the device is not going to be shared you can save some money making the C3750 a simple L2 switch and terminating all L3 interfaces on the PE itself.
On the other hand a VRF lite CE can reduce the number of L3 interfaces that need to be defined on the PE providing a scalability advantage (every platform has a maximum number of interfaces supported regardless they are in VRF or in global routing table)
Hope to help
Giuseppe

Vrf-Lite with MPLS requires a PE at the customer side?

Folks,
Looking at a cisco doc, which gives a sample configuration of VRF lite with MPLS (multiple customers in the same building using same MPLS cloud). My question is that how is it done in the real world. Does the provider place a PE at the customer site? cause the connection between the CE and PE has to be a link that can carry dot1Q (ethernet or fast etheret) atleast the example shows that.
Any real world experience would be highly appreciated.
Thanks,

Hi,
the customer needs no PE router installed at his site.
You can use vrf-lite (aka multi-vrf) even on a Cisco router, which does not support MPLS at all. On the CE each dot1Q subinterface can be placed in a vrf. All you need is a routing process started within the vrf being adjacent to the PE.
Example CE:
ip vrf CE-VRF1
rd 65000:1
interface FastEthernet0.100
encapsualtion dot1Q 100
ip vrf forwarding CE-VRF1
ip address 10.1.1.1 255.255.255.0
router ospf 100 vrf CE-VRF1
network 10.1.1.1 0.0.0.0 area 1
The PE would have MBGP and different RD and RTs defined, whatever is needed to setup VRFs in the provider network. Infact PE and CE each do not know about each others VRF configs at all.
VRFs on the CE define a separate IP routing context (control plane). The separation on the data plane is done via dot1Q headers (frame-relay, ATM PVC etc. would do as well) on the link between CE and PE. In an MPLS network data plane separation is done via labels.
Hope this helps
Martin

VRF Lite running in the enterprise network

Hello everybody
Altough VRF lite (or Mulit VRF) seems to be a Service Provider Tecnology.
Does it make sense to use it in an Enterprise Network to isolate Networks from others ?
I cant find any design paper which describes if this would make sense.
What do you think. Is someone using it ? Does Cisco recommend it ?

Yes, VRF-lite SHOULD be used in an Enterprise environment to isolate the different security classes of devices.
In the past you would isolate different groups of users using Layer1, i.e. separate hubs either totally isolated or connected together by a router with ACLs. Since the PCs were only connected at shared 10 Mbit and the routers were such low performance and worms weren't really prevalent, this was not a big security issue at the time.
Then we migrated to VLANs, which essentially allowed Layer2 isolation within the same switch to provide the same functionality of separating different classes of users and to break up broadcast domains. Unfortunately, everyone connected the VLANs together at Layer3 with a router (or SVI) which essentially connected everything together again! And almost no one gets the ACLs right (if at all) to isolate the VLANs from each other. In fact, in most cases every VLAN can automatically reach every other VLAN from a Layer3 or IP perspective. This is a huge security problem.
Enter VRF-lite, essentially created by Cisco as their tag switching migrated to standards based MPLS and had a need to isolate Layer3 security domains from each other within the same switch (or router). Think of VLANs for routing tables. VRF stands for 'Virtual Route Forwarding', which basically means separate routing tables. Since VRF-lite is a per-switch feature (running locally to the switch) you will need to use other technologies to connect multiple VRF-lite switches together and keep the traffic isolated, see below.
What makes this so secure is that there is no command within the switch to connect different VRFs together within the same switch. You would need to connect a cable between two ports on the same switch configured in different VRFs to be able to communicate between them (recent IOS 12.2SR allows tunnels with different source VRFs but that is a corner case). The reason for this is simple, remember the basis for VRF (and VRF-lite) is for a service provider to isolate multiple customers from each other within the same switch. Just like an ATM, Frame-Relay, SONET, or Optical switch, the command line makes it very difficult (or impossible) to accidentally connect 2 different customers together.
Think about that. Even if someone was able to get ssh enable access to your switch (you aren't running telnet anymore, right?!), they CAN'T connect 2 VRFs together with any command.
And, yes, this is highly recommended by Cisco Engineers and is actually deployed far more than you think. I have VRF-lite running on at least 10 client's networks and those are LARGE networks. VRF-lite was integrated into the environment purely to solve a Layer3 security class isolation issue. I have used Layer3 dot1q trunks on c6500 switches and tunnels to keep isolated connectivity between VRFs between switches.
In Cisco speak, VRF-lite falls under the topic of 'Path Isolation' which is combined with other features that isolate traffic within the same network such as dot1q trunking, tunneling, VPN, policy-routing, and MPLS. Do a search on Cisco's web site for 'path isolation' and you will find a bunch of info.
See the following URLs for a good start:
http://www.cisco.com/en/US/netsol/ns658/networking_solutions_design_guidances_list.html
http://www.cisco.com/en/US/netsol/ns658/netbr0900aecd804a17db.html
http://www.cisco.com/en/US/netsol/ns658/networking_solutions_white_paper0900aecd804a17c9.shtml
As always, rate all posts appropriately, particularly those that provide value and don't be shy about following up with additional questions or comments.
Good luck!

AAA Authentication and VRF-Lite

Hi!
I've run into a strange problem, when using AAA Radius authentication and VRF-Lite.
The setting is as follows. A /31 linknet is setup between PE and CE (7206/g1 and C1812), where PE sub-if is a part of an MPLS VPN, and CE uses VRF-Lite to keep the local services seperated (where more than one VPN is used..).
Access to the CE, via telnet, console etc, will be authenticated by our RADIUS servers, based on the following setup:
--> Config Begins <---
aaa new-model
aa group server radius radius-auth
server x.x.4.23 auth-port 1645 acct-port 1646
server x.x.7.139 auth-port 1645 acct-port 1646
aaa authentication login default group radius-auth local
aaa authentication enable default group radius-auth enable
radius-server host x.x.4.23 auth-port 1645 acct-port 1646 key <key>
radius-server host x.x.7.139 auth-port 1645 acct-port 1646 key <key>
ip radius source-interface <outside-if> vrf 10
---> Config Ends <---
The VRF-Lite instance is configured like this:
---> Config Begins <---
ip vrf 10
rd 65001:10
---> Config Ends <---
Now - if I remove the VRF-Lite setup, and use global routing on the CE (which is okey for a single-vpn setup), the AAA/RADIUS authentication works just fine. When I enable "ip vrf forwarding 10" on the outside and inside interface, the AAA/RADIUS service is unable to reach the two defined servers.
I compared the routing table when using VRF-Lite and global routing, and they are identical. All routes are imported via BGP correctly, and the service as a whole works without problems, in other words, the AAA/RADIUS part is the only service not working.

Just wanted to help future people as some of the answers I found here were confusing.
This is all you need from the AAA perspective:
aaa new-model
aaa group server radius RADIUS-VRF-X
server-private 192.168.1.10 auth-port 1812 acct-port 1813 key 7 003632222D6E3839240475
ip vrf forwarding X
aaa authentication login default group RADIUS-VRF-X local
aaa authorization exec default group X local if-authenticated
Per VRF AAA reference:
http://www.cisco.com/c/en/us/td/docs/ios/12_2/12_2b/12_2b4/feature/guide/12b_perv.html#wp1024168

Question to understand VRF and VRF-lite features

Hi,
when I look at METRO switches Feature list I see that most of them support only "VRF-Lite".
Does it mean that they can't work with MPLS lables and can't be placed as PE devices in cases where we need VPN services or any kinf of "Lable-switching" services?
Which role then does those METRO switches play in a network?

Hello Konstantin,
VRF lite is a subset of MPLS L3 VPN features missing MPLS forwarding plane capabilities.
An end to end dedicated IP path is needed for each VRF, practically a VRF-lite capable device should be connected to a fully capable PE node by using a L2 trunk and dedicating at least two Vlan and two SVI for each VRF: one towards customer and one towards PE.
you get a multi VRF CE that can be shared by multiple customers
a fully capable PE node uses N+1 links for N VRFs, a multiVRF CE requires 2*N logical interfaces for N VRFs
only one MPLS enabled backbone link is needed for handling traffic of multiple VRFs in a fully capable PE node.
in metro ethernet VRF lite multi VRF CE are used as feeders sort of satellite of PE nodes to provide an access layer to customers
Hope to help
Giuseppe

Selective Route Import/Export in MPLS VPN

Champs
I have multiple brach locations and 3 DC locations.DC locations host my internal applications , DC's also have central Internet breakout for the region. My requirement is to have full mesh MPLS-VPN but at same time brach location Internet access should be from nearest IDC in the region if nearest IDC is not availalbe it should go to second nearest DC for internet.I have decided which are primary and seconday DC for Internet breakout. How can this be achieved in MPLS-VPN scenario.Logically i feel , i have to announce specific LAN subnet and default route(with different BGP attribute like AS Path) from all 3 DCs. Spokes in the specific region should be able to import default route from primary DC and secondary DCs only using some route filter?
Regards
V

Hello Aaron,
the route example works for all routers except the one, where the VRF vpn2 is configured. What you can do for management purposes is either to connect through a neighbor router using packet leaking or configure another Loopback into VRF vpn2.
The last option (and my recommendation) is to establish another separate IP connection from your NMS to the MPLS core. Once VRFs are failing (for whatever reason, f.e. erroneously deleted) you might just not get connectivity to your backbone anymore to repair what went wrong.
So I would create an "interconnection router" with an interface in the VRF vpn2 and one interface in global IP routing table. This way you will still be able to access PEs, even if VRFs or MBGP is gone.
Hope this helps! Please rate all posts.
Regards, Martin

Extending VRF-lite to 6500??

Hello,
I have a simple scenario, where there is a 6500 connected to a router (ISP end), which we have planned to implement vrf-lite on.... there are basically 2 VLANs on the LAN, one production and one guest... we need to isolate the routing table instances between the production and guest.. we have planned to configure trunk between the 6500 and PE router at the ISP end. 6500 acts as a CE here.
Now, I want to extend the VRF information from the PE to the 6500 CE, since the layer 3 VLANs terminate on the 6500. i will define the same VRF information on the 6500 and isolate VRF routing tables for the guest/production vlan on the LAN also.. I know we will require to configure VRF, RD, BGP etc on the PE router and do a "ip vrf forwarding" on the subinterface of the router. What is the configuration required on the 6500 to extend the VRF-lite information to the end vlans ????? does anyone have any sample configs or links to which i can refer ?
Raj

Well,
first a sample config (not from a 6500, but you should be able to get the idea):
ip vrf Cust1
rd 65000:1
ip vrf Cust2
rd 65000:2
interface FastEthernet0/0.100
encapsulation dot1Q 100
ip vrf forwarding Cust1
ip address 10.1.1.1 255.255.255.252
interface FastEthernet0/0.200
encapsulation dot1Q 200
ip vrf forwarding Cust1
ip address 10.1.2.1 255.255.255.252
interface FastEthernet0/0.300
encapsulation dot1Q 300
ip vrf forwarding Cust2
ip address 10.20.1.1 255.255.255.252
interface FastEthernet0/0.333
encapsulation dot1Q 333
ip vrf forwarding Cust2
ip address 10.1.1.1 255.255.255.252
!On a 6500 you could also have:
interface vlan 400
ip vrf forwarding Cust2
ip address 10.1.123.1 255.255.255.252
router rip
address-family ipv4 vrf Cust1
version 2
network 10.0.0.0
no auto-summary
exit-address-family
address-family ipv4 vrf Cust2
version 2
network 10.0.0.0
no auto-summary
exit-address-family
The separation in the control plane (routing etc.) is achieved through the normal VRF configuration. Overlapping IPs and such are supported by having separate IP routing tables per VRF and VRF aware routing protocols like RIP, OSPF, etc.
In the data plane traffic is sorted by layer2 encapsulation. In the example above, the dot1Q VLAN tag will deliver the same functionality as the MPLS VPN labels. If f.e. an IP packet with destination 10.1.1.1 arrives, the VLAN tag 100 or 333 will allow the VRF-lite CE to determine, whether it belongs to Cust1 or Cust2. The same differentation will take place for traffic from the CE to the PE. So the PE config is practically the same, BUT in addition MP-BGP and route-targets and MPLS towards the core is used.
So no MPLS is needed on the VRF-lite CE router, no labels will be used, hence VRF-lite.
The PE will not be the PHP LSR in the MPLS sense, because it is the LAST router in the MPLS network.
Instead of the FastEthernet also VLAN interfaces can be used. The number of interfaces per VRF or the number of VRFs are limited by memory.
Hope this helps! Please use the rating system.
Regards, Martin

Dial-In access to VRF Lite (MPLS VPN)

Similar Messages

Maybe you are looking for