Sunday, 17 February 2013

How to Configure PPP Sessions for MPLS VPNs

Sometimes you have a problem which is relatively complicated however you don't have the scope or time to solve it. This is just such a problem which has been bugging me for a long time, simmering away since a job almost a year old: how do you get PPP sessions such as DSL subscribers into a private MPLS VPN? As it was never in the remit at the time I never solved it, despite that it stayed in the back of my mind. One rainy day I decided to get rid of it and solve the problem with a pleasant GNS3 lab, happy in the knowledge it was fairly pointless to do so. The solution, as ever, was satisfyingly simple: radius attributes. [And when I say, "solution", I mean, "my solution" - I am certain there are other methods which I would love to hear of.]

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.


Ok so the PPP client is relatively straight-forward. The router PPPoEClient is desired to be in a VPN with CustA1 router. Both these routers have default routes for simplicity with BGP distributing VPN routes at the PE.
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 1
So 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 callin
But 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-family
The 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.255
We 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 nicholas
And 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??]

3 comments:

  1. Hello,

    I have a quite similar config but with a probleme of course.. :)
    I send through radius attributes like the vrf forwarding but it seems the LNS is ignoring them and doesn't terminate the Vi interface in the specified vrf.
    Do you have an idea which command debug I could use to find the solution?

    Regards,
    Gauthier

    ReplyDelete
    Replies
    1. Hi Gauthier - I have to admit it is some time since I worked with MPLS, enjoyable as it is - I seem to remember looking at Wireshark an awful lot and having just a few little bugs which broke the whole process. Sorry I cant be more specific :-(

      Delete
  2. Great information, this is in depth details of how to configure PPP sessions. Thanks for sharing.

    ReplyDelete

Found this pointless and feel you must comment? Really, there is no need, we are fully aware of the pointlessness of this article. But if you must...

Google+ Followers