In this topology I've created an MPLS framework with one Customer VPN. A radius server was implemented using a VMWare running Freeradius connected via a dedicated VMware virtual network. An LNS router has been configured to terminate PPP sessions by using the Radius server for authentication, and a Cisco 2600 is used as the PPP client. It goes without saying none of the below is of production quality, it is rough-and-ready lab to prove the point.
interface Dialer1 ip address negotiated ip mtu 1492 ip nat outside encapsulation ppp no ip mroute-cache dialer pool 1 ppp authentication chap pap callin ppp chap hostname nicholas ppp chap password 0 nicholas ppp pap sent-username nicholas password 0 nicholas ! interface FastEthernet0/1 no ip address duplex auto speed auto pppoe enable pppoe-client dial-pool-number 1So far so good. Next in the chain is the LNS router. Well, ahem, you might expect it be called an LNS in a production environment, however we're not actually terminating L2TP tunnels in this lab. I mean, come on. I am having a bit of brain-freeze as to what this should actually be called, if I remember I will come back to it.
Anyway, lets look at the problem. In the project environment all PPP subscribers will be terminating their PPP sessions in a common VRF due to whatever the virtual-template has decided for them. In my lab environment it doesn't really matter if the PPP subscribers mix with the global routing table, so to save time I haven't given the virtual-template any VRF context:
interface FastEthernet0/1 no ip address duplex auto speed auto pppoe enable group global ! interface Virtual-Template2 mtu 1472 ip unnumbered Loopback0 no ip redirects ip tcp adjust-mss 1452 no peer default ip address ppp authentication pap chap ppp direction callinBut this particular subscriber has paid for an MPLS VPN so we require them to authenticate their session on the Radius and for routing appear in a private VRF, which I have cryptically called, "vpn1". Here is a selection of MPLS configuration for the lab:
ip vrf vpn1 rd 65001:1 vpn id 1:1 route-target export 1:1 route-target import 1:1 ! router bgp 65000 no synchronization bgp log-neighbor-changes redistribute connected neighbor mpls peer-group neighbor mpls remote-as 65000 neighbor mpls update-source Loopback0 neighbor 10.0.0.1 peer-group mpls neighbor 10.0.0.2 peer-group mpls neighbor 10.0.0.3 peer-group mpls neighbor 10.0.0.4 peer-group mpls no auto-summary ! address-family vpnv4 neighbor mpls send-community both neighbor 10.0.0.1 activate neighbor 10.0.0.2 activate neighbor 10.0.0.3 activate neighbor 10.0.0.4 activate exit-address-family ! address-family ipv4 vrf vpn1 redistribute connected no synchronization network 172.16.0.0 network 172.30.3.0 mask 255.255.255.0 exit-address-familyThe LNS also has a loopback in the private VRF, but why, what is it for?
interface Loopback5 ip vrf forwarding vpn1 ip address 172.16.6.1 255.255.255.255We will find out soon. So all this config is great, but it doesn't work, the customer will appear in the global routing table. The answer to my pondering was happily simple: radius. So first it might be nice just to see the users file in Freeradius, thats the kind of useful stuff people come to blogs for:
nicholas Cleartext-Password := "nicholas" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 172.16.3.33, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = Broadcast-Listen, Framed-Compression = Van-Jacobsen-TCP-IP, Cisco-AVPair="lcp:interface-config#1=ip vrf forwarding vpn1", Cisco-AVPair+="lcp:interface-config#2=ip unnumbered loopback 5"The spoiler is the Cisco-AVPair config. You can probably leave now. No, really, you want to stay? Wow. Ok. For those staying, the LNS radius config looks like this (Please note the 192.168.1.0/24 subnet connecting the radius and LNS is not to be confused with the VPN 192.168.1.0/30 subnet - which I dont think you know about anyway, well, its between CustA1 and MPLS1, so you know now):
aaa new-model ! aaa authentication ppp default group radius aaa authorization network default group radius local aaa accounting exec default action-type start-stop group radius ! ip radius source-interface FastEthernet0/0 ! radius-server host 192.168.1.74 auth-port 1645 acct-port 1646 non-standard key nicholasAnd so to the solution. I am using Freeradius, it is familiar and easy to manage. The server itself is fairly simple to set-up. Using a wireless adapter to bridge the radius and LNS is a frustrating process, you can use a loopback and layer3 bridge however if you actually dont need to see the network on your LAN - which we all have to admit is kind of fun - then just connect both the vmware and GNS to a vmware host-only network.
And now let us behold the successful PPP negotiation (takes a wee while to debug so it does):
Now we can see the VPN routes on one of the MPLS switches:
With the critical AV-Pairs passing the virtual-template the required details the virtual-access interface is the right VRF. On the working model it is interesting to see how IOS builds the configuration with your radius values. "Derived configuration", that is a nice touch rarely seen I would suspect :-)
Ok enough, finally can one side ping the other?
Great, so finally I solved my simple problem. I hope this has been informative and I'd like to thank you for reading. [Dear CBT, that's not trademarked is it??]